Gawker User Account Database Compromise

Another day, another user account database compromise.

Already there are reports of various accounts with trivial, re-used passwords being exploited to send spam, propagate twitter worms, etc.

It's pretty obvious by now that some users simply won't stop widely re-using using the same password. That security drum has beaten loudly for years, yet with every user account compromise it's the same reaction by so many, including among the technically savvy.

Oh no! The password I use everywhere is now public!

A question I have to ask those who re-use passwords is why did you ever trust Gawker in the first place? Why did you trust every employee and intern of that group to do the right thing? Trust that every backup is treated with the appropriate care and concern, every service patched and monitored? Why did you trust that the site hasn't been compromised all along?

Brute force exposing passwords isn't even necessary when nefarious agents have owned a site. They'll just grab it before it's even hashed.

You shouldn't trust these sites with a shared password. You simply shouldn't.

It's actually a breath of fresh air that Gawker is salting and hashing passwords (albeit with the mediocre DES), so technically they're not the worst, though they're certainly not the best. Yet still, we're assuming that there aren't password siphons logging away cleartext before the password ever makes it to the hash.

I'm not singling out Gawker: You shouldn't trust any site except for those that you must (like your bank). If you're panicking now because your trivial password that you use everywhere is out there, you're doing something wrong because it's entirely possible that it was exploited all along.

Input Type="Password" Needs To Grow Up

While only tangentially related to the Gawker exploit, I would like to take this opportunity to revisit a proposal I made half a decade ago: One Password To Rule Them All. In that proposal I opined that the input type="password" element needs to optionally add (perhaps via a secure="secure" attribute):

• Web-wide common complexity requirements (rather than every site manufacturing their own absurd collection of rules for what is or isn't allowed), because...
• The password is automatically varied with the domain and username, and is hashed and/or cryptographically encrypted on the client (and is appropriately blocked from JavaScript value queries)
• Meaning that you never give up your password to any site. They only get a hash of your password, which they should hash again or encrypt again (preferrably with a runtime secret that provides slightly more obfuscation. If you then blowfished that hash with a runtime prefix that came from a web service and isn't statically stored in your code, that's an additional check on breaking your passwords in the vast majority of real-world cases)
• And phishing is made vastly more difficult.

Ideally this uses a very computationally demanding hash like blowfish over multiple rounds, pushing the envelope of brute force attacks. In my original suggestion I noted that sites should be able to provide variants to avoid replay attacks or eavesdropping vulnerability, though that's an incredibly weak alternative to simply using the proven SSL for that purpose.

What am I missing? Why shouldn't we do this sooner rather than later? Think of this as bringing digest authentication to forms.

Such a scheme improves security in a number of ways, though it only marginally helps in the Gawker scenario (though it does invalidate the simple dictionary attack being performed for the low hanging passwords, each entry could still be brute force evaluated).

Postnotes (2010-12-14)

This entry got a lot of attention, as obviously it's a growing concern. I thought some of the comments deserved responses.

This will never get adopted because of xyz.

This isn't a W3C RFC submissions. It's a guy commenting on a blog about the known deficiencies of the password element for the purposes of encouraging discussion. Some of the "it is an imperfect solution therefore it offends my sensibilities" responses are deeply counterproductive. Worse are the "this is so wrong!" comments, speaker desperately looking around for affirmation, with no details.

You can just brute-force your solution! With an infinite number of cores, quantum-computing...

I was very vague about the hash/encryption performed, however it is not at all difficult to contrive computationally demanding tactics. You SHA384 the password+username+domain, use that as a key to a blowfish cipher that you use to encrypt a prepared, user-specific 512-byte block, etc. It is not a difficult exercise to contrive a system where it is rationally inconceivable that anyone but the most incredibly resource rich could reasonably brute force compromise your password. Yes, if the NSA really wants to know your twitter password, then sure, they'll probably get it. But for everyone else, it's highly unlikely. It'd be easier for them to just beat it out of you.

This does nothing for the Gawker attack!

Aside from the fact that Gawker was using one of the weakest techniques to hash the password, the principal motive of this entry was that you should never have trusted them in the first place! You have no idea what the countless sites you trust your credentials to are doing with your login information, so the repeated outrage when such a leak occurs demonstrates that something is just fundamentally very wrong.

This doesn't replace SSL

No. It doesn't. It is not intended to. That completely misses the point.

Browsers could never change for this. It's too big a change

This is the one that I find the most remarkable. The web platform landscape has been changing at a blistering pace (many of the innovations like SVG and web workers and canvas having been discussed in detail here), yet securing the password element: Just too difficult. Can't be done.

Authentication Platforms like OpenID Is Better

Indeed, for a class of problems they are. They are not exclusive. However in this case I think it's interesting that the password from Gawker is being used to access the Twitter accounts of some people....with that Twitter account being the shared authentication platform used on many other sites.

But what if the domain changed, subdomains, etc.

This is intentionally domain specific. Very intentionally.

But it's a password-equivalent hash

Aside from the fact that this isn't a replacement for SSL, the intent of this is to avoid any given site (or those who have a database backup or who've installed an interception trojan, etc) knowing what your real password (or password family) is. The intention is avoiding an exploit of one site ever overflowing to other sites, which is exactly why this is a big deal. Otherwise Gawker could have simply reset every single password on the site and sent out password change emails to users and it wouldn't be a concern at all.

When doing activities that impact the web site presentation of projects I'm involved with, I occasionally hop down to the menu item "Validate Local HTML" in Firefox, a function that is available when you have the web development tools (you can also access it via Ctrl-Shift-A, and of course can always run it directly, but that seemingly tiny improvement in ease and efficiency of utilization can dramatically increase the usage of it). In a weak sort of TDD, it is a constant sanity test of at least the fundamental HTML validity of the generated presentation, and I always strive to get it to the rewarding green no-errors-no-warnings state.

Does it really matter though? Ultimately what really matters is if the site renders as close to as expected as possible in the major browsers, and most of them happily overlook even egregious errors (Internet Explorer was criticized early on for being so forgiving, but given its dominance the other browsers really had no choice but to allow the same sloppiness. Most web publishers weren't about to re-engineer their site just to ensure that it displayed correctly in Opera, for instance.)

Out of curiousity I decided to check some other sites to see how many ensure that their (X)HTML is clean. The following are the results as they stand at this moment, though of course as content is added or removed the state will change (though a clean site is often a clean site with intention, and new content is automatically filtered to ensure that it is pure).

• FAIL - http://www.reddit.com - 36 errors as XHTML 1.0 Transitional. EDIT: Rechecked Reddit, and now it's a PASS
• FAIL - http://www.slashdot.org - 167 errors as HTML 4.01 Strict
• FAIL - http://www.digg.com - 32 errors as XHTML 1.0 Transitional
• FAIL - http://www.cnn.com - 40 errors as HTML 4.01 Transitional (inferred as no doctype was specified)
• FAIL - http://www.microsoft.com - 193 errors as XHTML 1.0 Transitional
• FAIL - http://www.google.com - 58 errors as HTML 4.01 Transitional
• FAIL - http://www.flickr.com - 34 errors as HTML 4.01 Transitional
• FAIL - http://ca.yahoo.com - 276 errors as HTML 4.01 Strict
• FAIL - http://www.sourceforge.net - 65 errors as XHTML 1.0 Transitional
• FAIL - http://www.joelonsoftware.com - 33 errors as XHTML 1.0 Strict
• FAIL - http://www.stackoverflow.com - 58 errors as HTML 4.01 Strict EDIT: Rechecked and now it's a PASS
• FAIL - http://www.dzone.com - 165 errors as XHTML 1.0 Transitional
• FAIL - http://www.codinghorror.com/blog/ - 51 errors as HTML 4.01 Transitional
• PASS - http://www.w3c.org - no errors as XHTML 1.0 Strict
• PASS - http://www.linux.com - no errors as XHTML 1.0 Strict
• PASS - http://www.wordpress.com - no errors as XHTML 1.0 Transitional

(I searched around for more good examples to sit in the PASS category, but sadly they are very few and far between)

Should this be normal?

No, it shouldn't.

Some of the errors in some of the mechanically generated HTML are simply unexcusable, and testify to the general level of sloppiness in the web industry in particular.

Check your HTML. Ensure it conforms to the specs it purports to obey, or accept defeat and step back to a less-demanding level. With tools like one keystroke validation and auto-cleanup HTML Tidy (which is available in module form, allowing you to auto-cleanup content mechanically inline in your site code - see this entry for an example of using Tidy from .NET code), there's simply no excuse.

Many will wave off such criticism, declaring that if it renders fine that's what really matters. Yet the worry about purity has more to do with the code maintenance process, and ensuring that an appropriate amount of care and concern is put into the product, in much the same way that you should strive to have 0 warnings in your projects, even if the compiled output works fine regardless. In the same way that I try (albeit with failures at time) to ensure that I avoid misspellings and typos, even if the message could be successfully conveyed with them.