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

171–180 of 219 posts

Re: How To Safely Store A Password

#171

Post by asdfor »

Raphael wrote: post #165
asdfor wrote: post #117

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 b…

I think rate limiting per user is perfect. And if the real person wants to log in while someone else used up their attempts, do a quick email confirmation.

"do a quick email confirmation". And what happens if one or more of your users gets targeted for a long period of time ? You will force them to open there inbox every time they want to log in your site ? And this gets even better if they target your site generaly, it will be a lot of fun for the majority of your userbase to have to do that "open inbox" step, bet users will love it :)

Sorry mate but your method sounds easily exploitable ... heck using reCaptcha would be less punishing for the user than your approach.

Re: How To Safely Store A Password

#172

Post by city41 »

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?

Re: How To Safely Store A Password

#173

Post by Xk »

alanh wrote: post #162
jasonwatkinspdx wrote: post #151

Earlier quoted context omitted.

This exposes information about the password: namely it's estimated entropy. The bet you're making is that the increased work factor overshadows any advantage an attacker may gain knowing that information. How could someone use this? Well, I could decide to only target the rows with a low work factor. Since your entropy estimate is high for these rows, I can know that it's more likely they'll be 8 characters or longer…

If I’m remembering my discrete math correctly, your claim isn’t correct: > … Let's assume 2 choices of work factor. Also let's assume strong passwords of length 8 have 96^8 ~= 53 bits of entropy and eak passwords of length 8 or less have 27^8 ~= 38 bits of entropy. > You just let me cut the search space for strong passwords of length 8 to to ~15 bits… You can’t subtract bits of entropy like that. Here’s something I h…

You are correct: 2^10 - 2^5 != 2^(10-5); which is what he is doing by subtracting the entropy.

Re: How To Safely Store A Password

#174

Post by ams6110 »

brown9-2 wrote: post #96
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…

Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.

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

Re: How To Safely Store A Password

#175

Post by rorrr »

gcr wrote: post #142
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…

Hm. I don't know about bcrypt at all -- is it possible, given the ciphertext, to know roughly how much work is required to test a password? E.g. an attacker can go "Oh! this password will take FIVE SECONDS to test, so I know it must be a simple password." or "Hey, check this out; this password can be tested in 0.1 seconds. It must be pretty complex." In general, I'd guess that these kinds of information leaks are pre…

Doesn't matter. 5 seconds or 0.1 seconds per test means that you cannot brute-force. Even for 5-letter English lowercase letters your search space is 11,881,376 combinations. At 0.1 sec/try it will take you 6.8 days on average to find just one password.

Re: How To Safely Store A Password

#176

Post by brown9-2 »

burgerbrain wrote: post #147
brown9-2 wrote: post #96

Earlier quoted context omitted.

Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.

Because we all know rolling your own in the crypto world instead of deferring to the experts never leads to catastrophe!

You assume those are the only two choices, I was considering that in some environments these might be the only two choices when I asked the question.

Re: How To Safely Store A Password

#177

Post by [deleted] »

ams6110 wrote: post #174
brown9-2 wrote: post #96

Earlier quoted context omitted.

Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.

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

[deleted]

Re: How To Safely Store A Password

#178

Post by IgorPartola »

niels_olson wrote: post #118

Fun fact: this has been posted to Hacker News before, when it first came out. I think most would agree this is a great example of why re-posting should be allowed. http://news.ycombinator.com/item?id=1091104

I admit I games the system a bit to re-post this link, but it seemed very relevant. I learned a ton from this discussion, so my selfish reasons were met.

Re: How To Safely Store A Password

#179

Post by burgerbrain »

ams6110 wrote: post #174
brown9-2 wrote: post #96

Earlier quoted context omitted.

Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.

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)

Re: How To Safely Store A Password

#180

Post by retroryan »

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…

What did you end up using? What are good solutions on a java platform?
Post reply on HN