How do you use SHA256 to create a key token, value pairs and secret signature?

I want to check some hidden input fields (to make sure that they were changed during sending) using a sha-encoded string of key value pairs of these hidden fields. I saw examples of this online, but I did not understand how to encode and decode values ​​with a dynamic secret value. Can someone help me figure out how to do this in perl?

And what type of signature (MD5, SHA1, SHA256, etc.) has a good balance of performance and security?

Update

So how do you decode a string after encoding it?

+4
source share
3 answers

What you really need is not a simple hash function, but a message authentication code like HMAC . Since you say you want to use SHA-256, you might like the HMAC_SHA256, which is available in Perl through the Digest :: SHA module

use Digest::SHA qw(hmac_sha256_base64); my $mac = hmac_sha256_base64( $string, $key ); 

Here $key is an arbitrary key that you must keep secret, and $string contains the data you want to sign. To apply this to a more complex data structure (for example, hashes of a key pair -), you first need to convert it to a string. There are several ways to do this; for example, you can use Storable :

 use Storable qw(freeze); sub pairs_to_string { local $Storable::canonical = 1; my %hash = @_; return freeze( \%hash ); } 

You could also encode URLs as suggested by David Schwartz . The important thing is that any method you use should always return the same string if the same hash is specified as the input.

Then, before sending data to the user, you calculate the MAC for them and include it as an additional field in the data. When you get the data back, you delete the MAC field (and save its value), recalculate the MAC for the remaining fields, and compare it with the received value. If they do not match, someone (or something) forged the data. Like this:

 my $key = "secret"; sub mac { hmac_sha256_base64( pairs_to_string(@_), $key ) } # before sending data to client: my %data = (foo => "something", bar => "whatever"); $data{mac} = mac( %data ); # after receiving %data back from client: my $mac = delete $data{mac}; die "MAC mismatch" if $mac ne mac( %data ); 

Please note that there are some potential tricks that this method does not automatically prevent, such as repeated attacks : after sending the data and the MAC for the user, they will recognize the MAC corresponding to the specific data set and can potentially replace the fields in the later form with the values ​​stored from earlier form. To protect yourself from such attacks, you must include sufficient identifying information in the data protected by the MAC to ensure that any potentially dangerous retries are detected. Ideally, you want to include a unique identifier in each form and verify that no identifier is submitted twice, but this may not always be practical. Otherwise, it might be a good idea to include the user ID (so that the attacker could not fool someone else into sending their data) and the form identifier (so that the user could not copy data from one form to another) and, possibly, a timestamp and / or session identifier (so you can discard old data) on the form (and in the MAC calculation).

+2
source

I don't know what you mean by "unpack", but you cannot get the original string from the hash.

Let me understand the problem: you create hidden fields, and you want to make sure that they are presented without changes, right? Here you can provide it.

Suppose you have two variables:

 first: foo second: bar 

You can use them together with a secret key:

 secret_key = "ysEJbKTuJU6u" source_string = secret_key + "first" + "foo" + "second" + "bar" hash = MD5(source_string) # => "1adfda97d28af6535ef7e8fcb921d3f0" 

Now you can do your markup:

 <input type="hidden" name="first" value="foo" /> <input type="hidden" name="second" value="bar" /> <input type="hidden" name="hash" value="1adfda97d28af6535ef7e8fcb921d3f0"> 

When you submit the form, you get the values ​​of the first and second fields, attach them to the private key in the same way and hash again.

If the hashes are equal, your values ​​have not been changed.

Note. never provide the secret key to the client. And sort the key / value pairs before hashing (to eliminate order dependency).

(disclaimer: I'm not a cryptography specialist, so you can just stop reading now)

Regarding performance / security, despite the fact that it was discovered that MD5 has a weakness, it is still quite useful, IMHO. SHA1 has a theoretical weakness, although there has not yet been a successful attack. There are no known flaws in SHA-256.

+3
source

For this application, any encryption algorithm is in order. You can pack the values ​​as you like, as long as they are repeatable. One common method is to pack the fields into a string the same way you encode them into the URL for the GET request (name = value).

To compute the hash, create secret text that can be whatever you want. It must be at least 12 bytes long. Calculate the privacy hash combined with the packed fields and add this to the end.

So, let's say you chose MD5, the secret of JS90320ERHe2 , and you have these fields:

 first_name = Jack last_name = Smith other_field = 7=2 

First, the URL encodes it:

 first_name=Jack&last_name=Smith&other_field=7%3d=2 

Then calculate the MD5 hash

 JS90320ERHe2first_name=Jack&last_name=Smith&other_field=7%3d=2 

This is 6d0fa69703935efaa183be57f81d38ea . Final encoded field:

 first_name=Jack&last_name=Smith&other_field=7%3d=2&hash=6d0fa69703935efaa183be57f81d38ea 

So what do you pass to the user. To test it, remove the hash from the end, calculate the MD5 hash, combining what remains with this secret, and if the hashes match, this field has not been changed.

No one can compute their own valid MD5 because they don’t know that the string prefix should be.

Note that an adversary can reuse any old valid value. They simply cannot create their own value set from scratch, or modify an existing one and test it for proper operation. Therefore, make sure that you include something in the information so that you can verify that it is suitable for the purpose that it used.

+2
source

Source: https://habr.com/ru/post/1390580/


All Articles