2

I have spent the past hour reading up on salting and still don't understand how it is achieved. Forgive me if im wrong, but the way I am thinking of salting is, storing an ArrayList of random strings for example 100 strings. Now when a user registers, a method gets a random string from the array list and retrieves the index of the string within the array to insert into my DB, it then applies this random string to the password the user entered and then hashes the whole string and stores into the DB.

Now when the user logs in it will retrieve the index for the ArrayList of random strings, then applies it to the entered password to then hash the whole string and compare the 2 passwords.

Is this a good way of salting? Is this classed as salting?

otus
  • 32,132
  • 5
  • 70
  • 165
mogorilla
  • 123
  • 2
  • 1
    A different random salt is generated when the user account is created (or possibly when a password is changed). You typically store it in the database with the password hash. http://crypto.stackexchange.com/questions/1776/can-you-help-me-understand-what-a-cryptographic-salt-is/2010#2010 – bmm6o Jul 10 '15 at 20:16
  • But how is it possible to compare the 2 strings when logging in? ie the user entered password and the password in the db? @bmm6o – mogorilla Jul 10 '15 at 20:41
  • You access your database using the user's name. You retrieve the salt and the parameters for the password-hashing scheme. You compute the password-hashing scheme using said parameters, the salt and the password and check if the resulting digest matches with the stored one (in the same entry as the parameters and the salt). – SEJPM Jul 10 '15 at 21:13
  • You had tagged the question MD5, which isn't relevant to the question, so I removed it. I hope it didn't mean you intended to use MD5 as the hash. MD5 is broken, and although current attacks don't apply to this kind of use, they only get better. – otus Jul 11 '15 at 08:09

1 Answers1

1

No it isn't a good way of salting and it isn't the standard way either. There is no reason or benefit to store the salt before it is used. The point of salt is just to prevent parallel and precomputation attacks. Storing it ahead of time means in an undetected compromise the attacker would learn of 'future salts' which undermine the precomputation resistance.

After the salt is generated and used to hash the password it can simply be stored in the database right next to the hashed password. There is no reason to come up with more complicated schemes.

So as an example let's say Bob signs up at your website. He provides a username of 'bob' and a password of 'passw0rd'. Your login/signup code generates a random 64 bit salt of 'ed7d9075fe3d31e7'. You should be using a KDF like PBDKF2 instead of a simple hash to securely hash passwords. For this simple example lets assume it is just a single hash like SHA-256. Instead of hashing just the password you hash the password concatenated with the salt. Let's imagine the resulting hash is '58e901b....'

You would store in the user table of your database a record with username = bob, hashedpassword = 0x58e901b..., salt = ed7d9075fe3d31e7.

When someone attempts to login with username of 'bob' and password of 'pass' you would lookup the username 'bob' to read the salt and hashed password from the database. You take the password from the attempted login ('pass') and concatenate it with the salt from the database to produce a hash exactly like you did on signup. You don't know what bob's correct password but you do know it should produce the hash stored in the database. In this case the password is wrong so it will produce a different password and can provide an error.

Gerald Davis
  • 616
  • 4
  • 6