My company has a small team of software developers, who program applications for the business. Nothing too fancy. Sometimes the applications they produce are meant only for system-to-system communication, but more often they are intended to extract data from a system or database and present it to end users in a readable, Web-friendly format. It's my job to make sure those applications are secure. I do this by checking their software with a code scanner, testing their application with vulnerability analysis and penetration-testing tools, and using my eyes to look at the lines of code they've written.
One of the first things I look at when I'm reviewing a new piece of software is authentication. Does it require a username and password? When there is a need for separate user profiles, or users have different levels of authorization to access data in the system, authentication is usually required. And more often than not, that is the case with the Web applications produced by our developers. And of course, the developers don't usually consult with me before they write their code, so any problems I find result in delays and resentment, because when a developer produces an application that does not perform authentication securely, I have to send it back to do that part over.
This happened to me last month. A software developer coded an authentication algorithm using the MD5 hash. MD5 is one of many hashing algorithms available today. Hashing is like encrypting. With the right key, you can decrypt an encrypted value, but you're not supposed to be able to "decrypt" a hash. A hash is like one-way encryption -- you can compare two hashed values, but you shouldn't be able to derive the original data from the hash. That's why hashes are used in password-checking algorithms. The idea is simple: Usernames are stored in a database, but instead of storing the users' passwords there as well, a hash of the password is stored. When the user types his username and password into the application, the username is compared with what's in the database, and the entered password is hashed, and the hash value is compared to what's in the database. This is a tried-and-true technique. So what is wrong?
Encryption and hashing algorithms have a shelf life. And the MD5 hashing algorithm is way past its expiration date.
To find out about how secure various algorithms are, you can rely on the U.S. government. Well, you used to be able to rely on the government. As I wrote in my last column, the National Institute of Standards and Technology shut down its website before I was able to look up the following information, and rather than proceeding to write without facts, I opted to wait until the government reopened and I could reach the NIST website again. Now that the site is back up, I've been able to get my facts straight.
The MD5 hash function is nearly the oldest technology of its type. It was created by private research in 1991 (the dawn of client/server computing as we know it today). The SHA algorithm was designed by the NSA in 1993 as a stronger alternative to MD5. Defined in the FIPS 180 publication that can be found on the NIST website, the SHA algorithms range in strength from 160 bits (SHA-1) to 512 bits (SHA-512).
Due to a flaw in MD5 discovered in 1996, the use of the SHA-1 hash algorithm was recommended as an alternative to MD5 at that time. That was a long time ago in technology evolution. As you can see, MD5 was not considered the best choice for hashing as far back as the late '90s. And in 2004, MD5 was considered "broken."
This means that nobody should be using it today.
As with all cryptographic technologies, the SHA-1 hash algorithm grew weaker over time as computing power strengthened. It was no longer considered acceptable for use in 2010, according to NIST Special Publication 800-131A. Thus, it too should no longer be used today. As you can see, my software developers are more than one generation outdated in their knowledge of these technologies.
SHA-224, SHA-256, SHA-384, and SHA-512 are acceptable for the foreseeable future (the number in the SHA algorithm name refers to the number of bits, which can be thought of as a key length, which as we all know is of critical importance to the strength of the algorithm). Today, SHA-256 is considered the best choice for businesses that need to balance cryptographic strength against computing performance. So that's what I told the developers.
As you can see, MD5 is a poor choice for password hashing and has been for many years. The fact that software developers don't know this underscores the lack of security awareness among programmers, and the need for independent security review.
This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at jf.rice@engineer.com.
Join in
To join in the discussions about security, go to blogs.computerworld.com/security.
Read more about security in Computerworld's Security Topic Center.