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

101–110 of 219 posts

Re: How To Safely Store A Password

#101

Post by tedunangst »

kd0amg wrote: post #13
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…

Bcrypt is backed by Blowfish, designed by Bruce Schneier. Go look it/him up. It's secure. Well, yes, I trust the Blowfish cipher (and GP probably does too). The question is how we can be sure it isn't being somehow misapplied, i.e. whether the way bcrypt uses it opens some other hole. That's what I (and probably GP) would like to see an expert weigh in on.

What it means to "open a hole" or what a "hole" would even be are hard to imagine in the case of bcrypt.

First of all, none of this security even comes into play until after your password file is stolen, but your and jim's comments imply you believe that using bcrypt would somehow make an existing site less secure.

Re: How To Safely Store A Password

#102

Post by cperciva »

tptacek wrote: post #68
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…

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

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

Re: How To Safely Store A Password

#103

Post by Cushman »

mfukar wrote: post #82
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…

The definition of a "weak" password is so loose it doesn't make sense to make your work factor a function of it. The most common attack on this kind of schemes is a side-channel attack, where you single out a subset of the password alphabet with a relatively small "work factor" and crack passwords which use that alphabet quickly. BCrypt is already based on the premise that there are passwords which are easy to comput…

I see it as a kind of side-channel defense; take the set of passwords which it is possible to crack quickly and use the work factor to even it out so that the total time to crack a password remains relatively constant.

Of course it's a good point that the challenge then becomes determining what that set of passwords is. And not having run the numbers, I can't be sure how much room for improvement there is.

Re: How To Safely Store A Password

#104

Post by kurin »

bostonvaulter2 wrote: post #48

If you have a 5-year old database using a given bcrypt work factor, how difficult is it to transition to a new, higher work factor?

If a user logs in, and their work factor is the low one, authenticate them, and then calculate the new hash with the higher work factor, and save the new hash and work factor.

Re: How To Safely Store A Password

#105

Post by [deleted] »

tptacek wrote: post #49
jmillikin wrote: post #42

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

[deleted]

Re: How To Safely Store A Password

#106

Post by cosgroveb »

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…

Chrome OS is using scrypt!

Re: How To Safely Store A Password

#107

Post by amalcon »

tocomment wrote: post #4

HN, is this the consensus? I thought certain hashes worked fine when properly salted?

The salt does exactly one thing: it makes the attacker pay to get each password, as opposed to making them pay once and get all of them. When the cost is a fraction of a second on a commodity CUDA setup, it's not really that helpful to make an attacker pay it multiple times.

Re: How To Safely Store A Password

#108

Post by eru »

yummyfajitas wrote: post #97
bostonvaulter2 wrote: post #48

If you have a 5-year old database using a given bcrypt work factor, how difficult is it to transition to a new, higher work factor?

I'm no expert, but I think you could just convert a database via function composition: new_hash = (bcrypt new_work_factor) . old_hash -- new hashing function new_hashed_passwords = map bcrypt old_hashed_passwords -- convert the old hashed passwords to new Of course, this will fail horribly if (bcrypt new_work_factor) is somehow an inverse (or partial inverse) of old_hash. It could also fail horribly if (bcrypt new_wo…

But if one of those two properties where true, that would probably give you some hints into how to attack bcrypt.

Re: How To Safely Store A Password

#109

Post by mcgin »

I made an attempt to implement bCrypt on the last web app I built. The problem I found with it is that there was no robust implemention of the algorithm for the tech stack I was using (J2EE) - I'm not sure whether that is the case outside of Java. jbCrypt was the only thing I could find, and if you look at the source, it really is a poor implementation. I could have gone ahead and rolled my own implementation, however I'm no security expert, and much prefer to rely on something more robustt then my own implementation which in all likelihood would have bugs in it.

Re: How To Safely Store A Password

#110

Post by eru »

tptacek wrote: post #41
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,

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…

That argument sounds like the German balloon fliers, who insist that they "fahren" (drive) the balloon and don't "fliegen" (fly) it.
Post reply on HN