3 ms·
Using a site-specific constant combined with the user's e-mail as the salt isn't too horrible. The owasp link you provided explains the two goals of using a sa
by Strom 10y ago
Using a site-specific constant combined with the user's e-mail as the salt isn't too horrible.
The owasp link you provided explains the two goals of using a salt:
1) Not being able to tell two passwords are identical based on the resulting hash. The e-mail is unique per user, so even if a bunch of users have "password" as their password, the hashes will all be different. Yes, if a user changes their password from "password" to "password" then the hash remains the same, but this is a very minor problem.
2) Prevent rainbow attacks. The constant part of the salt is enough to demand a site-specific rainbow table, and the e-mail takes this even further to a site + e-mail combo. Thus rainbow attacks would only have value in targeted attacks against a known site constant & e-mail combo. Once a good table is complete, it won't matter if the user changes their password.
Using a unique random salt would solve these two issues, however they can also be solved by adding a simple timestamp of the password's initial hashing time to the salt.
- sokoloff 10y agosite-specific content (or formulaic derivations based on other columns likely to be in the same DB dump) suffer from internal (or former internal) bad actor problems as well. Disgruntled (or just loose-lipped) ex-employees can leak the formula or constant and you have a false sense of security. (I'm not arguing it's "too horrible", but I am saying that it's worse than other schemes that aren't significantly more burdensome.)
- Someone1234 10y agoA site specific constant is often called a "Pepper" as an aside. Just helps people google it if they want more information. Several implementations utilise a Salt + Papper (unique per user value and single per site value). A Pepper is particularly useful when it is NOT stored in the database (e.g. stored in an environmental variable or even code). That way if someone steals your database via SQL Injection or a database backup file, they'd have to break the Pepper to recover passwords. Peppers only make sense when they're almost "free" to implement. A slow hashing scheme is the most important thing, then unique salting, and finally a pepper last (since a pepper adds the least security wise).