Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How To Safely Store A Password

codahale.com

Post reply on HN
Print view View original

41–50 of 219 posts

Re: How To Safely Store A Password

#41

Post by tptacek »

aidenn0 wrote: post #17
frisco wrote: post #7

Earlier quoted context omitted.

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,

He may be saying that because I've been making fun of people who use the word "salt" (in most other situations, crypto people would call that a "nonce"); I have in the past made the point that real crypto people never say "salt".

But then Eli Biham used the term extensively in his HAIFA framework and I lost the argument. I'll still make fun of the word (salt! smoked salt! peanut salt! hah!), but I can't say no crypto people use it. I wish they wouldn't, though.

Re: How To Safely Store A Password

#42

Post by jmillikin »

tptacek wrote: post #30
jmillikin wrote: post #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 i…

That salt is a public value . The security of salted password schemes is meant not to depend on the secrecy of the salt. Every time this topic comes up, 15 people chime in with various schemes in which some of the "salt" is derived from the hostname and some of it is stored in an encrypted vault and some of it is inferred from the color of the user's eyes. This is why Coda is making fun of "Himalayan pink salt". To u…

> That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt.

I don't understand why you'd add extra content to the password unless you keep it secret. The whole point of a salt/nonce is to prevent attackers from attacking the digest, right? You need some per-user data, to defend against rainbow tables, and some per-site data, to protect weak passwords.

My fundamental objection to schemes like bcrypt/scrypt is that they impose a heavy performance penalty on authentication to avoid a relatively rare case; besides, any theoretical entity capable of reversing a typical salted-password implementation is also capable of reversing bcrypt/scrypt.

Re: How To Safely Store A Password

#43

Post by bostonvaulter2 »

frisco wrote: post #28
aidenn0 wrote: post #17

Earlier quoted context omitted.

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

I was more talking about bcrypt being consensus with that post. Salting slows down cracking attempts by a factor of N where N is the length of the hash; md5 and sha1 are so fast that you shouldn't be banking on salting to protect you in 2010. Also, you should assume that if an attacker has your database (with salts), they also have your code, which tells them exactly how the salt was applied. In that case, salting do…

I think the point is that you should use bcrypt and salt at the same time.

Re: How To Safely Store A Password

#44

Post by jmillikin »

whakojacko wrote: post #35
jmillikin wrote: post #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 i…

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. How is that really any better? You should assume that if an attack can get to your database, they can get to your web servers and take all of that as well. Such a scheme certainly wouldn't hav…

Config files are not typically world-readable; the httpd reads them before dropping permissions. Otherwise, a vulnerability in the httpd would allow access to everything in the config (remote server passwords, signing keys, etc).

There's no reason why compromising the database would allow attackers into the web server, unless you've configured SSH to allow signing in from arbitrary remote systems.

Re: How To Safely Store A Password

#45

Post by oiuytrtyuiuytr »

tptacek wrote: post #40
tzs wrote: post #31

Earlier quoted context omitted.

Salting was introduced long before rainbow tables were invented.

Salting was introduced in the 1970's to combat the underlying class of attacks that rainbow tables optimize. Think of rainbow tables as a compression scheme; the attack is precomputation.

And with GPUs rainbow tables are gone - it's now quicker to calculate an MD5 than read it from disk!

Re: How To Safely Store A Password

#46

Post by jhchen »

frisco wrote: post #28
aidenn0 wrote: post #17

Earlier quoted context omitted.

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

I was more talking about bcrypt being consensus with that post. Salting slows down cracking attempts by a factor of N where N is the length of the hash; md5 and sha1 are so fast that you shouldn't be banking on salting to protect you in 2010. Also, you should assume that if an attacker has your database (with salts), they also have your code, which tells them exactly how the salt was applied. In that case, salting do…

But you're talking about defending against brute force attacks? Salting's strength is in defending against rainbow tables. It seems the best policy at this point is to use both as they defend against different things and are not mutually exclusive.

Re: How To Safely Store A Password

#47

Post by tptacek »

jimwise wrote: post #11
Xk wrote: 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…

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…

Don't use DES-EDE.

Schneier all but disavowed _Applied Cryptography_ in _Practical Cryptography_.

Schneier's reputation as a cryptanalyst is, as even he might concede at this point, somewhat outstripping his actual career.

Bcrypt is part of the academic literature; the people who wrote it are both renowned.

You can make your same critique about any other crypto construction; maybe the OCB block cipher mode is unsafe! After all, Bruce Schneier didn't write it!

Re: How To Safely Store A Password

#49

Post by tptacek »

jmillikin wrote: post #42
tptacek wrote: post #30

Earlier quoted context omitted.

That salt is a public value . The security of salted password schemes is meant not to depend on the secrecy of the salt. Every time this topic comes up, 15 people chime in with various schemes in which some of the "salt" is derived from the hostname and some of it is stored in an encrypted vault and some of it is inferred from the color of the user's eyes. This is why Coda is making fun of "Himalayan pink salt". To u…

> That salt is a public value. The security of salted password schemes is meant not to depend on the secrecy of the salt. I don't understand why you'd add extra content to the password unless you keep it secret. The whole point of a salt/nonce is to prevent attackers from attacking the digest, right? You need some per-user data, to defend against rainbow tables, and some per-site data, to protect weak passwords. My f…

"Reversing" bcrypt? "Reversing" salted hashes?

You're exactly the guy I'm talking about. "Oh, I use AES, but I don't just use AES; I store the secret IV for AES in a cookie so even my server can't decrypt it unless the client comes back with the IV so it's like two guys in the silo with the missile keys". Seriously, I just found that piece of code yesterday. Did you write it? Stop writing that stuff.

Re: How To Safely Store A Password

#50

Post by dfranke »

tptacek wrote: post #36
khafra wrote: post #20

Earlier quoted context omitted.

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...

(a) Virtually nobody has heard of scrypt; contrary to HN conventional wisdom, Colin is not yet a world-famous cryptographer. Give him time. (b) There are operational reasons not to use scrypt, one of them being that there is no reference implementation with broad language bindings. (c) The specific improvement scrypt makes over bcrypt is not yet relevant; nobody has ever hardware-optimized a bcrypt cracker, and the p…

The specific improvement scrypt makes over bcrypt is not yet relevant; nobody has ever hardware-optimized a bcrypt cracker, and the project that successfully does so and publishes their results will have made a contribution to cryptography literature.

Sure they have. A hardware-optimized bcrypt cracker is called a GPU. I can buy a 480-core GPU on Newegg for $350, but it doesn't come with any more RAM than a low-end PC does.

Post reply on HN