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

141–150 of 219 posts

Re: How To Safely Store A Password

#141

Post by Locke1689 »

e1ven wrote: post #131
tptacek wrote: post #63

Earlier quoted context omitted.

SHA1(salt || password) is an incompetent design that is debatably even easier to crack than the Gawker hashes. The insecurity of that construction is why we have PBKDF2. If the entire knowledge you have of cryptography comes from _Applied Cryptography_ --- wait; let me extend that: if you even feel the need to cite _Applied Cryptography_ --- you should be careful debating crypto constructions. You're not going to end…

I don't have a dog in this race either way, but I'm curious what you dislike about Schneier's book.

It's not deep enough to provide true knowledge of cryptography and cryptographic attacks while it also doesn't give practical advice on what to actually do in situations that require cryptography (read: always use high-level primitives). Applied Cryptography is pretty good (if outdated), I think, if you're seeking to gain a beginner-level knowledge of cryptography. Practical Cryptography, on the other hand, is a far better choice for what to do when actually using cryptography (although even that is outdated now).

Re: How To Safely Store A Password

#142

Post by gcr »

Cushman wrote: post #32

I wonder, is it easy to use bcrypt with a variable work factor per-password? I'm thinking you could take your entropy analysis of the user's password and set it so that "weaker" passwords use a higher work factor. This analysis could be easily done before hashing every time the password is input, so an attacker wouldn't be able to single out weak passwords from the hash file. Theoretically, you should be able to tail…

Hm. I don't know about bcrypt at all -- is it possible, given the ciphertext, to know roughly how much work is required to test a password?

E.g. an attacker can go "Oh! this password will take FIVE SECONDS to test, so I know it must be a simple password." or "Hey, check this out; this password can be tested in 0.1 seconds. It must be pretty complex."

In general, I'd guess that these kinds of information leaks are pretty bad because if an attacker can see how hard a password is to test, he now knows something about the password.

It may be better if, given a single unchanging hash, if it takes a variable amount of time to test a given password against this hash, though that might have its own can of worms.

Re: How To Safely Store A Password

#143

Post by gcr »

andreyf wrote: post #133
Cushman wrote: post #70

Earlier quoted context omitted.

That's true of passwords over a certain strength, for sure. And it always has been; "6ab$TRa?" has never been counting on the difficulty of hashing for security, and probably won't for some time. But as computing power increases, that minimum strength is being pushed out. bcrypt lets us hold the line by keeping pace with computing power— couldn't it also give us the ability to push back? How many users are using the…

"6ab$TRa?" has never been counting on the difficulty of hashing for security, and probably won't for some time. False.

Elaborate. Obviously its security depends on the hashing scheme (if it's CRC32, you could find a collision pretty easily), but educate us -- is that all you meant?

Re: How To Safely Store A Password

#144

Post by gcr »

Xk wrote: post #127
IgorPartola wrote: post #125

Earlier quoted context omitted.

Why not also add HASH.update(salt) On each iteration as well? Then again, if things were this simple, someone would have already said "just do this", it would have been peer-reviewed and would have become widely used. Anyone know why this hasn't caught on yet in web frameworks like Django/Rails?

If you're talking about why you don't do hash.update(salt) on every round, well it turns out that H(salt || H(H(H(H(H(H(password))))))) is just as strong as H(salt || H(salt || H(salt || H(salt || H(salt || H(salt || H(salt || password))))))). So you don't add any security by doing that. When working with cryptography, "why not also add" is really dangerous, because some times you get less secure systems after doing…

Could you explain a bit more about this?

Re: How To Safely Store A Password

#145

Post by bigiain »

niels_olson wrote: post #118

Fun fact: this has been posted to Hacker News before, when it first came out. I think most would agree this is a great example of why re-posting should be allowed. http://news.ycombinator.com/item?id=1091104

+1

Thanks to codahale for writing this, r11t the HN user who originally posted this early this year, and the discussion by everyone on that HN thread which convinced me of the correctness of the bcrypt approach.

I've already shipped one project which I'm sure at least part of the reason we successfully pitched was our demonstrated indepth understanding of password security requirements.

(I also realised in retrospect that a project I'd designed and specced before reading that article/discussion was going to be wrong in it's password handling, I'm disappointed we never got to build that product, but I'm kinda glad I'm not sitting here thinking "Fuck, what am I gonna do if $project's database ever gets compromised? It'll be just as bad as Gawker...")

Re: How To Safely Store A Password

#146

Post by Xk »

gcr wrote: post #144
Xk wrote: post #127

Earlier quoted context omitted.

If you're talking about why you don't do hash.update(salt) on every round, well it turns out that H(salt || H(H(H(H(H(H(password))))))) is just as strong as H(salt || H(salt || H(salt || H(salt || H(salt || H(salt || H(salt || password))))))). So you don't add any security by doing that. When working with cryptography, "why not also add" is really dangerous, because some times you get less secure systems after doing…

Could you explain a bit more about this?

(Aside: I'm sure that tptacek could give a significantly better answer here than I can, but I'll give it a shot. (And then whenever he answers trust him more than me.))

Assume you have a perfect cryptographic hash function H(X). No matter how many of N bits of X you change (0 Let A = H(salt||password), and let B = H(password). A and B are now, for all practical purposes, two different random integers. Each of which has the same entropy. This is because adding the salt should make no impact on the quality of these random numbers. It should now be fairly easy to see that there is no difference between H(salt||A) and H(salt||B), other than the fact that they produce different outputs.

This is all based on the assumption that the hash function is a perfect one -- however this assumption is reasonable for strong hash functions.

Re: How To Safely Store A Password

#147

Post by burgerbrain »

brown9-2 wrote: post #96
timtadh wrote: post #66

B-crypt and S-crypt are great libraries to use to solve this problem. However, the poor man's approach is as follows with HASH being your favorite hash function h = HASH.new() HASH.update(password) HASH.update(salt) for x in xrange(X): HASH.update(HASH.digest()) return HASH.digest() this approach "strengths" the hash by forcing you to calculate it over and over again. You should set X to be the number of rounds you w…

Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.

Because we all know rolling your own in the crypto world instead of deferring to the experts never leads to catastrophe!

Re: How To Safely Store A Password

#148

Post by wolfhumble »

nkurz wrote: post #84
tptacek wrote: post #49

Earlier quoted context omitted.

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

I can probably top you: some many years ago, I discovered that Network Solutions (the original domain name provider) was using the first two characters of the password as the salt for their user accounts, presumably so that the salt could also be secret. Of course, this had the side-effect of making the first two characters of the password visible in plain text if you looked at the hashes. I reported this as a bug an…

So the salt was just added to the hash without hashing the concatenated hash + salt, i.e was this the method they chose?: saltedhash(password)=hash(password).salt

A part from the obvious flaw of including part of the password in plain text, how secure is this method compared to the following method were the salt is not a secret and were the concatenated hash + salt is hashed?: saltedhash(password)=hash(hash(password).salt)

Re: How To Safely Store A Password

#149

Post by Cushman »

gcr wrote: post #142
Cushman wrote: post #32

I wonder, is it easy to use bcrypt with a variable work factor per-password? I'm thinking you could take your entropy analysis of the user's password and set it so that "weaker" passwords use a higher work factor. This analysis could be easily done before hashing every time the password is input, so an attacker wouldn't be able to single out weak passwords from the hash file. Theoretically, you should be able to tail…

Hm. I don't know about bcrypt at all -- is it possible, given the ciphertext, to know roughly how much work is required to test a password? E.g. an attacker can go "Oh! this password will take FIVE SECONDS to test, so I know it must be a simple password." or "Hey, check this out; this password can be tested in 0.1 seconds. It must be pretty complex." In general, I'd guess that these kinds of information leaks are pre…

Yeah, obviously if you can tell from the hash which class the password came from you lose the benefit.

Re: How To Safely Store A Password

#150

Post by tocomment »

Some everyone is saying how easy it is to crack md5. Say I have an md5 hash and I know it was created from a 1000 byte string. How long would it take to enumerate all 1000 byte strings that could create that hash?
Post reply on HN