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.

We recently decided to beef up a solution's storage platform. What would have been a simple process just a few months earlier — select a storage subsystem, whether it be NAS, SAN, or DAS, and then populate it with a bundle of drives to meet the performance and space needs — became a serious quandary. We're still in limbo, unsure what to do.

Should we bother paying out big dollars for arrays of magnetic drives, or should we push the envelope and go with an array of SSDs? Should we wait a while? Will our vendors and the storage systems support this technology? Will existing products make optimal use of it? Will the SSDs burn out under our usage models?

Dell, for instance, still has nary a mention of SSDs in their servers and storage products site. Their reps still telling you that SSDs are unsupported.

Yet the evidence is obvious that in the year ahead SSDs are going to absolutely annihilate the existing field of storage vendors. Suddenly "outsiders" like Intel (not really known for storage products) and Fusion-Io are the leaders, and are making the existing market look like a bunch of chumps. Paying big dollars for a large array of magnetic drives seems like a choice that will certainly yield some serious buyer's regret a few months down the line.

SSDs change everything.

In a similar way, the extraordinary advances in JavaScript over the past year have completely changed the scope of what a "web application" could entail, and we as developers still haven't fully come to realize what this means. Opera, Webkit, Tracemonkey, and now, jumping to a big lead, the supercharged V8 engine of Chrome 2 (I have some serious misgivings about Google's browser given that it's the product of an ad company, but it is uncontestably becoming a real contender. I will warn that on the Chrome download page linked before this parenthetical aside, they put the agreement to send...cough...anonymous statistics in exactly the position where people have habitually learned to click to agree to the ToS), the advances have been truly spectacular.

Exciting times ahead. These innovations aren't simply evolutionary, but change the scope and rules of the game.