Have I missed anything? Are there any additional steps storing passwords to the DB?
Storing the Password:
After as much re
Using BCrypt to handle passwords is the only step, or rather, encompasses the following:
You also forgot this link: http://codahale.com/how-to-safely-store-a-password/ which is what you reference with the quote.
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).