Don’t Hash Secrets

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

Quoth the article:<p><i>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.</i><p>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.<p>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.

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):<p>Just use an algorithm that is acceptably slow when used to authenticate users, but unacceptably slow when using for brute forcing.<p>For instance<p>HMAC(1,HMAC(2,HMAC(3,MAC(4,HMAC(..N,HMAC("yourPublicZZaaalt","yourpassword"))))))<p>Use N big enough so that you need a few milliseconds to run this code as optimized C.<p>If you are smart, design it so that CUDA wont help.<p>Now you are done. Brute forcing will take just too much if the password is not <i>too</i> obvious. It will be still possible to test 10000 hashes in a reasonable time maybe, but forget to run John The Ripper against it.

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

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.<p>Yes, it's like "Don't Hash Unless You Really Understand That I'm the Only One Who Really Understands"

Another post on this topic, with links to research papers: <a href="http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/" rel="nofollow">http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-has...</a>

Good god, no. Here is much better advice, in much shorter form:<p><i>If you're storing a password</i>, use bcrypt or I'll bite your thumbs off.<p><i>If you're making sure something hasn't been modified by someone and you absolutely can't use a signed GPG message</i>, use HMAC-SHA256 and a constant-time comparison algorithm or I'll bite your thumbs off.<p>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.

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.

I disagree on that conception...somehow. Can someone explain? <a href="http://securecoding.ch/?p=201001290042267" rel="nofollow">http://securecoding.ch/?p=201001290042267</a>