At the other end of the spectrum, you have satellite TV. In this area, a lot of money invested and full control of the playback platform have resulted in some strong systems. But still, it took a long time and a lot of cracks of intermediate systems for this industry to become the success story it is today.
Disclaimer: I worked for a company involved in the above.
http://www.securityfocus.com/news/143
--------
But DirecTV reacted to that wrinkle over a year ago, by taking advantage of their ability to remotely reprogram the set top satellite receivers, as well as the cards. The company sent a few specific bytes of data to all the H cards, while simultaneously reprogramming the satellite receivers to reject cards that didn't reflect the change. This forced hackers to update the cards manually with the new data, or to make the cards writable again.
--------
With a combination of technology (latest generation smart cards and cryptography) and litigation (going really strongly against infringers) has made DirecTV uncrackable in practice.
The fact that here in Mexico I cannot find someone selling a fully unlocked US smartcard shows that in a way DirecTV has won.
It used to be the case that for US$300 you could buy this fully unlocked DirecTV card to watch all USA channels here in Mexico. This was about 10 years ago when I was in college (and my flatmate used to buy that stuff).
That is all.
Actually, 13 of them.
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.
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.
[1] - http://www.codinghorror.com/blog/2007/08/falling-into-the-pi...
3DES is decades old and absolutely not acceptable today.
What's impressive is how long silly schemes (this one in particular) stay afloat!