Salted Hashes - yum.

azzeretti

I am just wondering if anyone has any comments on the security implications of storing passwords in a database for web authentication. I have inherited a web app that is currently storing the user passwords in the MySQL table encoded simply with the MySQL ENCODE function. While this does provide some encoding I am moving it away towards an SHA-1 algorithm or bcrypt. I like bcrypt because of it's very slow key setup but need to trade-off with account creation and login checking.

Anyway, I am tinkering with bcrypt but concerned about salt. Specifically the generation of (or not). Does anyone have any thoughts on this? Storing a random salt along with the hashed password has its downsides as does using a static salt but I can't really see any way around either especially if you consider the box being comprismised (that is, once they get access to the box none of this really matters!)

Cool Mo D

azzeretti wrote: »

I am just wondering if anyone has any comments on the security implications of storing passwords in a database for web authentication. I have inherited a web app that is currently storing the user passwords in the MySQL table encoded simply with the MySQL ENCODE function. While this does provide some encoding I am moving it away towards an SHA-1 algorithm or bcrypt. I like bcrypt because of it's very slow key setup but need to trade-off with account creation and login checking.

Anyway, I am tinkering with bcrypt but concerned about salt. Specifically the generation of (or not). Does anyone have any thoughts on this? Storing a random salt along with the hashed password has its downsides as does using a static salt but I can't really see any way around either especially if you consider the box being comprismised (that is, once they get access to the box none of this really matters!)

I'm not an expert, but I believe best practise is to:

• Generate a long random salt for each user, and store this in plaintext.
• Don't store any plain text passwords, but concatenate the password and salt, and hash them with the most secure hashing algorithm you have access to.

If the attackers get your database, and hence know the salt, it does not make cracking a single password any harder than it would be without the salt, but they will have to generate a new set of rainbow tables for each user, making it much, much more difficult to harvest multiple passwords.

Good discussion here: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190

azzeretti

Good discussion here: http://stackoverflow.com/questions/1645161/salt-generation-and-open-source-software/1645190#1645190

There's some good info in that link. The problem is I can find other opinions expressing reasons why you shouldn't use random salt and only use a static secret salt - nightmare!

Procasinator

Well if you have only one secret salt, then once it is found out, a rainbow table could be used for all passwords.

Even if you protect the salt well, if they crack one password they'll know what it is. And as you said, there is always good chance that if they get in, they'll get everything anyhow.

How do people justify a static salt?