Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Security Manager's Journal: Hashing out secure applications

J.F. Rice | Nov. 7, 2013
In-house developers show themselves to be woefully behind the times when it comes to security via authentication.

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.


1  2  Next Page 

Sign up for CIO Asia eNewsletters.