I know there are legal standards for credit card companies, ecommerce sites etc., but what should any other website do? I'm building a joke aggregation website right now(I know, I know) and I'm planning on sha1 with a 16bit salt. Too much? Too little?
* 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:
* 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.
Hey! Thanks for taking the time to write out such a detailed reply. I did read up. A salt needs to be large enough to avoid clashes with other salts in my database and the algorithm needs to be slow enough to calculate that it's impossible for hackers to crack but fast enough that it doesn't bog my site down. Right?
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!
the algorithm needs to be slow enough to calculate that it's impossible for hackers to crack but fast enough that it doesn't bog my site down. Right?
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.
Thanks for the detailed explanation. I also like this "How to safely store a password" post from a couple of years ago that has similar advice, although it concentrates on bcrypt:
http://codahale.com/how-to-safely-store-a-password/
I'm all in favor of making the passwords as secure as possible for your users, but I hate it when I'm dictated how my password has to look. For less than critical accounts I always use the same password, which is easy to remember to me. If any account is hacked, it’s not a disaster. I just hate it when I sign up for something the website throws back ‘your password should be at least 8 charachters long, contain one of the following characters: @!#$ etc. etc.’. From a usability point of view this is a nightmare, and it will cost you users.
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.
* 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.