How To Safely Store A Password • Hacker News Board

Re: How To Safely Store A Password

#71

Post by tptacek » Tue, Dec 14, 2010, 7:17 PM UTC

beej71 wrote: post #61

tptacek wrote: post #39

Earlier quoted context omitted.

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 .

Bcrypt is better for BOTH those reasons working together; removing either the salt or the variable-cost key scheduler would be Bad. Obviously, the variable-cost key scheduler is the central notion to the thing, but not having a large salt completely nerfs it. bcrypt uses a 128-bit salt, and it uses it for good reason. See the paper, sections 6.2.1 and 6.2.2.

You're not wrong. But a 128 bit salt on SHA1 would do zilch to slow down an attacker. You see my point. I see yours.

Re: How To Safely Store A Password

#72

Post by tptacek » Tue, Dec 14, 2010, 7:19 PM UTC

miGlanz wrote: post #69

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?

Imagine this Python code (I'm using SHA1 iterated multiple times, basically PBKDF2): import hashlib hashed = password for i in range(50000): hashed = hashlib.sha1(salt + hashed) Provided we also store the number of iterations (along with the salt), and provided I didn't do anything stupid above, we could simply add more iterations after these 5 years and update hash and number of iterations field. Would it be a viabl…

Yes.

Re: How To Safely Store A Password

#73

Post by defen » Tue, Dec 14, 2010, 7:19 PM UTC

jmillikin wrote: post #57

tptacek wrote: post #49

Earlier quoted context omitted.

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

No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used. I know there's lots of ways to screw up security, but most of them derive from lazy people taking shortcuts. They run the httpd, database, and authentication all off the same server so a vu…

> No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used.

Anyone can create an input that hashes to a given value. The relevant factor is how long it takes to create that input. I hope you can see the difference between that process taking 3 seconds vs 40 years.

Re: How To Safely Store A Password

#74

Post by Xk » Tue, Dec 14, 2010, 7:20 PM UTC

tptacek wrote: post #63

jmillikin wrote: post #57

Earlier quoted context omitted.

No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used. I know there's lots of ways to screw up security, but most of them derive from lazy people taking shortcuts. They run the httpd, database, and authentication all off the same server so a vu…

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'm curious what the attack is that makes that easier to crack than the Gawker way. (I'm sure you're right, I just didn't know that it would be easier.)

Re: How To Safely Store A Password

#75

Post by miGlanz » Tue, Dec 14, 2010, 7:21 PM UTC

tptacek wrote: post #72

miGlanz wrote: post #69

Earlier quoted context omitted.

Imagine this Python code (I'm using SHA1 iterated multiple times, basically PBKDF2): import hashlib hashed = password for i in range(50000): hashed = hashlib.sha1(salt + hashed) Provided we also store the number of iterations (along with the salt), and provided I didn't do anything stupid above, we could simply add more iterations after these 5 years and update hash and number of iterations field. Would it be a viabl…

Yes.

So the original question remains, is it possible with bcrypt?

Re: How To Safely Store A Password

#76

Post by tptacek » Tue, Dec 14, 2010, 7:21 PM UTC

Ixiaus wrote: post #33

Xk wrote: post #22

Earlier quoted context omitted.

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.

You shouldn't get downmodded for a comment that demonstrates exactly the moment of enlightenment Coda was trying to get people to have about password hashing. Let me fix that for you.

Re: How To Safely Store A Password

#77

Post by kgo » Tue, Dec 14, 2010, 7:23 PM UTC

jmillikin wrote: post #44

whakojacko wrote: post #35

Earlier quoted context omitted.

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…

Config files are not typically world-readable; the httpd reads them before dropping permissions. Otherwise, a vulnerability in the httpd would allow access to everything in the config (remote server passwords, signing keys, etc). There's no reason why compromising the database would allow attackers into the web server, unless you've configured SSH to allow signing in from arbitrary remote systems.

Direct DB access isn't typically world-accessible either. It's not like I can do an XML request to get my hashed password on any site.

The point is, if someone has gotten enough access that they can actually get a raw copy of the database, it's just as likely they can get a raw copy of the config files, or /etc/shadow, or whatever else is on the host system.

Re: How To Safely Store A Password

#78

Post by tptacek » Tue, Dec 14, 2010, 7:24 PM UTC

Xk wrote: post #74

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'm curious what the attack is that makes that easier to crack than the Gawker way. (I'm sure you're right, I just didn't know that it would be easier.)

SHA1 might (I think it is, but I'm not sure) be faster than DES; among other differences, DES crypt(3) has to run the DES key schedule before producing a hash. Data slips through SHA1 like a greased seal.

Re: How To Safely Store A Password

#79

Post by tptacek » Tue, Dec 14, 2010, 7:26 PM UTC

miGlanz wrote: post #75

tptacek wrote: post #72

Earlier quoted context omitted.

Yes.

So the original question remains, is it possible with bcrypt?

I don't know, but Oliver Hunt suggested just validating the password on the next login and upgrading it on the fly, which, to be honest, is what I'd probably do.

Re: How To Safely Store A Password

#80

Post by beej71 » Tue, Dec 14, 2010, 7:27 PM UTC

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?

This is a good practical question. My read of the algorithm is that you must force each user to enter a new password, and encrypt that at the new higher cost.

If you wanted to "upgrade" the passwords to the higher cost key schedule, you'd just continue the key schedule where it left off--but this would require knowing the original password! So that's not really an option.