On the contrary, "It has not been broken" is exactly what I would expect a programmer to say.
If the security of an algorithm is weakened, then it's important to evaluate the use of the algorithm and make efforts to implement stronger security now. You should feel fortunate that you even get the time to move to something better before all hell breaks loose.
This is the same kind of thinking I hear daily when people say things like, "Just use bcrypt" without thinking about the consequences.
The tendency for programmers to think of security in a nihilistic way continues to boggle my mind. I don't think the article suffers from an alarmist tone. I think it's correct to look at something shitty and call it shit.
I have no idea what this comment is even trying to say. I have no idea what MD5 has to do with bcrypt, and I have no idea what "nihilism" has to do with the fact that HMAC-MD5 isn't broken. We didn't just "discover" that MD5 was weak; Paul Kocher knew it was weak when SSL 3.0 was standardized back in 1996, which is why the SSL 3.0 handshake PRF uses both SHA-1 and MD5.
Yours is the kind of comment anyone can write without knowing anything whatsoever about cryptography, so I'm wary of going into more detail.
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.
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.
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.
> This is the same kind of thinking I hear daily when people say things like, "Just use bcrypt" without thinking about the consequences.
Sorry to say, but "just use bcrypt" is currently the right three word statement that you can use if anybody is asking "I'd like to hash a password, and I don't want to learn all of crypto before I do." Bcrypt is currently among the algorithms that are hard to break if used correctly, deployed widely, has wide support in deployed languages and frameworks and it's fairly simple to use. There's little room for major fuckups here.
There are algorithms that are harder to break (scrypt) or an official standard (PBKDF2), but seriously, bcrypt is currently good enough. Sure, it's always better to read and learn, but sometimes people just have to get things done and I'd rather see them use bcrypt than sha1 or unsalted md5.
> The tendency for programmers to think of security in a nihilistic way continues to boggle my mind.
tptacek is appears to be too modest to say it himself, so I'll go ahead and point it out: He's not "just a programmer", he's a well-respected computer security and vulnerability researcher.
This isn't to say that you should ever simply take his word for stuff, but rather that you are on one hand preaching to the choir, and on the other that you are probably not considering practical effects on security design that he has to wrangle with all the time.
For instance, it's probably a bad idea to hop immediately from one weakened (not even broken) cryptosystem to The New Hotness just because flaws are uncovered, especially for those doing this without thinking of the consequences. For every theoretical security bug you may fix while doing the conversion, you may very well introduce two much practical security bugs.
Cargo cults are bad wherever they are encountered, even when the cult involves something as seemingly as innocuous as "Cryptosystem $FOO has been weakened, time to jump ship".
The parent seems to be implying (taking other comments into account) that people "cargo cult"-ing on ideas like "just use bcrypt" might work now, but it will become a liability in future when bcrypt is weakened or broken (making it more difficult to get people to switch to the next standard practice).
That's odd, I don't think anyone is taking the advice to mean "use bcrypt for ever", I'd imagine that everyone understands that we use it because it's good enough for the foreseeable future.
If the security of an algorithm is weakened, then it's important to evaluate the use of the algorithm and make efforts to implement stronger security now. You should feel fortunate that you even get the time to move to something better before all hell breaks loose.
This is the same kind of thinking I hear daily when people say things like, "Just use bcrypt" without thinking about the consequences.
The tendency for programmers to think of security in a nihilistic way continues to boggle my mind. I don't think the article suffers from an alarmist tone. I think it's correct to look at something shitty and call it shit.