Gawker hack causes internet chaos, find out how to secure your users’ passwords

Just a few days ago, it surfaced that the Gawker blog network had had its database accessed by an unauthorised user, with 1.5 million commenter passwords and e-mail addresses stolen, causing a knock-on effect across the social web. While this is a catastrophic security failure in itself, for a number of reasons the situation has actually become a whole lot worse.

“Gawker’s use of DES [hashing algorithm] was a huge mistake. The DES algorithm was shown to be broken as far back as 1992 and was replaced with AES in 2001. This either indicates Gawker’s codebase is old and did not plan ahead of algorithm changes (in all fairness most developers forget to) or the developer that chose the algorithm never kept up with advances in cryptography” says Barry Dorrans, author of Beginning ASP.NET Security. “Cryptographic algorithms expire. As time goes on weaknesses are discovered, or the increase in available computer power makes it possible to brute force by trying every possible value until the right one is discovered.”

In addition to using an outdated algorithm, Gawker were not correctly “salting” their password hashes, a technique used to make it substantially harder to crack hashed passwords given just the hash itself. “There are very few circumstances to keep passwords – authentication to remote systems is the main scenario for this. Keeping passwords, encrypted or not, just to facilitate logging into your own web site is not best practice. Instead you should be stored password hashes, using a strong hash algorithm and a unique salt for each password store to avoid hash lookup tables. When a user logs in you recomputed the hash and binary compare against the stored value. Doing this means is highly improbable that the password can be worked out from the hash”, continues Barry.

As an author and security expert, Barry has provided some useful tips for developers working with user passwords in order to avoid a Gawker-like mess in their future systems.

1. Don’t roll your own cryptography.
2. Don’t store your user’s login passwords, hash them with unique salts and compare hashes.
3. Use “approved algorithms”. NIST is the best source.
4. Plan ahead for algorithm changes – store the algorithm you used with the data it produced.
5. If you must encrypt (as opposed to hash) use the right key length – try keylength.com
6. If you must encrypt ideally use a unique key for each item encrypted. If certain items need to use the same key then always use a unique initialization vector.
7. Hard coding of encryption keys in code or configuration files is simply a stupendously bad idea. Storing them in the same database as the encrypted material is just as silly. Encryption key storage is a hard problem to solve, commercial solutions run into big money. Some operating systems, such as Windows, have secure key storage built in which can be leveraged to store some types of keys
8. If you must encrypt, secure your keys outside of your main system. Preferably on another machine which cannot be remotely administered. Protected by robots with laser guns.