that sounds like all the consulting the big names provide to _yourfavoritegovernmentagencyhere_ in _yourengineeringprojectofchoice_ .
i used to think they did it on purpose, but now i'm starting to think they're just stupid and they actually think they're doing a good job.
A friend of mine sent me a research study on security standards for healthcare and they did suggestions on what to do. it boiled down to this:
in essence all they were saying was use decade old crypto that everyone else already uses, we're just stuck in the past, but i'll make it sound like i just invented something new.
In fairness, decade old crypto is still perfectly good, with the added benefit of being field tested. Now, if we can only get people to use it properly (as in make crypto libraries that do not require a degree in crypto to use properly).
it was just a study. it doesn't mean it'll get used anytime soon. think of it like nist standards. a lot of web developers know about them. but government contractors seem not to. theres plenty md5 and plaintext passwords in the wild.
Gizmo's point is that if only it were easy for developers to simply drop in an old (battle-hardened, field-tested) crypto system into their code, then we'd see much more of that in the wild, and much less md5 / plaintext.
Developers use md5 and plaintext because of laziness. It's not really a conscious choice on their part. They consciously choose to use MySQL vs Oracle, PHP vs .NET, etc, and they spend much more time thinking about those sorts of choices than about security choices.
Maybe some don't realize they're exposing themselves to alarming danger by storing passwords as md5 or plaintext. But I'd bet money that most simply feel that their current solution is sufficient because it "doesn't really matter anyway" since the likelihood of them getting burned by their mistake seems low to to them. So no matter how much you try to make them see that the chance of disaster is in fact alarmingly high, they'll always feel like the chance is low (until their database gets downloaded, and even then they're more likely to rationalize that away as a freak occurrence).
But the root of the problem is the laziness. So we can improve the situation by making it eas(y|ier) to use Crypto libraries properly. If it takes very little effort from average developers to use a crypto library properly, then they're much more inclined to listen. (If it costs them no time, then they're likely to go ahead and use the crypto library instead of a half-baked solution.)
By making it easy to fall into a "pit of success"[1] for crypto, we're only one or two generations of programmers away from making md5 and plaintext password storage extinct.
Unfortunately, it may be impossible to make crypto libraries easy to use without also introducing other (more subtle, yet just as dangerous) security problems, due to the context in which the crypto API is being used. In other words, truly securing an application is Really Hard, which is why tptacek's company (Matasano Security http://www.matasano.com) is so successful.
Probably not so much stupid, as ignorant pressure from above, apathy from below, and Marketing off in la-la land selling fantasies. "Lets build something that compiles and ship it, fuck them if it doesn't do as advertised, how will they know?" thinks the programmer.
i used to think they did it on purpose, but now i'm starting to think they're just stupid and they actually think they're doing a good job.
A friend of mine sent me a research study on security standards for healthcare and they did suggestions on what to do. it boiled down to this: in essence all they were saying was use decade old crypto that everyone else already uses, we're just stuck in the past, but i'll make it sound like i just invented something new.
i wish i could find the link.