Hacker News Reader

Comment by echohack | Hacker News Reader

Apologies. Perhaps I'm being a master of the obvious here, so I'll restate more simply:

When people try to implement security without actually thinking about what the system is doing, it creates weaknesses in the security, not due to algorithmic weaknesses, but because the organization and the engineering discipline for the future is compromised. Thus, while "just use bcrypt" or "just use HMAC-MD5" might work today, the organization doesn't have the mind to update it when it finally does break.

This is exactly what happened (and is still happening) today after MD5 was broken.

View on HN

This is the same comment with fewer words, and while I appreciate the concision, it doesn't make any more sense to me.

Bcrypt isn't broken or even weakened.

HMAC-MD5 isn't broken.

HMAC-MD5 and bcrypt are unrelated.

Nobody is ignoring the problem of MD5; in fact, suspicion about MD5 animates the very first secure SSL specification we have, from almost 20 years ago. Nobody is saying "just use HMAC-MD5".

I think what he is saying is that many individuals and organizations will not learn the fundamentals behind why X is broken, they only learn "X is broken use Y instead."

They instead should learn that Y is also potentially broken in a given circumstance - and maybe that doesn't apply to my current situation but I need a review process to check that it still doesn't apply to me at a given time in the future.

For someone designing a cryptography application, this understanding should be very deep. I don't think it needs to be as deep for someone who is configuring their Apache server and just needs to know what ciphers to enable and which ones to prefer. In this case it is best to follow an industry best practice based on the type of data being sent over the wire and the compatibility/performance required by the clients/users. Then schedule an annual or quarterly review of those choices to make sure they don't go out of date and keep an eye on security bulletins in case one of them is severely broken.

What he's saying is these blanket statements "just use X" is what is broken. Sometime ago it was "just use md5" and we're still suffering through the fallout of that long after md5 has been shown to be broken. Now we're pointing everyone in another direction and at some point that will be broken too. His point is that we need to educate people on the reasons why one algorithm is better than another for certain security concerns rather than relying on blanket catch-all declarations.

And now I'd like to say for the third time that no, there was no "just use MD5" meme in cryptography or in software development, and if TLS is an illustration of anything, it's of not simply leaning on MD5. Once again: the TLS protocol itself is not vulnerable because of MD5, and it's not vulnerable because its designers and implementors both knew about and accounted for the weaknesses of MD5.

The author took the opposite lesson from TLS than the one that it actually demonstrates, and the commenter above is harping on that broken lesson.

As a computer scientist, it's a joy to discover when you're wrong about things. So I'm enjoying being on the wrong side of the discussion for once, because I'm learning lots.

Thank you for your replies tptacek, I've learned much from this discussion. If I could edit my top comment, I would.

Has anyone said "just use MD5" to someone who wasn't about to use CRC32 instead?

Doubt about this exact case, but I've seen MD5 being (ab)used in a really weird ways, which I attributed to mindless "oh, I'll just use MD5 here, heard it's good for security!"

One particular case I remember was use of md5(md5(md5(unix_timestamp()))) to generate "secure" session tokens.

That scheme would be insecure even if it was SHA3(SHA2(SHA1(unix_timestamp()))

Reply on news.ycombinator.com