Don't hash passwords? I say yes. Hash them And correctly(securecoding.ch)

22 pointsby cjgvor 17 Jahren29 comments

Don't hash passwords? I say yes. Hash them And correctly

http://securecoding.ch/?p=201001290042267

6 comments

This is a blog post responding to another blog post. The first one recommended using HMAC in a place where it is totally appropriate to use HMAC. The response seems to miss that point.

To store passwords in a database the 'proper hash' to use is openbsd's bcrypt. http://www.openbsd.org/papers/bcrypt-paper.ps

fexlvor 17 Jahren

One minor issue, I think. I noticed on page 7 it says:

  bcrypt(cost, salt, pwd)
    state <= EksBlowfishSetup(cost, salt, key)

I guess the symbols "pwd" and "key" are synonyms there, right?

justin_vanwvor 17 Jahren

Well, the good news is that this paper is old, and bcrypt is readily available for most languages, including Ruby, Python and Java (and of course C).

travispvor 17 Jahren

That first blog post recommended using HMAC for communicating between applications, but then he said that he uses and recommends HMAC to store passwords in his database as well. I think that's what this post is responding to.

justin_vanwvor 17 Jahren

I agree, that would be a bad idea. I should have read the original more carefully.

cynicalkanevor 17 Jahren

Is there a PDF version of this? Or a way to read PS without installing new software? I'm on a computer that is not mine.

cynicalkanevor 17 Jahren

Actually, after some googling, I've discovered a sequel to bcrypt:

http://www.tarsnap.com/scrypt.html

This algorithm is not only provably computationally hard, but provably requires a lot of RAM. Since RAM, and the bandwidth thereof, (unlike password-cracking chips) is as cheap to the consumer as it is to the NSA, you can set your RAM requirements very high to give them a very hard time.

cpercivavor 17 Jahren

This algorithm is not only provably computationally hard, but provably requires a lot of RAM

Almost right. There is a lower bound on the time-area product, but not a significant lower bound on the area.

tvonvor 17 Jahren

I'll keep this up for a bit:

http://civicit.com/~tvon/files/bcrypt-paper.pdf

imurrayvor 17 Jahren

Is there...a way to read PS without installing new software?

It's not great compared to say Google's viewer for PDFs, but here is a long-standing service that works: http://view.samurajdata.se/

cpercivavor 17 Jahren

People use HMACs to derive keys from passwords? Idiots.

randombitvor 17 Jahren

PBKDF2 uses HMAC. What's the issue here? A PRF seems the right tool for this particular problem, and HMAC happens to be a PRF that has well understood properties.

cpercivavor 17 Jahren

PBKDF2 uses HMAC the same way that multiplication uses addition.

randombitvor 17 Jahren

So your objection here actually has nothing to do with HMAC at all, but with doing password hashing without iterations?

cpercivavor 17 Jahren

My complaint is about using a fast PRF where they should be using a slow PRF, yes.

oconnorevor 17 Jahren

Question: All of these discussions are based on the hacker having access to your database. If you really don't trust your hosting company not to leak your database details, why do you trust them not to overwrite your administrative password with an appropriately salted bcrypt/whatever hash?

shin_laovor 17 Jahren

There is a difference between being able to dump tables and being able to alter tables. Generally a lot of people have read access to the database, very little have full write access.

The same goes with hacks. It's easier to get unauthorized read access than unauthorized write access.

ErrantXvor 17 Jahren

> if you really don't trust your hosting company

That is not the case this protects against

DenisMvor 17 Jahren

1. Most users use the same email/userid and same password across variety of sites. A compromise of your site should not automatically compromise all other sites.

2. Backups have tendency to leak more so than the server security itself.

danskilvor 17 Jahren

So, if you have a hash, and your salt gets compromised, is there a way to re-salt without losing all old passwords? I'm thinking specifically of frameworks like rails where you can have hashes applied auto-magically.

mseebachvor 17 Jahren

In "olden times" (I guess around the fourth empire), common wisdom was to hash like this:

salt = getLongRandomString(); hash = sha256(salt+password); save_in_db = salt+"$"+hash

Thus, while you don't publish them, salts aren't "secret". That's based on the assumption that a cracker would have to bruteforce each password in turn, and that takes too much time.

But no, you can't re-hash with a new salt without access to the plain-text password. If you could, so could the bad guy :)

Disclaimer: IANAC, and if I were building security for mission critical stuff, I'd ask someone who was.

bengiulianovor 17 Jahren

But no, you can't re-hash with a new salt without access to the plain-text password. If you could, so could the bad guy :)

Yes you can, if you believe this: http://benlog.com/articles/2008/06/19/dont-hash-secrets/ This is exactly why HMAC is more complicated than just:

    hash(message+secret)

tptacekvor 17 Jahren

It's H(k, m) that's trivial to break, not H(m, k) (where the attacker has no control over the final block of the hash). H(m, k) is also much weaker than HMAC, but in trickier ways.

amalconvor 17 Jahren

A "salt", unlike most uses of a nonce, doesn't derive its benefits from secrecy. The only* benefit of the "salt" is essentially to prevent birthday attacks on your password database, since any attacker with the passwords probably also has the salts.

*-Not strictly true. If a user is rotating through a sequence of passwords, changing the salt will obscure that.

wizard_2vor 17 Jahren

You could probably write something to expire the salt and next time that user logs in providing their plain text password a new salt could be generated and a new hash could be saved.

DanielStraightvor 17 Jahren

The author admits to having little math ability and makes cryptographic recommendations anyway? Cryptography is math. If you don't know math, you don't know cryptography.

judofyrvor 17 Jahren

Well, he probably knows how to write the letters A-E-S and we all know what that means…

ElbertFvor 17 Jahren

I usually hash passwords like this:

    $hash = sha1('foo' . $username . $password);

Can someone explain to me why or when this isn't good enough?

enntwovor 16 Jahren

The author is arguing that it is good enough, and going any farther is unnecessary complicated. However, the use of a static salt or modifier, in this case "foo" does not change much if anything to the attacker. All portions of the salt should be random based on the user or account, so that for each individual account, an entire rainbow table would have to be created, which even with distributed cloud computing would be too expensive.

There was an article linked a while ago that plotted prices to crack common hashes using Amazon's cloud, and even for 8 length alphanumeric + symbol it was over $50,000 of estimated computing, adding a significant unique salt (username in this case) would make it unjustifiable from a monetary point of view.