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

111–120 of 219 posts

Re: How To Safely Store A Password

#111

Post by Xk »

tedunangst wrote: post #98
jimwise wrote: post #11

Earlier quoted context omitted.

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…

You're speculating about the existence of a flaw which is there no evidence to believe could exist. Just because some crypto constructions are not as sound as naive theory suggests does not mean all constructions are flawed, or even capable of being flawed. bcrypt is not an encryption algorithm. It doesn't "protect" your users' data, so there's no reason to trust or not trust it with their data.

Yes there is. A hash function does protect a user's password.

If you don't believe me, consider this hash function

H(A) = (A>>1)&0xFFFFFFFF

There. Hash function. It sends any input to a 32 bit value. Would you use it for your password though? No. I certainly would not.

Granted, that is an incredibly weak example, but it's one that's easy to see why it's weak, and thus why a hash function does protect a user's data.

Re: How To Safely Store A Password

#112

Post by getsat »

Xk wrote: post #74
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'm curious what the attack is that makes that easier to crack than the Gawker way. (I'm sure you're right, I just didn't know that it would be easier.)

A machine with a few GPUs can compute hundreds of millions of SHA1 hashes per second.

http://www.win.tue.nl/cccc/sha-1-challenge.html

Re: How To Safely Store A Password

#113

Post by tedunangst »

Xk wrote: post #111
tedunangst wrote: post #98

Earlier quoted context omitted.

You're speculating about the existence of a flaw which is there no evidence to believe could exist. Just because some crypto constructions are not as sound as naive theory suggests does not mean all constructions are flawed, or even capable of being flawed. bcrypt is not an encryption algorithm. It doesn't "protect" your users' data, so there's no reason to trust or not trust it with their data.

Yes there is. A hash function does protect a user's password. If you don't believe me, consider this hash function H(A) = (A>>1)&0xFFFFFFFF There. Hash function. It sends any input to a 32 bit value. Would you use it for your password though? No. I certainly would not. Granted, that is an incredibly weak example, but it's one that's easy to see why it's weak, and thus why a hash function does protect a user's data.

ok, that's a fair point. i guess i just believe bcrypt does a better job than that. :)

Re: How To Safely Store A Password

#114

Post by beej71 »

tptacek wrote: post #71
beej71 wrote: post #61

Earlier quoted context omitted.

Bcrypt is better for BOTH those reasons working together; removing either the salt or the variable-cost key scheduler would be Bad. Obviously, the variable-cost key scheduler is the central notion to the thing, but not having a large salt completely nerfs it. bcrypt uses a 128-bit salt, and it uses it for good reason. See the paper, sections 6.2.1 and 6.2.2.

You're not wrong. But a 128 bit salt on SHA1 would do zilch to slow down an attacker. You see my point. I see yours.

Yes... the point I see you making is something like this:

Putting the 128-bit salt on there prevents a precomputed dictionary attack, a constant time operation.

But SHA1 itself is a constant time operation, so having a salt only slows down an attacker in a wall time sense, but not the more important time-complexity sense.

We all agree the salt is not particularly important for the constant time hash. (It's only practically important when the hash takes a lot of wall time relative to the wall time of a precomputed dictionary lookup, and constant time hashes gradually lose this edge due to Moore's Law.)

The point you see me making is that bcrypt is not a constant time operation (due to the variable-cost key schedule--2^cost, actually), and allowing people to use a constant time precomputed dictionary lookup by not having a large salt would make it as bad as no-salt SHA1.

So we all agree that the large salt is vitally important for the non-constant time bcrypt.

Not that either of these points are relevant to my initial assertion that giving the salt to an attacker is not something people worry about. The salt is there to prevent a precomputed dictionary attack, and a large salt does this no matter how well-known it is.

Re: How To Safely Store A Password

#115

Post by shabble »

The part that I don't quite understand about bcrypt and the "scales with hardware speed" claim, is that, as I understand it, validating a password requires 3 parameters; password string, salt, and cost factor.

If you start out now with some given cost factor, that is unfeasibly breakable with modern hardware, that factor will remain stored somewhere, presumably in the database. Once computing hardware speeds up to the point that your factor is now practical to break, you can increase the cost factor for new passwords, but older ones remain susceptible to cracking. The only option would be to re-encode them periodically with the new factor to keep them secure.

Can anyone clarify if I've understood this correctly, or if I'm missing something fundamental about bcrypt? I've looked over the usenix paper, but I can't see anything obvious to confirm one way or the other.

Re: How To Safely Store A Password

#116

Post by tptacek »

cperciva wrote: post #102
tptacek wrote: post #68

Earlier quoted context omitted.

For what it's worth: this is essentially PBKDF2.

Actually, it's essentially PBKDF1, but that's close enough for non-cryptographers.

Shit, you're right. (PBKDF2 generates arbitrary-length output, which is what you want from a key derivation function, but maybe not something you care about for a password hash).

Here's a version that's much easier to read than the spec:

https://github.com/emerose/pbkdf2-ruby/blob/master/lib/pbkdf...

I should stop saying PBKDF2 and just go back to saying PBKDF.

Re: How To Safely Store A Password

#117

Post by asdfor »

Its really simple , AS LONG AS the user uses a weak password, using bcrypt or not wont protect him. Why ? Well instead of brute forcing the hashed password i'll directly try to bruteforce using the normal login method of your site (even if you rate limit my login attempts it wont take that much time...(see proxys)(if you are thinking about rate limiting per username etc you suck).

If you need yours users account to be safe just force them to use a strong enough password

hashed(password + salt) = epic win

Re: How To Safely Store A Password

#119

Post by Strilanc »

shabble wrote: post #115

The part that I don't quite understand about bcrypt and the "scales with hardware speed" claim, is that, as I understand it, validating a password requires 3 parameters; password string, salt, and cost factor. If you start out now with some given cost factor, that is unfeasibly breakable with modern hardware, that factor will remain stored somewhere, presumably in the database. Once computing hardware speeds up to th…

If you're using bcrypt then the client has transmitted the password to you. You can store a higher cost hash after verifying the password against the old hash.

Re: How To Safely Store A Password

#120

Post by Ixiaus »

Xk wrote: post #65
Ixiaus wrote: post #33

Earlier quoted context omitted.

Thanks for the answer and the link. My salting algorithm is very strong but I hadn't considered the idea of renting a bunch of EC2 instances and brute-forcing hashes because the hashing algorithms are so fast.

What do you mean by "my salting algorithm is very strong"?

Instead of just concatenating a salt to the password string, I use a dispersion method. I first concat the salt to the beginning of the password and SHA512 that. I then have a globally configured list in my app (it's different for every app I produce) that defines at which index, in the hashed salt+password digest, chunks of the (same) salt are sliced and interspersed.

Given the same list of indexes, I can then "find" the salt of a stored password hash and run a given plain text password through that algorithm.

But, as has been stated, that effort is completely null if the SHA512 algorithm is fast and brute-forcing it only takes a handful of rented GPU instances...

[EDIT] Now that I think about it, if the Gawker attack were to happen to me, then the attackers would also have the source code and can get the salt dispersion list... So this is, in hindsight, kind of pointless.

Post reply on HN