add salt to value before hash

[SHARATH YERAMALLA]

Hi There,

How could I add salt to the value before generate hash value to it? Is there any article that you could refer for it with a sample policy.Thanks in advance to CA.

[Zhijun He]

You might think of using Generate UUID assertion to generate the salt and add it to the source data.

https://docops.ca.com/ca-api-gateway/9-4/en/policy-assertions/assertion-palette/policy-logic-assertions/generate-uuid-as… 

(it's a 32bit UUID, if you want longer salt, generate UUID few times and concat them.)

[Mark ODonohue]

1. There is also :  ${gateway.random.[byte].[type]}

 

 

see :  Generating Random Values   in : 

General Context Variables - CA API Gateway - 9.4 - CA Technologies Documentation 

 

 

Can be used in similar way. 

 

2. Storing and Verifying value latter

 

I suspect from the question you ask you already know but just to point out if you do generate hash with salt added for each entry, then to verify the value latter, you need to store the salt value as well as the calculated hash value.

 

Something similar to : 

 

  calc hash: (somekey, data) 

       salt = generate_uuid();

       hashvalue = Hash( salt + data);

       storeSalt (somekey, salt)

       storeHash (somekey, hashValue)

 

 

verify hash:    (somekey, newdata)

     salt = getSalt(somekey)

     hashvalue = getHash(somekey) 

     

     newhashvalue = Hash(salt + newdata)

 

     result = (hashvalue == newhashvalue)

     return result;

   

   

Cheers - Mark

[SHARATH YERAMALLA]

This is exactly what am looking for, i need to store the salt for later to calculate the hash.For instance the userid(email)+salt=Hash.I will store the calculated hash in a log, but how could i get that salt back which i appended to recalculate/compare with the initial hash generated.I think here i need to use a known salt every time rather a random guid.

[Mark ODonohue]

It depends on what you are using the hash for as the salt is to make each hash(email) not the same.

 

1) How I think you want to use it - same salt for all hashes.

So if in your logs you are relying on the same user having the same hash, so you can check how often they logged on - but you want to make it harder for someone to enumerate over all the possible email addresses to find the value for the hash. -  then you probably want a single generated salt value you always use for calculating your hash. 

 

That will mean that two hashes of the same email will then give the same hash value, but still salted, so not a vanilla sha256 hash. 

 

so:  - do once and store. 

    static_salt = gen_uuid.  (once and store) 

 

then first gen of hash will be : 

    hash (email + static_salt) = hash1

 

And latter gen of hash will give the same : 

    hash (email + static_salt) = hash1

 

But it would be difficult for someone to try and backcalculate the email from hash1 using vanilla rainbow tables. 

 

 

2) Salting each storage. - storing passwords with SSHA 

Alternatively, and this is more applicable to passwords, in the above would still allow you to see if two users had the same email address, since they have the same hash, so if you generate a new salt each time you store the password, then even if say two users have the same password, each storage will generate a unique hashed value - so it's not possible to quickly know that admin and root have the same "hashed" value - so must have the same password.

 

So say using SSHA (salted SHA) then would do 

salt_value = gen_uuid  (20 bytes)

hash ( password+ salt) = hash1

 

Then you store the SSHA password in the db or something as string :   
          ssha_hash = {SSHA} salt_value + hash1 

 

Latter to verify the users password, when they present it again, you can check it's the same is the same,

you have : 

          ssha_hash = {SSHA} salt_value + hash1 

and : 

         newpassword

so extract the salt value which was the first 20 bytes of the stored ssha_hash, then calculate : 

    calc :   new_hash = hash(newpassword + salt_value ) 

 

     and compare new_hash == hash1. 

 

will tell you if the new_password matches the orignal password. 

 

Hope that helps. 

 

Cheers - Mark

[Zhijun He]

Just for discussion, maybe I don't understand it properly, but I believe the salt should be a random value, the purpose of salts is to generate different hash for the same password, therefore the password will have to be attacked individually. ie. if you have some users with same password, even on user is hacked, the others should still be safe.

 

I don't see difference between using constant salt  and  don't use it at all.

 

You can use jdbc connection to persist/retrieve the salt to/from external database.

[Mark ODonohue]

Hi Mark_HE,  you are correct, salt should be random value. I'll explain a bit below, as I think their use case is case 1) not 2). 

 

There are two ways :

 

1) You can have a single random "salt" value you generate once, and use all the time. 

This use of this salt makes your SHA256  "hash" different from the default SHA256 hash (without salt) -  

 

It has convenience that two hashes of the same value will give the same hash value. 

 

Best to store the "salt" seperate from the hashed data, so if someone gets backup copy of your database, without salt value they will have difficulty doing dictionary attack on your passwords for example. 

 

May programs do this by hardcoding some salt into their code, it is not foolproof, but it is better than non salted. 

 

So using md5 hash for demo : 

~ $ echo "password" | openssl dgst -md5   

(stdin)= 286755fad04869ca523320acce0dc6a4

 

If we have hardcoded salt value :  96cb3e0a

 

odonohue@ponyta ~ $ echo "96cb3e0apassword" | openssl dgst -md5
(stdin)= 1095e9066fed434c7a47959c452e3077

 

This gives us different answer to no-salt.   

 

But also if our code hashes "password" twice for two different users we will get the same hashvalue of "1095e9066fed434c7a47959c452e3077".

 

I can see for this case, since they are hashing email addresses, this may be what they want, as they may want to know from logs that it is the same user (since it gives same hash), even though they do not want visible the actual email address for the user.

 

 

2) Storing salt with each hashed value: (stronger) 

This is more secure, but means if two uses of the same value we cannot detect them by simply viewing the logs as they will have different "hashed" values 

 

With this method, when we store the SSHA hash of "password" the first time : we generate random salt : "96cb3e0a"

odonohue@ponyta ~ $ echo "96cb3e0apassword" | openssl dgst -md5
(stdin)= 1095e9066fed434c7a47959c452e3077

we then store the salt plus hash as :  "96cb3e0a" + "1095e9066fed434c7a47959c452e3077" somethign like : 

   {SSHA} 96cb3e0a1095e9066fed434c7a47959c452e3077

in the db. 

 

To verify we need to get the entry, via a key, extract the "96cb3e0a" prefix, and then recalculate the hash with the hash("96cb3e0a" + newPassword ) which should then match the "1095e9066fed434c7a47959c452e3077".

 

But.. if we store SSHA for another user, we generate new salt for them, so we have : new random salt : 1d8529d9

 

 

odonohue@ponyta ~ $ echo "1d8529d9password" | openssl dgst -md5
(stdin)= b527b9ef9bcefbb798fea6e8e434722e

store the salt plus hash a{SSHA} "1d8529d9" + "b527b9ef9bcefbb798fea6e8e434722e"

giving {SSHA} 1d8529d9b527b9ef9bcefbb798fea6e8e434722e

 

So even though both users have the same password : "password" the hashes are different, and it is not possible by looking at the database or the logs to detect they are using the same password. 

 

So for customers case, they would not be able to detect that the customer was using the same email address from viewing the logs - that may be what they want, but I suspect it is option 1) they are after. 

 

 

Cheers - Mark

[Dirk Bleyenberg]

Hi

 

Did the answers on this thread answered your question? If it did please mark it as the right answer.
When your question is not answered or you still have additional questions please let us know.

 

With Kind Regards
Dirk