Password storage is a pet peeve of mine. I’ve worked with systems that use:
- bidirectional encryption for the passwords (you can convert the password into gibberish, and then back to readable text),
- MD5 hashing (you can convert the string to gibberish, but not back. You test the password by hashing the password that the user is trying to log in with and comparing it to the hash in the database.), and
- clear text storage. (This is the worst plan ever).
They each have their own security flaws. Bidirectional encryption can be converted to clear text, which means that if someone steals the user list, they can discover all the passwords. Likewise, you can build a dictionary of known passwords and MD5 hashes and use that to look up the password that made a hash. And storing a password in clear text is pretty much the same as just giving out your user’s passwords.
I’m currently working on a software application that uses the BCrypt hashing algorithm to store passwords. BCrypt is available for .net and other languages, and is very easy to use and implement. The BCrypt library produces a salted hash, and stores the salt and the hash together. This systems means that even if you had a dictionary of hashes, you would need to rehash your entire dictionary for each salt. As each salt is unique, this is going to take a long time. The algorithm is intentionally slow, but configurable. By default it runs about ten iterations, but can be adjusted higher. The trade off is between security and hardware. In theory, as the hardware gets better you can increase the number of iterations, and keep it difficult to compute. The estimated execution time for the default configuration is 0.3 seconds per hash.
So, to summarise, BCrypt is:
- a one way hash (you cant reverse the password out);
- uniquely salted, making pre computed dictionary attacks much less useful;
- adaptive, so it can handle future changes in available compute power; and
- easy to implement.
So people, hash your passwords!
More information at DerekSlager.com.