1
Q: At the time of the security incident, how were passwords managed?
A: Passwords were never stored as plaintext nor were they conventionally encrypted with DES. Only hashes of the password were stored. The algorithm and use of salt has frequently been misidentified. The two password-hashing algorithms in use were traditional DES-based crypt(3) and bcrypt. The released dump did contain plain-text passwords. These were all cracked and not stored in the clear. Use of the technically-inaccurate term, "encrypted" in an early statement made about the password system contributed to confusion about how password information was stored.
Q: That's great, but my password was exposed. WTF?
A: The traditional crypt(3) password hash is horribly outdated, and it absolutely should have been replaced. Only the first eight characters are significant and its 12 bits of salt are inadequate today. At conception, it was the password hashing scheme for most Unix-based systems. Today, it is vulnerable to dictionary attack. Because computation is relatively fast1, even non-dictionary passwords are subject to brute-force discovery in short time periods. It is likely that all short passwords and dictionary words, including those written as "leet", were cracked and exposed almost immediately with a tool like John the Ripper.
Q: I've wasted hours of my life changing passwords on other sites because of this. What have you changed?
A: In the leaked data, some records have two hashes. The second hash is bcrypt and looks like this:
$2a$10$bhr.BySmgVaywxk8exrmf0aGiClyVJbrzPnpr.2fc.YpG3Ree8KkS.
Unchanged since it was first implemented in 2003, the password hashing code was reviewed when, in late 2008, a user noticed that only eight characters were significant in passwords2. A few weeks after this report, code was deployed to write bcrypt hashes for all new users and password changes. Unfortunately, the details about the fix were not communicated to users. Users were not forced to log in or to change their password to generate the bcrypt hash. Even after the change, the old hash continued to be written because of backward-compatibility issues.3 Nevertheless, this deploy did cause all password characters to be significant for newly registered users and for those users that changed their passwords. Currently, almost all users, including those who changed their passwords since the incident, have only slow bcrypt hashes. The remaining accounts are disabled until their passwords are changed through email.
Q: What about the other 2^12 failures leading up to the exposure of the password hashes?
A: I wrote this post to try to accurately describe Gawker Media's password hashing and what has been done to correct one of the mistakes that led to the password disclosure. I'm sincerely sorry that all the exposed hashes didn't start with the prefix $2a$10$ like they do now.
1 Incidentally, it is slower to compute than SHA-1 and far slower than MD5. Bcrypt is (tunably) orders of magnitude slower.
2 Gawker support did respond to the user after the fix was deployed and asked, "Can you please change your password from the Edit My Profile page (even if it's the same password) to generate the resolution we implemented?" This should have caused a bcrypt hash to be generated for the user, so all password characters would be significant.
3 Actually, eliminating this wouldn't have made much of a difference because old users who never logged in or changed passwords would exist unless their accounts were deleted completely. Also, please note that it is not possible to migrate to a new hash without access to a user's password, either through successful login or change.
4Thank you, Erin, for the illustration.
