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

151–160 of 219 posts

Re: How To Safely Store A Password

#151

Post by jasonwatkinspdx »

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…

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 and use a wider range of characters. I can likely ignore all candidate passwords that are shorter or that do not include non-alpha characters.

How useful is this? 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, and in a double whammy, I get to use bcrypt with a low work factor when brute forcing against these rows.

I'm not a cryptographer, and so it's entirely likely I've made some mistake here. But as a general rule, I think it is an _extremely_ bad idea to use cryptography in any way that exposes additional information about individual rows in a database.

Cryptography is not a place for innovative thinking. Even cryptographers need their cleverness to undergo exhaustive review.

Re: How To Safely Store A Password

#153

Post by steveklabnik »

joeguilmette wrote: post #152

I use a different password for every website. It is easy to remember, I just have a portion of my password that changes for every website. For example: dg76fb23S for Facebook, dg76fb23S for hacker news Been working great for years :)

Your Facebook and HN passwords are the same? ;)

And if someone ever sees these in plaintext, it's trivially extrapolate-able to other sites. Dunno.

Re: How To Safely Store A Password

#154

Post by Raphael »

joeguilmette wrote: post #152

I use a different password for every website. It is easy to remember, I just have a portion of my password that changes for every website. For example: dg76fb23S for Facebook, dg76fb23S for hacker news Been working great for years :)

>dg76fb23S for Facebook, dg76fb23S for hacker news

So you use the same password for everything.

Re: How To Safely Store A Password

#155

Post by tptacek »

Locke1689 wrote: post #141
e1ven wrote: post #131

Earlier quoted context omitted.

I don't have a dog in this race either way, but I'm curious what you dislike about Schneier's book.

It's not deep enough to provide true knowledge of cryptography and cryptographic attacks while it also doesn't give practical advice on what to actually do in situations that require cryptography (read: always use high-level primitives). Applied Cryptography is pretty good (if outdated), I think, if you're seeking to gain a beginner-level knowledge of cryptography. Practical Cryptography, on the other hand, is a far…

If you think _Practical_ is outdated (and I'm not saying it isn't), you should come over and let us buy you coffee sometime.

Re: How To Safely Store A Password

#156

Post by Raphael »

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…

What value of X would be good for a web app? 10? 100? 1000?

Re: How To Safely Store A Password

#157

Post by tptacek »

e1ven wrote: post #131
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 don't have a dog in this race either way, but I'm curious what you dislike about Schneier's book.

Quoting me: "Lots of random facts about crypto trivia. Not a lot of context. Even less information about how to actually safely use crypto primitives. You'll come out of it knowing how to get CAST or IDEA into your code --- two ciphers nobody uses anymore --- but not how to properly choose an IV for CBC mode."

Re: How To Safely Store A Password

#158

Post by tptacek »

Raphael wrote: post #156
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…

What value of X would be good for a web app? 10? 100? 1000?

1000 is a minimal value.

Re: How To Safely Store A Password

#159

Post by timtadh »

Raphael wrote: post #156
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…

What value of X would be good for a web app? 10? 100? 1000?

As I said, it depends on how slow you want your server to respond to a given request. For instance, you could set X so high that it takes a minimum of 1 second to respond to a request. That is probably not necessary. The real answer is you need to take the estimated minimum amount of time to calculate one of hash using the function you have chosen. Then compute using that number as the basis the minimum number of rounds to assure reasonable security for a single password. Reasonable security could be it would take 1 year to a do a full dictionary attack alphanumeric only or perhaps 1 month or 1 week. The value you choose for the time it takes to brute force one password is the level of protection you are providing your users.

EDIT: also what Thomas said. It is in the standard that 1000 should be the minimum value. I would use higher based on the level of protection you want to give your users. Note that different hash functions have different costs so this will also impact the choice of X.

Re: How To Safely Store A Password

#160

Post by davebob »

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…

please explain what you mean by rate limiting and why that's no good.
Post reply on HN