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

61–70 of 110 posts

Re: How To Safely Store A Password

#61

Post by sordidarray »

codahale wrote: post #56
sordidarray wrote: post #47

Earlier quoted context omitted.

I never said SHA-1, a cryptographically insecure hash, was a good choice. It's important to note in your differences that, for the most part, cryptographic hash functions in current use have gotten much slower (e.g., SHA-256 vs MD5), but are also getting much better (SHA-3 competition). The argument I have is this: The passwords that are going to be hitting Rapidshare in your scenario are the crappy or short ones, wh…

Uh. All of the current SHA-3 candidates are as fast or faster than SHA-1. That's one of the contest's design goals: NIST expects SHA–3 to have a security strength that is at least as good as the hash algorithms currently specified in FIPS 180–2, and that this security strength will be achieved with significantly improved efficiency. http://csrc.nist.gov/groups/ST/hash/documents/FR_Notice_Nov0...

Yes, that's why I specifically said, "in current use." No one should be using SHA-3 hash functions. SHA-256 and SHA-1 are much slower than MD5 and very much slower than MD4. The "Getting much better" comment was in reference to speed improvements as well as security improvements (such as removal of vulnerability to length-extension attacks).

Re: How To Safely Store A Password

#62

Post by dfranke »

sordidarray wrote: post #53
tptacek wrote: post #50

Earlier quoted context omitted.

You're arguing for the sake of arguing. The developing weaknesses in SHA-1 don't make it a poor password hash. That's an irrelevant factoid you threw in to cloud the argument. Pick a number of passwords to lose from a table. Hash them with any of the SHA-3 contestants and a "salt": you will lose more. Hash them with bcrypt, you will lose less. Again I'm left asking you: what's your point? What are you trying to prove…

I'm not "arguing for the sake of arguing." I'm trying to explain my point to you, and I'm doing so in a polite manner, which is exactly what I'd expect from you. The weaknesses in SHA-1 make it a poor cryptographic hash, which make it a poor pseudorandom function, which has a significant potential to make it a poor password hash. My point, for the second time, is that you're not "effed" if you use salted hashes. I'm…

All public results against SHA-1 are collision attacks. Password hashing doesn't rely on collision-resistance, only one-wayness. Not even MD5 has any published preimage attacks against it. The known weaknesses in these functions have nothing to do with why they're poor choices for password storage.

Re: How To Safely Store A Password

#63

Post by sordidarray »

tptacek wrote: post #54
sordidarray wrote: post #53

Earlier quoted context omitted.

I'm not "arguing for the sake of arguing." I'm trying to explain my point to you, and I'm doing so in a polite manner, which is exactly what I'd expect from you. The weaknesses in SHA-1 make it a poor cryptographic hash, which make it a poor pseudorandom function, which has a significant potential to make it a poor password hash. My point, for the second time, is that you're not "effed" if you use salted hashes. I'm…

I'd like you to explain how you'd exploit a problem with SHA-1, or, to make it more interesting, MD5 or MD4, to attack a "typical" hashed password (say, Keychain.app "memorable") more quickly than via iterated brute force.

Currently such attacks are infeasible, but there are some very interesting, and very promising families of collision-based attacks (such as herding) which may yield results in that area, although such attacks may only work in specific cases.

Re: How To Safely Store A Password

#64

Post by peterwwillis »

tptacek wrote: post #48
peterwwillis wrote: post #43

I am a crypto noob, so please excuse me if I sound stupid. But why not force your users to pick a password that is at least 8 characters and contains at least one digit, one capitalized letter, one lowercase letter and one special character, then gen a 16-byte salt and run it through SHA-512? The examples given in the article are for 6 lowercase alpha-only characters, which has always been relatively trivial to crack…

Once you go down the road of "not doubting a hacker's ingenuity", you might as well give up and stop applying OS patches. In any case, with "16 byte salts and SHA-512", you're pitting hackers against the folk wisdom of PHP developers. With bcrypt, you're pitting hackers against the IACR. You can't know everything, but you can pick the right battles.

Folk wisdom of PHP developers? I think the creators of crypt() are probably smarter than this.

Password hashes are part of a way to mitigate a particular situation: deciphering a login credential when the password database has been exposed. Shadow files are locked down to root-only because you should never trust people with your password hashes. If somebody has the hash, it's just a matter of time. I don't assume time is on my side.

If bcrypt() somehow makes it near-impossible to brute force password hashes in a "reasonable amount of time", we'd no longer need our shadow files to be root-only. We could give our bcrypt hashes out to the world and say, "Ha! TRY to crack this!" But you don't do that. Because you know deep down in your heart, once that hash is out in the open, the game is over. It's possible someone will crack it so you cannot trust it.

And if someone got access to your locked-down password database, someone is deep enough in your system to have at least read-only access to your password database. Whether or not they can decode the password they probably have other ways of getting whatever it is they really want, which is rarely just an account credential.

I will, however, agree that bcrypt appears to buy you much more time in the event that your password database is exposed. I am skeptical of how much more time that would be under the right circumstances, though, and the potential consequences of CPU exhaustion in the event of some kind of small DoS on the authentication layer.

Also: can you please comment on the original point of my post, which was using a complex password in addition to a fast salted hash? When compared to bcrypt and its purpose/results, is this still an inadequate technical solution, and why?

(edited to make 3rd paragraph not retarded and add request for clarification)

Re: How To Safely Store A Password

#65

Post by KirinDave »

cperciva wrote: post #49
KirinDave wrote: post #44

Earlier quoted context omitted.

In this case, it does. If the client's job is to hash the password then send it to the server for comparison, you've basically got plaintext passwords. They may be quite long, but we're at that place where things don't scale anymore.

Derive a 256-bit key from your password, then send that 256-bit key to the server. Nobody is ever going to perform a brute-force search against the 256-bit derived keyspace, so any attack will need to run the KDF against a list of likely passwords in order to get a list of likely keys.

"Never", huh? Seems to me like an extremely strong statement for a security officer for a major operating system to be bandying about.

Your proposal also treats a 2-way cryptographic function as a 1-way cryptographic function. That is, optimistically, a questionable thing to do.

Re: How To Safely Store A Password

#66

Post by tptacek »

peterwwillis wrote: post #64
tptacek wrote: post #48

Earlier quoted context omitted.

Once you go down the road of "not doubting a hacker's ingenuity", you might as well give up and stop applying OS patches. In any case, with "16 byte salts and SHA-512", you're pitting hackers against the folk wisdom of PHP developers. With bcrypt, you're pitting hackers against the IACR. You can't know everything, but you can pick the right battles.

Folk wisdom of PHP developers? I think the creators of crypt() are probably smarter than this. Password hashes are part of a way to mitigate a particular situation: deciphering a login credential when the password database has been exposed. Shadow files are locked down to root-only because you should never trust people with your password hashes. If somebody has the hash, it's just a matter of time. I don't assume tim…

If you controlled the passwords your users chose, you might be in a position to talk about "strong passwords" combining with "salted hashes" to make a reasonable solution.

Here's a bcrypt hash. Crack it, and I'll donate $200 to the charity of your choice. It's not random, and the cost factor on the hash is not high.

  $2a$14$Dk9dLUH6khBEU3tIHGkNX.6rm6kccRwDUq.bopQ68INbDumal3BiG

Re: How To Safely Store A Password

#67

Post by tptacek »

ErrantX wrote: post #34
kelnos wrote: post #29

Earlier quoted context omitted.

Presumably, bcrypt is something that has been vetted by crypto experts, whereas your idea is just some random thing you thought up. Maybe you personally are a crypto expert and know for a fact that your plan will work, but the vast majority of people aren't. A packaged solution like bcrypt that doesn't give the developer enough rope to hang themselves (and their users) is a much better idea. The idea is a developer w…

whereas your idea is just some random thing you thought up He might also have got the idea from one of tptacek's suggestions not long ago. The difference between doing the iterations and bcrypt is.. well.. not massive in a practical sense. You could do either (if your already MD5'ing passwords once [hmmmm], for example, then it is a quicker solution)

There's a difference: bcrypt (and moreso scrypt) were designed to be hard to speed up, while SHA1 was designed at least in part to be easy to speed up.

But in practical terms, "stretched" SHA1 is fine. I won't bitch at anyone for using it.

Re: How To Safely Store A Password

#68

Post by tptacek »

KirinDave wrote: post #65
cperciva wrote: post #49

Earlier quoted context omitted.

Derive a 256-bit key from your password, then send that 256-bit key to the server. Nobody is ever going to perform a brute-force search against the 256-bit derived keyspace, so any attack will need to run the KDF against a list of likely passwords in order to get a list of likely keys.

"Never", huh? Seems to me like an extremely strong statement for a security officer for a major operating system to be bandying about. Your proposal also treats a 2-way cryptographic function as a 1-way cryptographic function. That is, optimistically, a questionable thing to do.

It's an idea roughly analogous to SRP, which is well-studied. Share a key, then later prove you still know it.

Client-side hashing would be great, if there was a way to do it that didn't involve Javascript.

Re: How To Safely Store A Password

#69

Post by sorbus »

tptacek wrote: post #15
alextgordon wrote: post #7

So say we tone it down to a more feasible 0.01 seconds per hash, or to put it another way, 100 requests per second. That's only 4.8 months to crack that password. There'll certainly be future hardware advances, plus GPUs could be used to bring that down. And you can be sure someone used "password" or "123456". Moral of the story: use long and multiple passwords.

I'm not even checking your math, because that's 4.8 months to crack one user's password . A spectacular win compared to "salted hashes".

I'm sorry if I'm completely misunderstanding, but couldn't a hacker generate a rainbow table once - of all the common passwords, say - and then, once they get a copy of the database in which the password hashes are stored, simply compare them? In the same way that md5 rainbow tables exist, which greatly reduce the computations required when looking for passwords?

Unless, of course, you salt them (which would turn it into 4.8 months to break all the common passwords in a table, building a rainbow table with the salt taken in mind - the only situation in which you're spending 4.8 months per user is if they're each salted differently, for example with the username)- but the article doesn't suggest salting bcrypt, so I'm ignoring that.

Re: How To Safely Store A Password

#70

Post by jrockway »

tptacek wrote: post #17
jrockway wrote: post #16

Earlier quoted context omitted.

Only experts should be allowed to innovate in the security domain. Passwords on lolcats are serious business! We certainly don't want people in the software engineering industry to come up with new ideas, implement them, and see how they work in real life. That could lead to advancement in the field, and that would be bad, because I might have to learn something new. Shudder.

For a significant portion of users, the lolcats password is equivalent to the gmail password, which is game over. But don't let that get in the way of your learning experience, which is simply going to converge on bcrypt anyways.

I know. Don't make anything cool, because someone might misuse it.
Post reply on HN