Have I missed anything? Are there any additional steps storing passwords to the DB?
Storing the Password:
After as much research on the subject as possible I’ve come to the conclusion that the best way to store user passwords in a web application DB (in my case MySQL+PHP) is as follows:
- Assign a sitewide static salt. (16 rand chars incl 0-9,a-z,A-Z,[]/*-‘)
- Assign a per user random salt (stored in the DB).
- Store the result hash_function($userPassword + $sitewideSalt + $randomSalt)
- Store the $randomSalt alongside the resulting hash.
- Use bcrypt adjustable workload
hashing
-
Attack #1: Attacker dumps the DB via SQL Injection.
DB results of
our hash_function and the random per
user salt.After the dump the attacker could
obtain $userPassword and
$randomSalt by looking up his own account. Then by guessing the hash
function such as md5 he could start a
rainbow attack on the
$sitewideSalt. But that could take up to 1.41 hundred million
centuries[1].By using this type of security does not allow a dump of the DB to compromise stored passwords. The user still has to find the $sitewideSalt through another method.
-
Attack #2: Attacker finds a Local File Inclusion (LFI) vector.
Attacker could obtain the raw code for our web application.After exploiting the web application through a possible LFI
or RFI[2] the attacker reads the
source code for our web
application and obtains our simple
algorithm and the stored
$sitewideSalt.
Where to next?
Now the attacker has both of the salts he can begin to rainbow to obtain the actual passwords. Except he must make 1 rainbow table for each user as each user has a different random user specific salt ($randomSalt).
“A modern server can calculate the MD5
hash of about 330MB every second. If
your users have passwords which are
lowercase, alphanumeric, and 6
characters long, you can try every
single possible password of that size
in around 40 seconds.”
“…CUDA, you can put together your own little supercomputer cluster which will let you try around 700,000,000 passwords a second…”[3]
What we need to do now is extend the hashing function by using a time consuming algorithm such as bcrypt. bcrypt’s work load factor can be 5-6 orders of magnitude that of the simpler hashing functions. Cracking just one password can take years instead of minutes. And as a bonus bcrypt already generates a random salt for each hash and stores it in the resulting hash.
Nice work! Looks very complete to me.
Only suggestions I would have are:
Rotate the service salt.
Design a method to periodically rotate the service-wide salt, and exercise it regularly.
For example, after generating a new service salt, use it for all new accounts & any password changes. When an existing user tries to log in, authenticate them with the old service salt. If successful, update their hash with the new service salt (and optionally a new user-specific salt). For users who don’t log in for ‘some time’, randomly generate a new password on their behalf. This will ‘keep up’ security for users who’ve abandoned your site, forcing those that return to use the password reset facilities. (‘some time’ = whatever period you’re comfortable with).
Don’t hard-code your service salt.
Don’t allow a LFI attack to compromise your service salt. Feed the service-salt to your application at start up, and keep it in memory. To compromise the service salt, an attacker would need to be able to execute code to read the salt from memory. If an attacker can do that, you’re pretty well hosed anyway. =)
Don’t reuse a users salt.
Look for opportunities to give users new salts. User changes his password? Generate a new random salt. This further hampers brute forcing your server-wide salt should an attacker be able to obtain his hash whenever he feels like it. Couple this with regularly rotating your service-salt, and I’d wager you’ve got a strong deterrent against brute-forcing.
(Marking this as a community wiki should others have additional ideas).