Live data from Hacker News

How To Safely Store A Password

codahale.com

11–20 of 219 posts

Re: How To Safely Store A Password

#11
post #3
post #2

I'm not so sure. The other side of the coin is that ``{MD5, SHA1, SHA256, SHA512, SHA-3, etc}'' have had extensive peer review in the cryptography world. There's a long history of ``clever new ways'' to use existing crypto algorithms turning out to have serious flaws -- a good example is early attempts to improve the strength of (56-bit key) DES by encrypting three times with three keys. This turns out to introduce e…

No. Use Bcrypt. Always. Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. MD5/SHA1/etc are not weak because they are cryptographically weak (though some are), it is weak because they are fast. SHA3, when it is picked, will still be a very bad choice because it too will be fast. So, why Bcrypt? Well, it uses Blowfish. Blowfish has a very slow key scheduling algorithm which basic…

The question is not whether BCrypt is backed by Blowfish, the question is whether BCrypt uses Blowfish in a way which is cryptographically sound. If it does not, then an attacker may not need to use brute force. Assuming the author has read more of Mr. Schneier's book than the quoted preamble, he should know this -- Schneier discusses this at length in both editions of Applied Cryptography.

Again, an example of this is the 3DES encrypt/decrypt/encrypt process vs. a more naive encrypt/encrypt/encrypt process. One is substantially stronger than the other. One is a secure way to use DES, and one is not.

Re: How To Safely Store A Password

#12
"It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database."

Why are you storing the whole salt in your database? Isn't it much more common to keep half of it in a configuration file? I know Django has a SECRET_KEY parameter for this sort of thing, and hopefully other frameworks do also.

For that matter, why is authentication being handled by the web server? If you've got data worth stealing (billing, emails, medical), you can afford to spring the extra few hundred for a proper authentication server.

Gawker's password handling (7-bit salt, in the database, digested with crypt) seems like the worst possible implementation of secure password storage.

Re: How To Safely Store A Password

#13
post #3
post #2

I'm not so sure. The other side of the coin is that ``{MD5, SHA1, SHA256, SHA512, SHA-3, etc}'' have had extensive peer review in the cryptography world. There's a long history of ``clever new ways'' to use existing crypto algorithms turning out to have serious flaws -- a good example is early attempts to improve the strength of (56-bit key) DES by encrypting three times with three keys. This turns out to introduce e…

No. Use Bcrypt. Always. Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. MD5/SHA1/etc are not weak because they are cryptographically weak (though some are), it is weak because they are fast. SHA3, when it is picked, will still be a very bad choice because it too will be fast. So, why Bcrypt? Well, it uses Blowfish. Blowfish has a very slow key scheduling algorithm which basic…

Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure.

Well, yes, I trust the Blowfish cipher (and GP probably does too). The question is how we can be sure it isn't being somehow misapplied, i.e. whether the way bcrypt uses it opens some other hole. That's what I (and probably GP) would like to see an expert weigh in on.

Re: How To Safely Store A Password

#14
post #9
post #8

Earlier quoted context omitted.

In a case like the Gawker incident, it isn't safe. If the source code to the password hashing algo is compromised (it was) then the salt becomes useless. In short, just use bcrypt.

No. No no no. The source code to the hashing algorithm means nothing . It is already open source! The reason that the salt is there is to prevent against rainbow tables. The salting did NOT become useless. If they had not salted passwords, then many many more passwords would have been broken because instead of having to brute force each and every one, you'd just look it up in a massively large hash table.

[deleted]

Re: How To Safely Store A Password

#15
post #3
post #2

I'm not so sure. The other side of the coin is that ``{MD5, SHA1, SHA256, SHA512, SHA-3, etc}'' have had extensive peer review in the cryptography world. There's a long history of ``clever new ways'' to use existing crypto algorithms turning out to have serious flaws -- a good example is early attempts to improve the strength of (56-bit key) DES by encrypting three times with three keys. This turns out to introduce e…

No. Use Bcrypt. Always. Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. MD5/SHA1/etc are not weak because they are cryptographically weak (though some are), it is weak because they are fast. SHA3, when it is picked, will still be a very bad choice because it too will be fast. So, why Bcrypt? Well, it uses Blowfish. Blowfish has a very slow key scheduling algorithm which basic…

Question, I use SHA512 for my passwords; is that also "fast" in comparison to bcrypt?

Re: How To Safely Store A Password

#16
post #8

HN, is this the consensus? I thought certain hashes worked fine when properly salted?

In a case like the Gawker incident, it isn't safe. If the source code to the password hashing algo is compromised (it was) then the salt becomes useless. In short, just use bcrypt.

Salting and choice of hashing algorithm are orthogonal. If it takes X amount of time to brute force a password of strength Y and you do salt, then an attacker can crack N passwords of strength Y in time NX. If you don't salt, then an attacker can crack all* passwords of strength Y in time N, which is a huge difference.

Re: How To Safely Store A Password

#17
post #7

HN, is this the consensus? I thought certain hashes worked fine when properly salted?

Yes, this is consensus. "Salting" isn't actually a real security practice. See: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the...

That article actually states that salting is a real security practice, is a necessity, and that it's been in UNIX since 1976,

Re: How To Safely Store A Password

#18
post #16
post #8

Earlier quoted context omitted.

In a case like the Gawker incident, it isn't safe. If the source code to the password hashing algo is compromised (it was) then the salt becomes useless. In short, just use bcrypt.

Salting and choice of hashing algorithm are orthogonal. If it takes X amount of time to brute force a password of strength Y and you do salt, then an attacker can crack N passwords of strength Y in time N X. If you don't salt, then an attacker can crack all* passwords of strength Y in time N, which is a huge difference.

Alas, I stand corrected. Thanks. At the same time, the author does have a good point that very slow algorithms are fundamentally better for security, but I'm glad you pointed this difference out. Classic case of me not thinking things all the way through.

Re: How To Safely Store A Password

#19
post #9
post #8

Earlier quoted context omitted.

In a case like the Gawker incident, it isn't safe. If the source code to the password hashing algo is compromised (it was) then the salt becomes useless. In short, just use bcrypt.

No. No no no. The source code to the hashing algorithm means nothing . It is already open source! The reason that the salt is there is to prevent against rainbow tables. The salting did NOT become useless. If they had not salted passwords, then many many more passwords would have been broken because instead of having to brute force each and every one, you'd just look it up in a massively large hash table.

[deleted]

Re: How To Safely Store A Password

#20
post #13
post #3

Earlier quoted context omitted.

No. Use Bcrypt. Always. Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. MD5/SHA1/etc are not weak because they are cryptographically weak (though some are), it is weak because they are fast. SHA3, when it is picked, will still be a very bad choice because it too will be fast. So, why Bcrypt? Well, it uses Blowfish. Blowfish has a very slow key scheduling algorithm which basic…

Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. Well, yes, I trust the Blowfish cipher (and GP probably does too). The question is how we can be sure it isn't being somehow misapplied, i.e. whether the way bcrypt uses it opens some other hole. That's what I (and probably GP) would like to see an expert weigh in on.

Bcrypt is recommended by all the relevant experts who haven't heard of scrypt(1). Those who have(2), use scrypt because it's got a better built-in Moore's Law-defeater than bcrypt.

(1) http://news.ycombinator.com/item?id=601408

(2) http://www.chromium.org/chromium-os/chromiumos-design-docs/p...

Post reply on HN