I think that storing a per user salt and a site salt and using both in your password hashing scheme is about the best you can really do.
If a hacker gets into your database in a way that allows them to reveal structure and uncover your salt value, then they still won't be able to replicate the original password without knowing the site salt, which is stored in code, not the database (unless your site salt is too simple). If they can access code and database then all is lost anyway. But this fear that a hacker might be able to get the value for the user salt if it's just in a column names salt in the user table is a little bit redundant really. If they can get the salt value, then they'll pretty much be able to access everything else so they no longer really need your site at all. Why try to find the key when you've already busted down the door? Also, and I hate to say it, but if a user is for some reason using their banking password for any other public site, then they must wear the lions share of the responsibility if or when it is discovered and used by a malicious user. I mean, you have a role to play in the users security, but so do they. From: Hector Virgen [mailto:[email protected]] Sent: Tuesday, 31 August 2010 3:56 PM To: Bill Karwin Cc: fw-general General Subject: Re: [fw-general] Re: Guidance on storing passwords securely Bill, do you have any concerns about hackers recovering the user's original (raw) password to log into their other accounts such as banking? That's where I see the salt coming in as a protective measure -- they would need the db as well as the code to discover the password. -- Hector Virgen Sent from my Droid X On Aug 30, 2010 10:50 PM, "Bill Karwin" <[email protected]> wrote: > > On Aug 30, 2010, at 10:29 PM, Ralf Eggert wrote: > >> interesting stuff. But where should the distinct salt per user be >> saved? >> It feels quite wrong to store it in the database right beside the >> password. Or should it be combined from, lets say: user id, email >> address and registration date? > > Ideally the salt should be more strongly pseudorandom. You don't need > to use any constant or other user-related field in the calculation of > the salt. Just make it as random as you can make it. And make sure > you use a distinct random salt per user. > > If the attacker gains access to make queries against your database, > you've lost the game anyway, so storing the salt in a column named > "salt" in the same table with the hashed password is not significantly > riskier than storing the salt anywhere else that the attacker gains > access to. > > In other words, don't rely on security by obscurity. Don't even favor > security by obscurity. In some ways, I think it's better *not* to > make your code or database obscure at all, if that encourages you to > strengthen more effective security measures to prevent attackers from > gaining access. > > Regards, > Bill Karwin
