* The whole reason leaking user's passwords is dangerous is because users tend to re-use passwords.
* The purpose of hashing a password is to make it hard for an attacker to know the plaintext
* Many users are probably using fairly predictable passwords (like 'abc123' for example) so if you run them through sha1 these predictable passwords will always come out the same. This means I can precompute them and just look them up. (the table of hashes is called a rainbow table) This is why you use a salt.
* The size of the salt doesn't matter too much (once you're over a certain size) and it doesn't really matter if your attacker knows it. The point is just to add entropy to the user's password.
* The sha family of hashing algorithms are designed to be fast. This is a problem for protecting your data. It means once the attacker has your table, they can rip through the calculations very quickly. You want a slow algorithm that can be tuned to get slower as computers get faster.
* This means for you it might take 1 second to hash a person's password but that means it also takes an attacker 1 second per attempt at brute-forcing. That's not worth it.
* There are several of these but the most popular are scrypt, bcrypt, PBKDF2:
http://www.tarsnap.com/scrypt.html
http://en.wikipedia.org/wiki/Bcrypt
http://en.wikipedia.org/wiki/PBKDF2
* Any one of the above three would be a good choice. Popular web frameworks like rails and django used to just sha256 passwords but they have realized that the speed of that algorithm makes it non-ideal for password hashing.
* If you don't know this stuff, then do spend the time to get familiar with it. Many people will tell you not to implement hashing or encryption algorithms yourself. That's probably a good idea but it's no excuse for not educating yourself.
I picked sha because it's fast to compute. The idea behind the level of security I'll get is that it is trivial to provide and in the occurrence of a data leak, it will require a non-trivial effort to get any plaintext passwords out. Any less than this and the hacker just needs to dump the data on the internet and my users will immediately be SOL.
I think I over-thought the performance bit though. Sign-ups and sign-ins are not a regular enough event to be too much of a performance issue. Thanks again!
That's exactly right. It's kind of an insidious problem because it goes against the intuition of most web developers, which is to be as fast as possible always.
The follow up by Thomas Ptacek, a security expert, goes into a lot more detail about what to use and how: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the...
Both are very readable articles, which I find helps immensely.
In the end, the user is responsible for choosing a secure password. You can only direct.
On a side note: the 'unbreakable' Enigma cypher was cracked (partly) because the German re-used part of the encrypting key, for example, one operator often used the name of his girlfriend as a key. These easy to distuinguish words were called cillies (see http://en.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma#Ope... ).
My point is that you should do everything possible to encrypt the passwords of your users without sacrificing usability.