TL;DR

Don’ts

• Don’t limit what characters users can enter for passwords. Only idiots do this.
• Don’t limit the length of a password. If your users want a sentence with supercalifragilisticexpialidocious in it, don’t prevent them from using it.
• Never store your user’s password in plain-text.
• Never email a password to your user except when they have lost theirs, and you sent a temporary one.
• Never, ever log passwords in any manner.

Do’s

• Use scrypt when you can; bcrypt if you cannot.
• Use PBKDF2 if you cannot use either bcrypt or scrypt.
• Reset everyone’s passwords when the database is compromised.

Why hash passwords anyway?

The objective behind hashing passwords is simple: preventing malicious access to user accounts by compromising the database. So the goal of password hashing is to deter a hacker or cracker by costing them too much time or money to calculate the plain-text passwords. And time/cost are the best deterrents in your arsenal.

Another reason that you want a good, robust hash on a user accounts is to give you enough time to change all the passwords in the system. If your database is compromised you will need enough time to at least lock the system down, if not change every password in the database.

Best practices

Bcrypt and scrypt are the current best practices. Scrypt will be better than bcrypt in time, but it hasn’t seen adoption as a standard by Linux/Unix or by webservers. If you are working with Ruby there is an scrypt gem that will help you out.

I highly suggest reading the documentation for the crypt function if you want to roll your own use of bcrypt, or finding yourself a good wrapper or use something like PHPASS for a more legacy implementation. I recommend a minimum of 12 rounds of bcrypt, if not 15 to 18.

I changed my mind about using bcrypt when I learned that bcrypt only uses blowfish’s key schedule, with a variable cost mechanism. The latter lets you increase the cost to brute-force a password by increasing blowfish’s already expensive key schedule.

Average practices

I almost can’t imagine this situation anymore. PHPASS supports PHP 3.0.18 through 5.3, so it is usable on almost every installation imaginable—and should be if you don’t know for certain that your environment supports bcrypt.

But suppose that you cannot use bcrypt or PHPASS at all. What then?

Try an implementation of PDKBF2 with the minimum number of rounds that your environment/application/user-perception can tolerate. The lowest number I’d recommend is 1000 rounds.

As I Said Last Time…

The computational power required to actually crack a hashed password doesn’t exist. The only way for computers to “crack” a password is to recreate it and simulate the hashing algorithm used to secure it. The speed of the hash is linearly related to its ability to be brute-forced. Worse still, most hash algorithms can be easily parallelized to be reproduced even faster. This is why costly schemes like bcrypt and scrypt are so important.

You cannot possibly foresee all threats or avenues of attack, and so you must make your best effort to protect your users up front. If you do not, then you might even miss the fact that you were attacked until it’s too late… and you’re liable. To avoid that situation, act paranoid to begin with. Attack your own software (internally) and attempt to steal log in information, or access other user’s accounts. If you don’t you cannot blame anyone but yourself.

Lastly: I am not a cryptographer. Whatever I’ve said is my opinion, but I happen to think it’s based on good ol’ common sense … and lots of reading. Remember, be as paranoid as possible, make things as hard to intrude as possible, and then, if you are still worried, contact a white-hat hacker or cryptographer to see what they say about your code/system.

NOTE: This answer was originally posted at StackOverflow.com by Robert K