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

61–70 of 219 posts

Re: How To Safely Store A Password

#61

Post by beej71 »

tptacek wrote: post #39
beej71 wrote: post #27

Earlier quoted context omitted.

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 .

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.

Re: How To Safely Store A Password

#63

Post by tptacek »

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…

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

Re: How To Safely Store A Password

#64

Post by hoop »

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.

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

I think you give people way too much credit. Maybe config files aren't "typically" world-readable but they ARE typically httpd-readable.

It's a mistake to assume, that because you might follow best-practices, the rest of the people out there do. You said yourself in a comment on this same post that many people make mistakes because they're too lazy to take that "half an hour of research." Let's make the assumption that that is typical.

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

Oh, you mean the default behavior? See above.

Re: How To Safely Store A Password

#65

Post by Xk »

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.

What do you mean by "my salting algorithm is very strong"?

Re: How To Safely Store A Password

#66

Post by timtadh »

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 want to conduct. Ie. how slow you want you server to respond to an individual request. It is always a trade-off between server slowness for individual requests and "security" of the hash function. The goal is to make dictionary attacks take longer than is feasible for you attackers to conduct.

[Note: you should absolutely have a different salt for each password with this approach.]

Re: How To Safely Store A Password

#67

Post by tptacek »

dfranke wrote: post #50
tptacek wrote: post #36

Earlier quoted context omitted.

(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 p…

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. Sure they have. A hardware-optimized bcrypt cracker is called a GPU. I can buy a 480-core GPU on Newegg for $350, but it doesn't come with any more RAM than a low-end P…

URL to the source code, please.

Re: How To Safely Store A Password

#68

Post by tptacek »

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…

For what it's worth: this is essentially PBKDF2.

Re: How To Safely Store A Password

#69

Post by miGlanz »

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 viable solution?

Re: How To Safely Store A Password

#70

Post by Cushman »

tptacek wrote: post #55
Cushman wrote: post #51

Earlier quoted context omitted.

Definitely a good point. I feel like it might still help you to avoid wasting time exhaustingly hashing already strong passwords. I mean, how high does that uniform work factor have to be? The guy whose password is "password" or "qwerty12" is gonna get cracked no matter what, sure. But what about people whose passwords are a couple of dictionary words? If the work factor means each hash takes a second or two, even a…

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 100,000 most common passwords? 1,000,000? As it stands today, anyone using one of those is instantly compromised the moment the hash file is accessed. With a truly variable work factor, you could theoretically ensure the safety of any password, regardless of strength.

It obviously gets silly toward the far end (make "password" take three months to hash?) And maybe it gets silly a lot sooner than I'm thinking. But surely it could be pushed back a little, yes? Make one of those 1,000,000 passwords intractable, and you're protecting thousands of users from attack.

Post reply on HN