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

181–190 of 219 posts

Re: How To Safely Store A Password

#181

Post by ams6110 »

burgerbrain wrote: post #179
ams6110 wrote: post #174

Earlier quoted context omitted.

Some projects require FIPS 140-2 compliance. I've not been able to find that blowfish or bcrypt are certified. See http://csrc.nist.gov/publications/fips/fips140-2/fips1402ann...

If a randomly clobbered together and unvetted system is compliant, but bcrypt isn't, that just goes to show how little FIPS140-2 compliance actually means. (as if everybody didn't already know it's worthless)

Nonetheless, some projects mandate use of FIPS 140-2 hashing algorithms, and afaik bcrypt is not one. So if you find yourself on such a project, bcrypt is not an option on the table.

I'd be happy to find out I'm wrong.

Re: How To Safely Store A Password

#182

Post by jbellis »

mcgin wrote: post #109

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, howeve…

I googled [bcrypt api] to see how hard it would be to wrap with JNA (my guess: not very), but the first hit was "jBCrypt - strong password hashing for Java." So I stopped looking.

Re: How To Safely Store A Password

#183

Post by dangoldin »

city41 wrote: post #172

My issue is asking a lot of people to change their password because I've decided to change my encryption algorithm. Is there a best practice for upgrading encryption without forcing users to do that? Something like when the user logs in, hold onto their plaintext password for a bit, confirm it's correct against your current algorithm, and then re-encrypt it with bcrypt?

Good question.

My gut instinct would be to do just that but I wonder if there's a better way. You'd probably also want to track the encryption of each user so you know when you can make the final switch.

Another alternative is to just send "update your password" emails to everyone framing it as an improvement to your site's security.

Re: How To Safely Store A Password

#184

Post by Xk »

gxti wrote: post #163
gcr wrote: post #143

Earlier quoted context omitted.

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?

To nitpick, the topic at hand is pre-image attacks, not collision attacks. Pre-image is where you know the hash and want the plaintext, collision is where you create two plaintexts with the same hash but don't care about the actual hash value. The former is recovering information, the latter is falsifying trust and almost always involves signatures. Collision attacks don't apply to many situations but are much easier…

Wrong. Collisions can be found in MD5 in 2^21 time due to an attack by Xie and Feng. 2^64 is a very respectable number and is not practical for people to do on their home machines. 2^21 is.

Re: How To Safely Store A Password

#185

Post by niktech »

city41 wrote: post #172

My issue is asking a lot of people to change their password because I've decided to change my encryption algorithm. Is there a best practice for upgrading encryption without forcing users to do that? Something like when the user logs in, hold onto their plaintext password for a bit, confirm it's correct against your current algorithm, and then re-encrypt it with bcrypt?

Why not do it behind the scenes?

Simply use the existing MD5/SHA1 hash as input to bcrypt and update all password hashes in your database in one go. Then, whenever the user logs in you first apply the old hash function followed by bcrypt before comparing with what you have in the DB.

Re: How To Safely Store A Password

#186

Post by Seth_Kriticos »

What the article tries to say is, that your password hashing function needs three attributes:

* it has to be dog slow (to make brute forcing hard)

* it should be complicated enough to avoid collisions (this really applies to most hash functions)

* it should be suitably salted, to avoid rainbow tables

-> bcrypt is designed like this, if in doubt, use it

Re: How To Safely Store A Password

#187

Post by rmc »

nitrogen wrote: post #132
dguido wrote: post #56

Earlier quoted context omitted.

Basic version: The salt prevents an attacker from being able to pre-compute a mapping from password hash value. It's most effective when it changes per-password and it doesn't matter if it's public. http://en.wikipedia.org/wiki/Salt_(cryptography)

To make it even more obvious, it's to prevent this (I haven't done SQL in a long while so this may be broken): SELECT username FROM users WHERE password=HASH('secret'); I've seen systems where that statement will give a list of all usernames with the password "secret".

If you use a salt you could still do this 'attack.

    SELECT username FROM users WHERE password = HASH(salt||'secret');
This is academic because you already know the password ('secret').

Salts make rainbow tables (essentially precomputed hash values of (say) all english words) hard and infesiable.

Re: How To Safely Store A Password

#188

Post by joshu »

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

It's not hard to do this (with Ruby bcrypt, it's 2 lines of code using the public interface), but I think you're overthinking it. Most users will use crappy passwords. Set the work factors uniformly high.

Dumb idea:

Have the work factor also be a function of the password itself... this would cause even more difficulty brute-forcing the password, as it means intermediate steps would also have to be tested - breaking one weak password doesn't give you any information about other passwords.

Re: How To Safely Store A Password

#189

Post by StavrosK »

joshu wrote: post #188
tptacek wrote: post #37

Earlier quoted context omitted.

It's not hard to do this (with Ruby bcrypt, it's 2 lines of code using the public interface), but I think you're overthinking it. Most users will use crappy passwords. Set the work factors uniformly high.

Dumb idea: Have the work factor also be a function of the password itself... this would cause even more difficulty brute-forcing the password, as it means intermediate steps would also have to be tested - breaking one weak password doesn't give you any information about other passwords.

I'm not sure about the bcrypt implementation, but if the work factor is public (i.e. you have to know it before calculating the hash), this gives you information about the password, which is bad.

Re: How To Safely Store A Password

#190

Post by StavrosK »

Cushman wrote: post #70
tptacek wrote: post #55

Earlier quoted context omitted.

You're overthinking both the security aspect of this and the performance aspect of it. User-imperceptible hash times are adequate to make most conceivable brute force attacks intractable.

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…

> As it stands today, anyone using one of those is instantly compromised the moment the hash file is accessed.

How? If hashing one password takes one second, and you have a dump of a thousand users, it will take you a million seconds to try just 1,000 common passwords on that list.

Are you thinking of unsalted hashes, perhaps?

Post reply on HN