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

31–40 of 219 posts

Re: How To Safely Store A Password

#31

Post by tzs »

sph wrote: post #26
tocomment wrote: post #4

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

The problem is that it's relatively easy to brute-force attack even a salted hash today. On the first day, people stored passwords in plain text. If someone got access to your database, they had all the passwords. On the second day, people decided to hash the passwords so that people couldn't unencrypt them. Then the attackers created rainbow tables that correlated each hash with its associated password since the pas…

Salting was introduced long before rainbow tables were invented.

Re: How To Safely Store A Password

#32

Post by Cushman »

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 tailor the numbers so that cracking a weak password isn't any faster than cracking a strong one, right? Plus it will encourage your users to use a stronger password in the first place, since it'd make login slightly faster.

Any obvious problems with this plan?

Re: How To Safely Store A Password

#33

Post by Ixiaus »

Xk wrote: post #22
Ixiaus wrote: post #15

Earlier quoted context omitted.

Question, I use SHA512 for my passwords; is that also "fast" in comparison to bcrypt?

SHA512 is very, very fast compared to Bcrypt. It's only slightly slower than SHA1 or SHA256. Source: http://www.cryptopp.com/benchmarks.html

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.

Re: How To Safely Store A Password

#34

Post by [deleted] »

izak30 wrote: post #29
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…

I may be mistaken, as I was only browsing. I was looking at Django's auth system last night (as all of this had me curious about the backend). I don't think that SECRET_KEY is used for part of the salt at all, I think it's primarily used for validation of site-generated data, signing requests, and cookie encoding/decoding.

[deleted]

Re: How To Safely Store A Password

#35

Post by whakojacko »

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…

Why are you storing the whole salt in your database? Isn't it much more common to keep half of it in a configuration file? I know Django has a SECRET_KEY parameter for this sort of thing, and hopefully other frameworks do also.

How is that really any better? You should assume that if an attack can get to your database, they can get to your web servers and take all of that as well. Such a scheme certainly wouldn't have saved Gawker.

Re: How To Safely Store A Password

#36

Post by tptacek »

khafra wrote: post #20
kd0amg wrote: post #13

Earlier quoted context omitted.

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.

Bcrypt is recommended by all the relevant experts who haven't heard of scrypt(1). Those who have(2), use scrypt because it's got a better built-in Moore's Law-defeater than bcrypt. (1) http://news.ycombinator.com/item?id=601408 (2) http://www.chromium.org/chromium-os/chromiumos-design-docs/p...

(a) Virtually nobody has heard of scrypt; contrary to HN conventional wisdom, Colin is not yet a world-famous cryptographer. Give him time.

(b) There are operational reasons not to use scrypt, one of them being that there is no reference implementation with broad language bindings.

(c) The specific improvement scrypt makes over bcrypt is not yet relevant; nobody has ever hardware-optimized a bcrypt cracker, and the project that successfully does so and publishes their results will have made a contribution to cryptography literature.

(d) Even when bcrypt starts to face down hardware crackers, it doesn't "lose"; you simply have to increase work factors to compensate.

(e) You don't even have to use bcrypt; you can use PBKDF2, which simply iterates SHA1 a tuneable number of times. Bcrypt is better than PBKDF2, but every adaptive hash, PBKDF2 included, is in a different and better league than "salted hashes".

Re: How To Safely Store A Password

#37

Post by tptacek »

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.

Re: How To Safely Store A Password

#38

Post by jhchen »

whakojacko wrote: post #35
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…

Why are you storing the whole salt in your database? Isn't it much more common to keep half of it in a configuration file? I know Django has a SECRET_KEY parameter for this sort of thing, and hopefully other frameworks do also. How is that really any better? You should assume that if an attack can get to your database, they can get to your web servers and take all of that as well. Such a scheme certainly wouldn't hav…

In Gawker's case this is exactly right. The database AND the source code was accessed so the config file defense would not have worked.

Re: How To Safely Store A Password

#39

Post by tptacek »

beej71 wrote: post #27
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…

If you want to crack passwords ultrafast, you make a look-up table of the hashes of all probable passwords. Without a salt, this is rather a smaller table. A 7-bit salt makes the table larger, but not hugely larger, and not troublesomely larger. The 128-bit salt used by bcrypt makes the table intractably hugely large. You cannot precompute it. Of course, you know the salt (because it's stored right there in /etc/shad…

Those password crackers that are belting through billions and billions of passwords an hour with just a couple of video cards aren't using rainbow tables, are they? You could have zero bit salt: you're still boned.

Bcrypt is not better because it has a better salt. It's better because one iteration of bcrypt takes a long time, and millions of iterations take an intractably long time.

Re: How To Safely Store A Password

#40

Post by tptacek »

tzs wrote: post #31
sph wrote: post #26

Earlier quoted context omitted.

The problem is that it's relatively easy to brute-force attack even a salted hash today. On the first day, people stored passwords in plain text. If someone got access to your database, they had all the passwords. On the second day, people decided to hash the passwords so that people couldn't unencrypt them. Then the attackers created rainbow tables that correlated each hash with its associated password since the pas…

Salting was introduced long before rainbow tables were invented.

Salting was introduced in the 1970's to combat the underlying class of attacks that rainbow tables optimize. Think of rainbow tables as a compression scheme; the attack is precomputation.
Post reply on HN