5

When storing user credentials in a database, we all know that hashing the password is the bare minimum you should do, but salting it before hashing is better. The salt should be randomly generated, long enough, and unique for each user.

I remember reading somewhere (but I don't remember where) an article about using two salts (both long enough and randomly generated) :

  1. One global salt
  2. One unique-per-entry salt

The resulting hash would be : hash(globalSalt + password + uniqueSalt) (the order of concatenation is not really important).

Is there any reason why this would be more secure than simply having one unique salt per entry ? We suppose that the attacker has access to the code files where the global salt is stored.

3 Answers 3

8

I wrote an answer, then read a little more, and substatially edited my answer. This question has already been debated on Stack Overflow. The accepted answer on this question is a good starting point, follow the links.

My take is that:

The static salt (which you call global) is somewhat valuable because:

  • It is simple to implement, and doesn't require a database lookup at runtime, i.e. it's easy to scale.
  • This salt is static, and can be stored as a global constant in the the application code, or read from an INI file. This way getting access to the database (SQL injection attack for example) does not necessarily reveal this salt.

The per-password salt is important because:

  • It is a random string, unique for each password, generated on the server side, and stored in plain text in the database. For N passwords, this effectively makes the total search space for a rainbow table attach N x N. This cannot be effectively attacked by pre-computed rainbow tables today due to the sheer size of the dataset.

Another useful tip that I learned from the Stack Overflow discussions is encrypting the username if possible. I hadn't actually thought of that, but it does of course make good sense in certain scenarios.

EDIT: Please do read the excellent article "Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes". Most of what is said about password hashing is wrong, including the whole 'MD5/SHA256 with a salt' approach so often used.

3
  • Thanks for the link and comments. I looked a bit on SO, but figured this kind of question belonged here.
    – Wookai
    Sep 28, 2010 at 11:05
  • The primary reason to salt passwords is to 'salty the earth' for attackers who gain access to your webserver and DB. If all you do is the static salt, you cant be sure the passwords wont be decrypted easily. If the webserver code is stored in plaintext (PHP, Python, Ruby etc.) the salt will be found and exploited with a single rainbow table. If you do a per-account salt they will have to build a rainbow table PER PASSWORD which becomes infeasible. Some attackers have lots of time on their hands so even this could be broken. Per-account salts still buy your users some time. Sep 29, 2010 at 3:45
  • Gareth Farrington: I agree. My point is mainly that (a) getting access to the database file and the web server code is 2 different things, think SQL injection attack against a 2-tier system, and (b) the whole salting discussion is less important than 'use a secure system designed by someone else and peer reviewed' as the the "Enough With The Rainbow Tables" article.
    – user1857
    Sep 29, 2010 at 11:18
4

This pretty much has already been asked on StackOverflow: Double salt for hashing passwords?

1

I just read this question and it reminded me of a question I posted on SO about a year ago: Comprehensive information about hash salts. You might be interested in reading over the question and answers as it has some other information which could be very useful to anyone interested in learning a bit more about hashes.

I should also note that implementing user authentication in general is not something which you really want to tackle on your own if you can avoid it. Always remember Don't Reinvent The Wheel, Unless You Plan on Learning More About Wheels.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.