The MD5 Security Lesson

 
 
By Larry Seltzer  |  Posted 2009-01-02 Email Print this article Print
 
 
 
 
 
 
 


 

The hash function used in this case was MD5, a rather old function, and one that has been known for years to be subject to collision attacks. Other CAs found by the researchers to still be issuing certificates using MD5 hashes are FreeSSL, TC TrustCenter, RSA Data Security, Thawte and Verisign.co.jp. There have been a series of improved functions introduced over the years, the most famous and common one being SHA-1.

In all likelihood, the non-MD5 certificates the researchers found used SHA-1, and yet these are not safe either. Other research has shown that SHA-1 is probably vulnerable to collision attacks as well, and it's just a matter of time until improved algorithms and faster PlayStations make SHA-1 crackable.

There is a stronger SHA-2 version that uses variable-length keys and thus can be designated as SHA-224, SHA-256, SHA-384 and SHA-512. NIST, the National Institute of Standards and Technology, is holding a competition for a new hash function, to be designated SHA-3, to set a new standard for the future. One submission in the contest is Skein, by Bruce Schneier and many colleagues.

At one level, changing hash functions is easy, but as a practical matter it's a headache. It's like saying that we're going to be switching from Phillips-head to square-head screws, and that you can't use Phillips screwdrivers after some time. It means you have to pull out all the old Phillips screws too. They're everywhere, in places you've forgotten about. The first thing you have to do is stop using the old ones, and this research will probably end the use of MD5 hashes by certificate authorities in very short order, although it's kind of shocking that they were being used at all. Microsoft's SDL (Security Development Lifecycle) urges users to avoid old hashes and to use SHA-256 or later functions.

In reaction to this research, and to the mozilla.com certificate scandal, some people scoff at certificates as "security theater" and claim they don't help even when they work as advertised. I think that's an overreaction and an unhelpful attitude. EV-SSL (which does not allow the MD5 hash) helps by putting the certificate details more in the user's face. It's true that SSL (Secure Sockets Layer) needs more improvements like this so that it can deliver something closer to what people think it delivers. That too will take time.

What does it all mean? The most important lesson of all this is not anything specific about SSL or certificates, but that security standards evolve and users have to move with them. The notion of "If it ain't broke, don't fix it" doesn't work well with security because things are often broken even if there appears to be nothing wrong with them.

I see the same reluctance to change everywhere, including from people who think Internet Explorer 6 is just fine and that Microsoft should continue selling Windows XP forever. With very few exceptions, old software products are insecure ones, and there are limits to what you can fix by patching them. Sometimes you need to throw out the old and move forward.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's blog Cheap Hack.



 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel