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
