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

71–80 of 110 posts

Re: How To Safely Store A Password

#71

Post by tptacek »

sorbus wrote: post #69
tptacek wrote: post #15

Earlier quoted context omitted.

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…

No. Bcrypted passwords have nonces in them, just like "salted" hashes. You don't have to think about it. You just use bcrypt.

Re: How To Safely Store A Password

#72

Post by codahale »

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…

You're asking about the relative merit of two hash functions, one of which allows your attacker to test a candidate password in 1 millisecond, the other of which allows the same in less than 1 nanosecond. Using the latter provides your attacker with a 1,000,000x productivity boost. Personally, I'm not that generous.

As far as CPU exhaustion, there are some huge sites which use bcrypt (like, in the top 10)[1]. It is not a problem, provided you choose your work factor carefully.

As far as complex passwords, use them. Try to get your users to use them. But it's an orthogonal concern: your attacker will still be able to work their way through the gigantic keyspace of your monster passwords at 1,000,000x the rate of what they could do if you'd have used bcrypt.

[1] Just looked this up. Not the top 10, but the top 15 for sure.

Re: How To Safely Store A Password

#74

Post by boundlessdreamz »

tptacek wrote: post #71
sorbus wrote: post #69

Earlier quoted context omitted.

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…

No. Bcrypted passwords have nonces in them, just like "salted" hashes. You don't have to think about it. You just use bcrypt.

Complete noob. Can you explain this more. if you bcrypt(12345) isn't the result always same ? If the hash varies then what does the inbuilt nonce depend on ?

Re: How To Safely Store A Password

#75

Post by cperciva »

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.

I am perfectly willing to stake FreeBSD's security on the belief that nobody will ever perform a brute-force search against a 256-bit keyspace.

For that matter, Microsoft, Apple, RedHat, Debian, and Ubuntu all make the same or (usually) even weaker assumptions in their respective packaging and/or updating systems.

Re: How To Safely Store A Password

#76

Post by sordina »

It probably still makes sense to salt before hashing. It might take months to crack a password using bcrypt, but is there something preventing a database of bcrypt hashes being built? (serious question)

Re: How To Safely Store A Password

#77

Post by dschobel »

from the bcrypt page: the other [bit of terrible advice] recommends reversible encryption, which is rarely needed and should only be used as a last resort.

Why is reversible encryption a terrible idea for passwords?

Re: How To Safely Store A Password

#78

Post by pudquick »

dschobel wrote: post #77

from the bcrypt page: the other [bit of terrible advice] recommends reversible encryption, which is rarely needed and should only be used as a last resort. Why is reversible encryption a terrible idea for passwords?

Because it means with , your entire customer base's worth of passwords is now decrypted.

You've now gone from "Even if we get attacked, we've chosen a provably difficult / secure storage method. The damage should be negligible." to "If we get attacked - I hope like hell they don't get ."

An attack is an attack. If they can get in and steal your password database, what's to say that they can't get access to the key that decrypts your reversible database?

Re: How To Safely Store A Password

#79

Post by codahale »

sordidarray wrote: post #57
tsally wrote: post #42

Earlier quoted context omitted.

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information). Are you suggesting that because a comprise is bad, nothing should be done to reduce the magnitude of the impact? This argument does not hold up in general, and it is especially weak when arguing about using encryption algorithms with…

Of course I'm not suggesting such a thing. The effort required to implement bcrypt in new systems is indeed small, and such a method is the suggested way to do, but depending on the amount of users, the effort required to port an existing database over to bcrypt (e.g., Facebook) could be immense, and the result disastrous if not done with great care. Ptacek said, and I quote, "... a crappy web app ..." so why do you…

I should have been more precise in the article. Here:

A system which uses an adaptive hash function like bcrypt is ~6 orders of magnitude less effed in the event of a compromised database than a system which uses a standard hash algorithm and a salt, ceteris paribus.

I would hope you agree that those ~6 orders of magnitude could well be the difference between "not noticeably effed" and "profoundly effed."

Post reply on HN