
Don’t Hash Secrets - davidblair
http://benlog.com/articles/2008/06/19/dont-hash-secrets/
======
imurray
The broader take home message of the article: "Don't invent security protocols
(e.g., involving hashing) as there can be surprising weaknesses. Find a well-
designed library routine that already does what you want."

~~~
Locke1689
"Don't do crypto yourself."

------
cperciva
Quoth the article:

 _That means that if you know SHA1(secret || message), then you can compute
SHA1(secret || message || ANYTHING), which is a valid signature for message ||
ANYTHING. So to break this system, you just need to see one signature from
SuperAnnoyingPoke, and then you can impersonate SuperAnnoyingPoke for lots of
other messages._

This is absolutely incorrect. If you know SHA1(secret || message), you can
compute SHA1(secret || message || padding || anything), which is quite a
different matter. Most useful values of "anything" don't start with such
padding.

Should anyone be designing a system which relies on this distinction for its
security? Of course not. But things are bad enough already without
exaggerating the scope of attacks.

~~~
tptacek
You mean useful values of "anything" not including URLs, HTTP cookies, unicode
comma-seperated lists, and unicode key=value ASCII pairs, where a small amount
of padding isn't going to break anything.

~~~
cperciva
I don't know about you, but I generally don't allow NUL bytes in my URLs, HTTP
cookies, unicode comma-separated lists, or unicode key=value ASCII pairs.

~~~
tptacek
That's because you're a C programmer. Tarnsap may not have this problem, but
Flickr definitely did. I don't know why you think it's a good idea to talk
this problem down; it has already been catastrophically bad for some
applications.

~~~
cperciva
I'm not trying to talk the issue down. I'm just saying that it's bad enough
already without exaggerating it further.

------
antirez
This is what you really want if you care a lot about avoiding the small domain
problem (brute forcing H(myguess) so that I finally find H(myguess) ==
password_hash):

Just use an algorithm that is acceptably slow when used to authenticate users,
but unacceptably slow when using for brute forcing.

For instance

HMAC(1,HMAC(2,HMAC(3,MAC(4,HMAC(..N,HMAC("yourPublicZZaaalt","yourpassword"))))))

Use N big enough so that you need a few milliseconds to run this code as
optimized C.

If you are smart, design it so that CUDA wont help.

Now you are done. Brute forcing will take just too much if the password is not
_too_ obvious. It will be still possible to test 10000 hashes in a reasonable
time maybe, but forget to run John The Ripper against it.

~~~
tptacek
Don't use HMAC, but, sure: iterate SHA1 a couple thousand times. This is the
approach taken by PBKDF.

A better approach is to use bcrypt or scrypt. It's not a security objective of
SHA1 or HMAC-SHA1 to take a long time to run --- in fact, they have the
opposite design goal. Bcrypt and scrypt have both been designed to be
"cryptographically slow": speeding them up in the general case would (forgive
an oversimplification) require a new result in cryptography that would be more
significant than "optimizing brute force cracking".

~~~
antirez
I proposed HMAC just in order to avoid that there is some strange property
about H(H(H(H(H(...))) probably not true for SHA1 and many other believed
secure hash functions and block cyphers.

Btw another slow thing that can be used is Blowfish, as it has a slow key
scheduling stage, but don't know if it's slow enough.

Another approach can be to take any Feistel Network based block cypher and
turn it from M rounds to M*N rounds.

There are many ways to turn a secure cryptographic primitive into a monkey
asses slow cryptographic primitive that seriously limits the effectiveness of
brute force.

~~~
tptacek
Bcrypt is a pessimized version of Blowfish. If you're working at this level of
granularity, it should be for a research paper, not something people actually
use.

~~~
antirez
Ah was not familar with "Bcrypt" thank you very much for the info. I'll look a
bit better into it.

------
brettbender
I feel like this should be titled "Don't hash secrets, unless you actually
know what you are doing."

~~~
gcb
Actually he suggests to use something that he has no clue what it's doing. :)

------
eplanit
Hard to make it past 3 sentences of the arrogant writing style. Such arrogance
usually indicates a lack of expertise. The substance of the article confirms
that.

Yes, it's like "Don't Hash Unless You Really Understand That I'm the Only One
Who Really Understands"

------
jf
Another post on this topic, with links to research papers:
[http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-
has...](http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-
hmac/)

------
codahale
Good god, no. Here is much better advice, in much shorter form:

 _If you're storing a password_ , use bcrypt or I'll bite your thumbs off.

 _If you're making sure something hasn't been modified by someone and you
absolutely can't use a signed GPG message_ , use HMAC-SHA256 and a constant-
time comparison algorithm or I'll bite your thumbs off.

All the business about hash functions is like advice on how to build your own
car brakes using a backyard smelter and a sand cast. You might get something
of roughly the right shape and weight but someone's going to get hurt down the
road.

------
oozcitak
Such articles leave me with the feeling that there are probably a couple
hundred people on earth who truly understand cryptography. The rest of us
either blindly follow them (good thing) or try to understand and apply the
algorithms ourselves (very bad thing). I'd love to see some sort of crypto-
recipes.org site: with a listing for use-cases, recipes underneath and
implementations in different languages. I'm sure crypto experts will look down
on this, but I believe it would greatly benefit the community.

------
nokya
I disagree on that conception...somehow. Can someone explain?
<http://securecoding.ch/?p=201001290042267>

~~~
dazmax
The article says not to hash shared secrets, it does not argue against hashing
passwords (with salts).

~~~
nokya
Oh. It seemed to me the use cases pretty talked about password hashing.

I guess I should re-read :)

