3 ms·
Wrong algorithm. Here's what you need to know: * The whole reason leaking user's passwords is dangerous is because users tend to re-use passwords. * The purpo
by po 15y ago
Wrong algorithm. Here's what you need to know:
* 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://www.tarsnap.com/scrypt.html
http://en.wikipedia.org/wiki/Bcrypt http://en.wikipedia.org/wiki/Bcrypt
http://en.wikipedia.org/wiki/PBKDF2 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.
- asto 15y agoHey! 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!
- po 15y agothe 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.
- tagawa 15y agoThanks 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/ http://codahale.com/how-to-safely-store-a-password/