Mobile app version of vmapp.org
Login or Join
Ogunnowo487

: Using two salts for user authentication? 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

@Ogunnowo487

Posted in: #Authentication #Hash #Password #Security

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) :


One global salt
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.

10.03% popularity Vote Up Vote Down


Login to follow query

More posts by @Ogunnowo487

3 Comments

Sorted by latest first Latest Oldest Best

 

@Dunderdale272

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.

10% popularity Vote Up Vote Down


 

@Sarah324

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

10% popularity Vote Up Vote Down


 

@XinRu657

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.

10% popularity Vote Up Vote Down


Back to top | Use Dark Theme