Don’t Hash Secrets (2008)

http://benlog.com/articles/2008/06/19/dont-hash-secrets/

by pizza • 13 years ago

78 34 13 years ago

lmm• 13 years ago

Not a very helpful way to express the advice; if you tell people "don't hash secrets" the natural interpretation is "send them in the clear".

HMACs have their use case, and it's good to use them for that, but honestly it's a tiny corner of the possibilities for "hashing secrets", and an effective approximation (hash(message + hash(secret)), as mentioned towards the end of the article) is the obvious approach if you have any idea how hashes work, and just as effective as a dedicated HMAC.

Skalman• 13 years ago

I think the point is that that is not necessarily true for all hash functions, since reordering your example with SHA1 renders it weaker.

If I understood correctly sha1(sha1(secret) + message) is not safe, because from that hash you can calculate sha1(sha1(secret) + message + ANYTHING)

Mindless2112• 13 years ago

So why not sha1(sha1(secret) + sha1(message))? Or is that essentially an MAC?

tptacek3• 13 years ago

Correct; H(H(secret) || message) just scrambles the secret, but doesn't change the MAC construction.

jessedhillon• 13 years ago

...if you tell people "don't hash secrets" the natural interpretation is "send them in the clear"

What? When you see a sign by the pool that says "Don't Run" do you get down on your belly and start crawling? Some assumptions are safe to make -- e.g. most people who care enough to read this know not to send secrets in the clear.

StavrosK5• 13 years ago

Not a very helpful way to express the advice; if you tell people "don't hash secrets" the natural interpretation is "send them in the clear".

Yeah, a better title would be "Don't just hash secrets."

kmm• 13 years ago

It's terrible advice, just like that "Don't do cryptography" from some time ago. It just seems like people are trying to be too clever. I admit I learned something, but the tone of the article could be better.

baddox• 13 years ago

I don't think that anyone who understands what "hashing secrets" means would think that "don't hash secrets" means "send them in the clear."

bjt• 13 years ago

This article is right for the case of using HMACs for two parties checking the authenticity of a message passed between them (assuming they have a shared secret).

But it's wrong about the database password storage. These days the real threat there is the monstrous computing power available to compute tons of hashes simultaneously. To combat that, you want a hashing function specifically designed to be slow. And not just slow, but to have a tunable parameter so you can require more and more work as GPUs get faster and cheaper. PBKDF2 is such a function, and is used by Django as of a year or two ago. bcrypt is another.

ukd1• 13 years ago

This. Use bcrypt or scrypt for storing secrets. HMAC is for...hash(ing) message authentication code(s); read: http://security.stackexchange.com/questions/16809/is-a-hmac-...

gohrt• 13 years ago

In fact, I use HMAC for my password databases, too. It’s overkill, but it lets me use a standard library that likely makes me safer in the long run.

Actually, it's underkill. HMAC is too easy to crack to be used as a password hashing scheme.

http://security.stackexchange.com/questions/16809/is-a-hmac-...

http://security.stackexchange.com/questions/3165/hmac-why-no...

tptacek3• 13 years ago

Fun fact: it was a design goal of the SHA-3 competition not to have the hash be vulnerable to length extension attacks, which obviates the need for constructions like HMAC that apply the hash function twice.

oconnore• 13 years ago

Sufficiently truncated hashes (SHA-384, SHA-512/256, SHA-512/224) in the SHA2 family should have the same property, right? You need the missing state to extend.

JoachimSchipper3• 13 years ago

Yes, but that's a hack, and not nearly as well-studied as HMAC or SHA-3. If you decide to do it this way, at least be sure to make it very obvious that "upgrading" to SHA-512 completely breaks your cryptosystem.

Dylan16807• 13 years ago

Yeah, this article is honestly painful to read with it's repetitive 'duh' style that doesn't apply to half the hash functions out there.

Hell, you could take the 'use bcrypt' meme out of context and you'd be fine.

maaku2• 13 years ago

Here’s the deal: if I tell you that SHA1(foo) is X, then it turns out, in a lot of cases, to be quite easy for you to determine what SHA1(foo || bar) is. You don’t need to know what foo is. It’s just that, because SHA1 is iterative and works block by block, if you know the hash of foo, then you can extend the computation to determine the hash of foo || bar.

This is simply wrong. Padding of cryptographic hash functions protect against this behavior.

pbsd3• 13 years ago

It is not simply wrong. The usual Merkle-Damgard padding only means that you get something like SHA1(foo || garbage || bar) instead, garbage being smaller than the hash's block size.

maaku2• 13 years ago

Maybe disingenuous was a better word. The "garbage" in the middle still protects against most (though not all) attacks.

rpearl• 13 years ago

Say it with me one more time: do not use fast hash functions for passwords.

StavrosK5• 13 years ago

Okay, not to put anyone off crypto, as it's really really important, but the one rule everyone needs to remember: Use the current best practices for each situation, don't make up your own crypto.

This usually means "use whatever is in OpenSSL, Keyczar, etc", that's what it's for.

mikegagnon• 13 years ago

The article makes the point that it is insufficient to use good crypto algorithms / implementations. You must also use it correctly.

"A component can only be secure under certain well-defined circumstances, not for any use that happens to look similar."

StavrosK5• 13 years ago

A hash is a crypto primitive, it's not what you use for that. If you want to store a password, you use a KDF. If you want to fake-sign, you use an HMAC with a secret. You don't use a hash, just like you don't use plain AES to encrypt a file.

theboss• 13 years ago

But he is hashing secrets. Salted and Hashed passwords are extremely important...and saying "Don't Hash Secrets" is just an attempt to get him more traffic.

There is another important aspect to salting that he neglects to say. Adding an 8byte salt is extremely effective (along with a proper password hashing algorithm) in increasing the complexity of generating and storing rainbow tables. PBKDF2 and bcrypt are both slow enough to protect a lot of that low hanging fruit that he is saying ISN'T protected....Sure if you use SHA1....they might get some of them....but everyone agrees you should not be using SHA1 ! (for passwords).

kGrange• 13 years ago

On salting, the author says that an attacker needs to rebuild the dictionary for each user they attack.

But doesn't the attacker only need to rebuild the dictionary once, using the salt they recovered?

fywacro• 13 years ago

The salt is different for EVERY secret. When you hash/store a new password, you randomly generate a salt for THAT password, and you store each salt & password together.

Because each salt is ~unique, the attacker must rebuild a separate dictionary for every single stored secret. That's functionally the same as having no dictionary, at all.

Myrmornis• 13 years ago

OK I have a probably naive cryptography question. It seems that one good way of transmitting secrets would be to do so with everyone thinking they are encrypted one way (or possibly not at all) when the truth is they are encrypted another way. I.e. a difficult problem to know when the message has been unencrypted. So basically there would be multiple ways to read the message which are plausible as the true unencrypted message. Is there any parallel to that sort of thing in modern cryptography?

Don’t Hash Secrets (2008)

Related Stories