

Don't hash passwords? I say yes. Hash them And correctly - cjg
http://securecoding.ch/?p=201001290042267

======
justin_vanw
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>

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

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

~~~
cperciva
_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.

------
cperciva
People use HMACs to derive keys from passwords? Idiots.

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

~~~
cperciva
PBKDF2 uses HMAC the same way that multiplication uses addition.

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

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

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

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

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

~~~
bengiuliano
_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)

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

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

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

------
ElbertF
I usually hash passwords like this:

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

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

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

