There have been a flurry of posts about Gawker Media servers being broken into. Most articles have stayed above the technical details of how this happened, but after analyzing the actual data files in question, it appears the issue was Gawker’s reliance on Symmetric Encryption, specifically the DES cipher, and using it seemingly without salt.
When building an authentication system, it is common practice not to store the actual password (e.g. “opensesame”) but instead to store an encrypted or obfuscated version which can be confirmed against the password but cannot be used elsewhere. The standard operating procedure is to employ a cryptographic hash, a one-way function that cannot be deciphered. A layman’s example of a hash function might be hash(word) = (number of vowels) + (number of consonants), so hash(opensesame) = 5 + 5 = 10. As you can see, if someone submitted a password like “letmein” or “password” or “123456,” the system could count the vowels and consonants and determine whether there was a match, but do so without actually storing “opensesame” at all. Then, if miscreants broke into the database, they would know that your password has 5 vowels and 5 consonants, but they wouldn’t know the actual password, and if they tried to log into your Gmail or WordPress or Bank of America site they’d still have quite a task ahead of them.
Unfortunately, in this case it appears that instead of a one-way hash function, Gawker used a symmetric (i.e. two-way, i.e. reversible) function called DES. DES is fine (well, not really, it’s actually been deprecated for over a decade) for storing the passwords. What this means is that, if bad guys can determine the encryption key, they can decrypt the raw password and use it to log into other sites. If there were just a single key used, then the entire user list would be vulnerable as soon as someone found it.
Current forensic evidence suggests that Gawker did not use a single key across the board, but instead used the password itself as the encryption key, which does help avoid the problem of a single key being compromised. However, because encryption is predictable and deterministic, this also means that a given password will always encrypt to the same encrypted password, meaning once someone computes “encrypt(opensesame)” they can find all the other users who used that same password. That’s how the attackers published a list of all the users whose passwords were “password” or “qwerty” (a shockingly large number): They were looking at a table that looked something like:
| joe@hotmail.com | hf387d2_4us |
| mary@hotmail.com | hf387d2_4us |
| steve@yahoo.com | hf387d2_4us |
| … | hf387d2_4us |
and once they figure out what that string decrypts to, they know everybody’s password.
The recommendation to avoid this problem is to employ “salt,” a random number that is added to each password before the encryption or decryption happens. With this in place, you’re not storing encrypt(opensesame) again and again, you’re storing encrypt(opensesame+12345) and encrypt(opensesame+90210) and encrypt(opensesame+02138). The salt can be stored in plaintext in the database because it’s not providing actual security against decryption here, it’s simply fighting against one compromised password creating an advantage for deciphering a second one. In fact, the bigger problem it helps guard against is one known as “Rainbow Tables,” which are basically pre-computed lists of encrypted passwords. Without salt, an attacker can build or buy a list of common passwords and compare the encrypted results against your database; with salt, these tables are mostly impractical.
This essay is not meant to criticize Gawker individually, but rather to use this attack to help teach others to avoid the same pitfalls.
