

Ask HN: What are the current standards for online password storage? - asto

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?
======
po
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://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.

~~~
asto
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!

~~~
po
_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.

------
jacktoole1
Jeff Atwood has a great layman's introduction to rainbow tables and why this
stuff deserves thought here:
[http://www.codinghorror.com/blog/2007/09/rainbow-hash-
cracki...](http://www.codinghorror.com/blog/2007/09/rainbow-hash-
cracking.html)

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...](http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-
tables-what-you-need-to-know-about-s.html)

Both are very readable articles, which I find helps immensely.

------
dirkdeman
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...](http://en.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma#Operating_shortcomings)
).

My point is that you should do everything possible to encrypt the passwords of
your users without sacrificing usability.

------
nreece
Bcrypt should be the ideal starting point.

