The Dirty Truth About Web Passwords

December 14, 2010

This weekend, the Gawker network was compromised.

This weekend we discovered that Gawker Media's servers were compromised, resulting in a security breach at Lifehacker, Gizmodo, Gawker, Jezebel, io9, Jalopnik, Kotaku, Deadspin, and Fleshbot. If you're a commenter on any of our sites, you probably have several questions.

It's no Black Sunday or iPod modem firmware hack, but it has release notes -- and the story it tells is as epic as Beowulf:

So, here we are again with a monster release of ownage and data droppage. Previous attacks against the target were mocked, so we came along and raised the bar a little. How's this for "script kids"? Your empire has been compromised, your servers, your databases, online accounts and source code have all been ripped to shreds!

You wanted attention, well guess what, You've got it now!

Read those release notes. It'll explain how the compromise unfolded, blow by blow, from the inside.

Gawker is operated by Nick Denton, notorious for the unapologetic and often unethical "publish whatever it takes to get traffic" methods endorsed on his network. Do you remember the iPhone 4 leak? That was Gawker. Do you remember the article about bloggers being treated as virtual sweatshop workers? That was Gawker. Do you remember hearing about a blog lawsuit? That was probably Gawker, too.

Some might say having every account on your network compromised is exactly the kind of unwanted publicity attention that Gawker was founded on.

Personally, I'm more interested in how we can learn from this hack. Where did Gawker go wrong, and how can we avoid making those mistakes on our projects?

  1. Gawker saved passwords. You should never, ever store user passwords. If you do, you're storing passwords incorrectly. Always store the salted hash of the password -- never the password itself! It's so easy, even members of Mensa er .. can't .. figure it out.

  2. Gawker used encryption incorrectly. The odd choice of archaic DES encryption meant that the passwords they saved were all truncated to 8 characters. No matter how long your password actually was, you only had to enter the first 8 characters for it to work. So much for choosing a secure pass phrase. Encryption is only as effective as the person using it. I'm not smart enough to use encryption, either, as you can see in Why Isn't My Encryption.. Encrypting?

  3. Gawker asked users to create a username and password on their site. The FAQ they posted about the breach has two interesting clarifications:

    2) What if I logged in using Facebook Connect? Was my password compromised?
    No. We never stored passwords of users who logged in using Facebook Connect.

    3) What if I linked my Twitter account with my Gawker Media account? Was my Twitter password compromised?
    No. We never stored Twitter passwords from users who linked their Twitter accounts with their Gawker Media account.

    That's right, people who used their internet driver's license to authenticate on these sites had no security problems at all! Does the need to post a comment on Gizmodo really justify polluting the world with yet another username and password? It's only the poor users who decided to entrust Gawker with a unique username and 'secure' password who got compromised.

(Beyond that, "don't be a jerk" is good advice to follow in business as well as your personal life. I find that you generally get back what you give. When your corporate mission is to succeed by exploiting every quasi-legal trick in the book, surely you can't be surprised when you get the same treatment in return.)

But honestly, as much as we can point and laugh at Gawker and blame them for this debacle, there is absolutely nothing unique or surprising about any of this. Regular readers of my blog are probably bored out of their minds by now because I just trotted out a whole bunch of blog posts I wrote 3 years ago. Again.

Here's the dirty truth about website passwords: the internet is full of websites exactly like the Gawker network. Let's say you have good old traditional username and passwords on 50 different websites. That's 50 different programmers who all have different ideas of how your password should be stored. I hope for your sake you used a different (and extremely secure) password on every single one of those websites. Because statistically speaking, you're screwed.

In other words, the more web sites you visit, the more networks you touch and trust with a username and password combination -- the greater the odds that at least one of those networks will be compromised exactly like Gawker was, and give up your credentials for the world to see. At that point, unless you picked a strong, unique password on every single site you've ever visited, the situation gets ugly.

The bad news is that most users don't pick strong passwords. This has been proven time and time again, and the Gawker data is no different. Even worse, most users re-use these bad passwords across multiple websites. That's how this ugly Twitter worm suddenly appeared on the back of a bunch of compromised Gawker accounts.

Xkcd-excerpt

Now do you understand why I've been so aggressive about promoting the concept of the internet driver's license? That is, logging on to a web site using a set of third party credentials from a company you can actually trust to not be utterly incompetent at security? Sure, we're centralizing risk here to, say, Google, or Facebook -- but I trust Google a heck of a lot more than I trust J. Random Website, and this really is no different in practice than having password recovery emails sent to your GMail account.

I'm not here to criticize Gawker. On the contrary, I'd like to thank them for illustrating in broad, bold relief the dirty truth about website passwords: we're all better off without them. If you'd like to see a future web free of Gawker style password compromises -- stop trusting every random internet site with a unique username and password! Demand that they allow you to use your internet driver's license -- that is, your existing Twitter, Facebook, Google, or OpenID credentials -- to log into their website.

Posted by Jeff Atwood
72 Comments

There's really little excuse for J. Random Websites not to use Open ID. I'm not going to use it for credit card-linked account but for the likes of Gawker and forums about crocheting, it makes a lot of sense.

Tim Almond on December 14, 2010 7:06 AM

Classic, just classic. Next they'll realize that biting your nails makes you sick quite frequently, but gets you more sympathy and attention from your friends.

Once they fix that, someone will explain the dangers of rubbing your eyes.

The thing about salt though, it should come from a shaker. A full out compromise of a machine (through unrelated means) will usually reveal the special sauce. If your killer web app is not using some kind of directory authentication, where the directory is locked down quite a bit more.. you'll fail eventually.

This means yes, someone who cracks an OpenID provider can and will take full advantage of doing so.

Tinkertim on December 14, 2010 7:06 AM

jeff, blog more stack overflow less. thanks.

ctrlShiftBryan on December 14, 2010 7:13 AM

Great article, all of which I agree with. I'm more than happy to use Twitter to trivial logins, and I'll stick to a unique password for each of my bank accounts. It is safer and it is more convenient.

With regard to point 1, and this may not be correct, I believe that both the full database and the source code were compromised. If this is the case, then salts are of little use. I do advocate the use of both a database-stored salt and an application (source code) salt, however, so that if the database is compromised, password hashes (with their salts) are still secure.

In the case of Gawker too many mistakes were made.

Dcaunt on December 14, 2010 7:14 AM

Obviously, your work here about explaining the password anti-pattern is brilliant. But I'm not sure I will concede your editorializing about the content Gawker publishes; They certainly publish things that others won't, but I think that's the best thing about them. And I wouldn't slight the good work that Lifehacker (and Consumerist, when that was a Gawker title) do to help people by simply describing the effort overall as "often unethical" is actually pretty inaccurate.

(Disclaimer: I do know, and often like, Nick Denton. But then again I do know, and often like, you as well. :))

Anil Dash on December 14, 2010 7:14 AM

What's wrong with OpenID?

The short answer is that OpenID is the worst possible "solution" I have ever seen in my entire life to a problem that most people don't really have. That's what's "wrong" with it.

(Don't be picky on me for using my OpenID to post this. There are at least 20 comments I did not post because of having to use OpenID.)

manta on December 14, 2010 7:16 AM

I'm probably screwed, but my method has been to have two tiers of passwords:

Slashdot, diyaudio, and all the other news type sites I frequent get one strong but common password. The sites that matter, like my bank, gmail etc get unique and stronger passwords.

My rationale is that if my reused password gets compromised, I don't really care much. What damage is done? People could post using my name, but chances are they they could spoof that anyway. It's the bank password and such that really can cause pain and that is stronger and unique.

The real issue here is one of security vs. convenience. I'm willing to risk somebody posting as me to slashdot and the other dozen sites I visit vs. trying to remember unique passwords for each. If the web gets to the point that I need unique strong passwords for each site I visit, I'll punch out of this whole web experience.

Sheldon

Sheldon Stokes on December 14, 2010 7:18 AM

Can we please drop the "driver license" metaphor? "Passport" is much more accurate. A license gives one permission to perform an action whereas a passport establishes identity. I can hold a barber's license, but it wouldn't tell you anything at all about if I am actually that person. And why do barbers need licenses anyway?

Kevdog on December 14, 2010 7:21 AM

BCrypt for my passwords please! It is so incredibly easy to implement and is nearly impervious to the effects of Moore's law.

David Murdoch on December 14, 2010 7:24 AM

Accidents will happen and in our pursuit for secure systems, while increasing and creating ever more secure systems, we can also minimize the risks.

One strategy we like is having a cascade of passwords. Never a single password - perhaps OK in a single network or environment, but never in a hostile public environment. For example:

Level 1 password: only for physically accessible systems
Level 2 password: for highly trusted networks like Google, Yahoo
Level 3 password: for semi-trusted systems
Level 4 password: for low trusted system (you trust their services but not sure if their systems are 100% secure)
Level 5 password: no trust or perhaps you will use them only once

As individuals we all need to create our own system for passwords which we like magicians, we should never share with the world.

Virtual Apps on December 14, 2010 7:28 AM

I'm pretty sure this isn't right. They did store just salted hashes. The algorithm was DES, but inside crypt(3), which produces salted hashes. The reason the passwords were recoverable, though, was that dictionary attacks were very easy because crypt(3) only uses 2 characters of salt for the 8 character passwords.

Jim Hunziker on December 14, 2010 7:31 AM

If I comment on this post, will you steal my password? :O

Jeffrey Davis on December 14, 2010 7:41 AM

@Dcaunt:

The salt is there to (attempt to) prevent precomputed hashes from giving the attackers the plaintext passwords in a matter of minutes. In fact, the algorithm they used uses a different salt for each user and prepends the salt to the hash itself. Anyone getting just the hashes would have the salt anyway, even if they didn't have the rest of the code on the site.

Erik on December 14, 2010 7:48 AM

What truly shocked me in this story were the weak password, not of the users, but of the workers. I mean, "arthur"? Really?

Personally, I use a system suggested by a fellow Slashdotter: I take a fixed password, append the website's domain, hash it and cut it to 20 chars (plenty of websites have a small upper limit on password length - incredible but true).
For example, a possible password (not a real one, the domain is fake) is 9131d179c92b286a5474.

Of course, this is for random websites which I don't _really_ care if someone takes over my account - never for something so important as access to a major website's admin account!


As for OpenID, I think it's fine as long as I control the URL that identifies me. Right now, if someone hacks and takes control of http://andreparames.com/, I can simply unplug the server, as it's a laptop running in my bedroom.

Similarly, if someone hacks myOpenID.com, I can simply change my provider in my website.

But using someone else's domain as my ID is a no-go to me, and for most people that's what they'll do.

IceBrain on December 14, 2010 7:49 AM

Jeff, I would love to hear your opinion on this: http://www.quora.com/What-s-wrong-with-OpenID :P

Miguel Santirso on December 14, 2010 8:17 AM

Gawker did NOT store passwords. You are flat-out wrong there, Jeff. They stored the standard DES hashes of passwords as computed by crypt($password, "xy"), where "xy" is a random two-character salt (http://php.net/manual/en/function.crypt.php).

Using some kind of brute force (perhaps a dictionary attack, perhaps rainbow tables, perhaps something else), the hacker managed to crack about 200,000 of the 1.3 million passwords in the database. The other 1.1 million are still crackable, but only the hashes, not the plaintext passwords, are in the database that the crackers released.

Adam Rosenfield on December 14, 2010 8:19 AM

As a long time Giz commenter, I didn't have the choice to use Facebook or Twitter to comment back when I started reading Giz. You can't blame anyone for being limited by the technology of their times.

MaximillianHill on December 14, 2010 8:24 AM

Fortunetly, everyone is moving toward a "web driver's license".

Unfortuently, this isn't a decentralized system like OpenID, but rather Facebook Connect.

It's such a shame we ended up putting our web experiences into a company that a lot of people (myself included) avoid like the plague.

Miff on December 14, 2010 8:44 AM

Two comments:

1. I use LastPass. http://www.lastpass.com
It is free and it integrates very well into Firefox, IE, Chrome and Safari. Since LastPass remembers my passwords for me "in the cloud" (as people call it today), I have my passwords in every browser and wherever I go, as long as I have Internet access there. Since I only store my Internet passwords there, I won't need access to them if I have no access to Internet. And since I don't have to ever remember any of those passwords again, all my passwords for all my accounts are different and they are all combination of random letters (upper and lower case), numbers and punctuation characters, always as long as the service allows (up to 32 characters). Guessing them? Impossible. Brute Force? If you have the time ;-) If one gets compromised? No problem, has no effect on any other account and I can just pick a new random one for the compromised account. What if LastPass itself is compromised? No problem, passwords never leave the computer unencrypted, so not even LastPass could recover them; the data from LastPass is completely useless, unless the attacker knows the Master Password and my Master Password is very long and immune to dictionary attacks. Further I change it whenever I feel like it.

2. Regarding your Internet driver's license, you will probably love the new German identity card. It is a normal identity card, works like a passport within the European Union, with picture and standard ID information (name, address, date of birth, etc.). However, it also has a chip inside and by plugging a USB device to your computer, you can use it to authenticate online. You can either authenticate as yourself (with your realname and address), or you can use the pseudonym function to authenticate as the person owning the ID card, but without transmitting any personal information (other than that you own the ID card and the PIN to use it). To use the password, a 6 digit PIN is needed, that is of course secret and the card is locked after 3 incorrect attempts - too little to guess a 6 digit number. The pseudonym function is pretty cool: The Site sends a site identifier, the ID card takes this identifier, mixes it up with a unique number stored inside the chip, hashes the result and returns it back to the side, but only if the correct PIN is entered. To avoid man in the middle attack, a site must authenticate towards the ID card and the card towards the site in such a way, that a man in the middle will fail, even if he can see and modify all traffic in between those two (similar to SSL certificate authentication or how VPN tunnels are established based on certificates). Another very useful online function of the ID card: Age verification. It can just verify that you are above a certain age, without revealing you real age or any other personal information to the site owner. The card owner is always shown which information will be revealed to a site owner and its up to him to allow that, by entering the PIN.

Mecki on December 14, 2010 8:53 AM

Agreed that using the Internet Driver's license of Facebook/Twitter solves the Gawker hack problem--but it still leaves open a Facebook/Twitter password problem.

I'm not going to feel good about passwords on the internet ever--even if they are being stored by a trusted source like Facebook/Twitter.

The only solution that will make me feel absolutely secure is to use GPG/PGP auth, allowing me to sign my authentication but own my secret key/password--never to be given to anyone.

Adam Eivy on December 14, 2010 9:03 AM

There is a solution to this, user side. You can _easily_ use a different password for each site, without the need to remember them, without storing them. Really.

The idea is to hash+salt your password on the client side, on the fly (with a deterministic salt that depends on the site you visit). Instead of entering a password directly in the password field, you can install a bookmarklet/extension that takes you password, processes it through the salt+hash and fills the password input for you.

This way you don't have to trust every webmaster of every sites you visit, since you send them a different password for a different url.

A few extensions/bookmarklets implement this (but don't use the bookmarklets, it is not really secure):

- password hasher
- hash a pass
- supergenpass

Christophe-Marie Duquesne on December 14, 2010 9:23 AM

There is no end game with passwords and user accounts. You like the idea of a universal "driver's license" which is all fun and grand, until that gets compromised and then ALL of your accounts are automagically compromised in one fell swoop.

You have to have a good game plan to ensure your the really valuable stuff doesn't get compromised. I take several steps to do this, and to this day, those valuable accounts remain undetected and protected.

It all comes down to being smart, having a good strategy, and above all else, staying anonymous on the internet.

Phiberoptik on December 14, 2010 9:47 AM

I trust Google on security more than J. Random Website, but I'm not sure I'd say the same for Twitter or especially Facebook.

KCinDC on December 14, 2010 9:51 AM

@Adam Rosenfield:
I'm glad I wasn't the only one that thought that right away when reading this post.

Sure, they used a crappy *hash* that's been known weak since the 90s, but they still called crypt(), and didn't just store the passwords in the clear. This is the one huge failing that I can see.

opello on December 14, 2010 10:03 AM

A few points here.

1) Your memory is actually really good once you train it, it isn't hard at all to memorize (*aDb&<88g ... it's simply not, you just need to use the password about ten times.

2) The real problem is our insistent need to authenticate everything rather than monitor for fraudulent/unwanted activity. The bigger issue is that systems designers treat authentication as the end all of system security. We simply cannot and should not depend on it. Think of it this way, if I get General Anyman's military ID and flash that at the guards outside of Fort Knox, and the guard authenticates me for access, are they going to monitor my activities? Am I loading my backpack with gold? What did I bring into the fort? What have I done? What looks suspicious? Am I simply harvesting page-after-page of data? We need active monitoring and auditing of the actions a user account does in a secure system, authentication shouldn't be trusted to stop undesired actions.

3) Why the **** do I need to join my OpenID or register an account just to say hello and add my two cents? If I'm a spammer, I'll create a google account, join OpenID, post my spooling misteaks seling u bonerpills and be on my merry way. We need to examine that preventing spammers can be done without logins, which could in theory be part of a distributed reputation system, for example it could be "OpenRep." I don't want you to have my damn email just so I can comment, because I really don't trust you either.

Brian G. on December 14, 2010 10:44 AM

SuperGenPass +1. Its the first thing I setup on any browser.

http://supergenpass.com/

Corey Stup on December 14, 2010 11:43 AM

"The odd choice of archaic DES encryption meant that the passwords they saved were all truncated to 8 characters. "
To be more precise, DES-based Unix crypt() hashing, which is weak.

Yuhong Bao on December 14, 2010 12:04 PM

"stop trusting every random internet site with a unique username and password! Demand that they allow you to use your internet driver's license -- that is, your existing Twitter, Facebook, Google, or OpenID credentials -- to log into their website."
Yep, I pretty much look for this first as a habit nowadays every time I have to login, and it is pretty nice. For example, I am posting this right now with my Google account.

Yuhong Bao on December 14, 2010 12:08 PM

Not to mention if you want to impersonate someone, in most websites it is only slightly harder to create an account with a fake name to login with than putting a fake name into a Name field, which can be an issue for famous people, which is why I recommend using a verified Facebook, Twitter or Google account whatever possible when they comment on websites.

Yuhong Bao on December 14, 2010 12:23 PM

This is exactly why I use a lame throw-away identity for those smaller sites that don't mean much such as gawker. Of course if everyone used OpenID type auth I would be in hog heaven

Matthew Ishii on December 14, 2010 12:42 PM

@Matthew Ishii me too anything that requires me to create a login for very basic things like forum posting, blog posting... I just don't care if someone hacks it I have given no real personal information the most they will get is my email address.

For important things email, paypal, email , bank... secure all the way.

Petebob796 on December 14, 2010 1:37 PM

OpenID isn't some security panacea. You lose your domain or your website gets hacked, suddenly you're hacked!

But OpenID can be very convenient.
Check out http://openid.aliz.es/ it's like the http://spam.la of openid.

Yeah-use-openid-sheesh on December 14, 2010 2:19 PM

What about public key authentication akin to passwordless SSH logins? You can generate several keys to be as anonymous as you wish and there are several options where to store your public key. One option is to store it on a public keyserver; another is to upload it to the site you wish to access. The advantage is that the only data travelling across the net is the public key.

OpenID still relies on passwords. If you want to be able to have multiple identities online, you'll have to create multiple OpenID accounts. The unqestionable advantage of OpenID is that it does not require special browser support.

Dkobozev on December 14, 2010 3:25 PM

A couple of points:

1) Gawker has been around longer than Facebook Connect, and OpenId. Many of us have had gawker legacy accounts. You might have converted your readership to use internet drivers licenses, but not all sites are willing to do that. FWIW you can still use your legacy YouTube account if you wish.

2) It's pretty clear that Gawker did not save passwords. If they saved passwords (ie encrypted ones), then Gnosis would have cracked *all* the passwords. Cracking encryption typically involves attacking the key-strength, not brute-force guessing the original plain-text message. Based on the information given, it seems like Gawker saved DES based Hashes. Using a salt wouldn't help if they insecurely stored the salt (given the stupidity with their password security I don't think this is a bad conclusion to reach).

Like Petebob796, I could give a rats ass about my gawker account, so I used a weak password.

Alan Balasundaram on December 14, 2010 4:36 PM

Imho (and very just my own opinion) reusing the same password for some things isn't that bad of an idea, as long as you know what you're doing.
i personally use the same password (and quite possibly user name/email) for a lot of things, all of them completely inconsequential. i don't care at all if someone gets that "unimportant" password and logs in to everything that i used that password on, because it's all sites like forums, online games, J Random Website, etc.
beyond that i have a password i use for things that are slightly more important but still an inconsequential loss on sites i trust.
then i have different passwords for things like email accounts.
and then i have secure IDs for my online poker accounts and would feel much more comfortable if my email accounts had something similar.

now on the issue of storing passwords when you have a website/other kinda server that you require people to log on to (there's still a few things you can't use OpenID for i believe). When you only store a hash of a password, salted or otherwise, you're effectively shortening passwords to 20 bytes (or however long your hash is)(which is obviously longer than probably over 95% of passwords). now if you store 2 different hashes of passwords it's almost impossible to produce a hash collision since you need to have a string of characters that produces the same hash value against 2 different algorithms which then needs to be the same as the original password.
but yeah obviously use openID wherever possible.

Alexander Knopf on December 14, 2010 4:36 PM

As mentioned by others, how the sites store password is irrelevant. User should use a different password for every site.

Imagine that a site implements proper password storing technique. Once it is compromised, hackers can install their own code to intercept passwords entered by users of the site.

I used to play EVE online a while ago. PVP there is insane. One group spied on the other. I belonged to an alliance that modified standard forum software to keep a copy of a users password in a clear text. This password was then used to see if it works on enemy forums.

Moreover, they sometimes displayed "wrong password" message, even if the password entered was correct. In a typical scenario when a user is presented with a "wrong password" message he is trying other passwords he usually uses. That allowed them to harvest even more possible password.

Again, everybody should use a different password for each site.

Cloud Forge on December 14, 2010 5:30 PM

That's still pretty bad advise in the face of reality. The general public doesn't understand OpenID. It was designed for technically-well-versed bloggers and homepage owners. It's way too complex for Grandma. It's a non-solution.

Mario on December 14, 2010 7:01 PM

I like OpenID myself. I don't have a Facebook or a Twitter account. I've since replaced my Gawker password, not that it matters since it was unique to Gawker and was randomly generated (thank you KeePass and LastPass).

Dannybhoy1 on December 14, 2010 7:59 PM

And when a keystroke logger compromises your OpenID credentials, you lose everything everywhere.

We need at least 3 sets of credentials (un/pw pairs) through OpenID/OAuth corresponding to 3 security classes

Class I: utterly disposable
Class II: painful to lose, but ok for non-secured machines
Class III: cannot lose. Use only only on trusted, secured machines (ex. Personal machine running iOS)

jfaughnan on December 14, 2010 8:51 PM

While I agree, that passwords are not best idea (I rather use OpenID authentication, but only due to my laziness) I wouldn't agree that OpenID is a best (or even better solution).

Let's think about current situation: we can safely assume, that the culprits didn't download magic /etc/password file but got a hold of smaller or bigger portion of Gawker shared database. Right now they have access to (as Gawker say) 1.2 million records consisting of: username, e-mail, password (probably somewhat encrypted/hashed).

You now have this kind of DB, what now? First you need to link this data to proper identity. Most data-sensitive companies I know (and use their service) have numerical logins, which are never sent to user through internet, but usually through traditional mail, You can't link that, unless you'll try "password" for every client number you can imagine, good luck with that.

Same is with pretty everything else as long as someone set different password for e-mail and different password for site he is/was using - that way proper identity can't be linked and hack is gone (maybe someone is going to post bulls**t on site you forgot you even registered on sometime in the future, but who cares).

On the other hand if someone gets access to whole tree (he doesn't even need username/password, just linked data) then you have real problem. I shown friend of mine how his bank compromised him by asking by phone every identity confirmation question so he could log to phone service. I called back to the bank, introduces myself as him, given responses which I remembered hearing and changed password. And I am just average developer, nowhere close to expert identities thieves.

The point is that having 1.2mln of such records means you don't care for blank connections where email passwords are empty. You care only for those you can follow and researching identities is painful and expensive process. Chances that you'll be target of such identity mining are similar to someone picking exactly on you (which is unlikely unless someone is really hard core troll offending everyone or some kind of celebrity).

Gawker made smart move by exposing its problem. But as written in article - chances that your account will be compromised rise with every site you've registered on. As well as chances that you'll never know this happened...

Przemysław Kamiński on December 14, 2010 10:10 PM

I do agree that a global internet identity system would be really convenient, and I am almost sure that in the future (maybe ten years) it will be like that for everybody. If the biggest companies (say Microsoft, Google, Facebook, ...) get to an agreement and implement a common system, it would be quite fast.

But, let's talk about reality. When I think about a base user, I always think about my parent, a 70 years-old man with little knowlegde about technology. Would by dad be able to use my web if I used something like Open ID, for instance? Answer: NO, it's way too complicated.

So, for blogs like this one, it's ok to use that kind of standard identification system, but for webs like mine, I had no other options but implement my own identification system.

Agustín Caballero on December 15, 2010 3:55 AM

As some commenters have already pointed out, this post contains incorrect information. The UNIX crypt routine computes exactly what you are advocating -- salted hashes, even though it relies on symmetrical DES algorithm. Of course, that does not mean that using it is actually a good idea -- because of its low computational complexity and the short 2-char salt. bcrypt is generally recommended as a viable approach these days.. And at the end of the day, though, with passwords like '123456' and 'password' chosen by most users [1], no amount of smart hashing is going to help you if the database is compromised.

As there is enough confusion about password security in the blogosphere already, and your blog enjoys fairly high visibility, it would be nice to see that point fixed in the post.

[1] http://www.duosecurity.com/blog/entry/brief_analysis_of_the_gawker_password_dump

Andi Wundsam on December 15, 2010 4:51 AM

Kind of nitpicking here, but I recently discovered (http://security.stackexchange.com/q/379/33#440) that Rainbow Tables are NOT just large lists of hashes of all possible passwords.

It would actually be more correct to call them "Hash Chains", rather than the "Hash Tables" we are all familiar with, and most of associate with Rainbow Tables.
Yes, it seems even some of the tools call it by its wrong name...

User @Crunge on SE really opened my eyes to this one, even though I *knew* what Rainbow tables were - or thought I did, as it turns out I didn't. And I am also one of those considered by others to be an "expert" (in security, though not specifically cryptography).

Seriously, it's an awesome post, one of the best answers I've seen on SE - go check it out: http://security.stackexchange.com/q/379/33#440

AviD on December 15, 2010 5:58 AM

Biometrics...'nuff said.

Scott Everard on December 15, 2010 9:17 AM

This is yet another example of why passwords should never be stored in a sites database (in clear text or encrypted). The only correct way to store passwords is a salted hash.

I knew this two years ago when I created www.my-msi.net. Even if a hacker were able to get a list of emails and 'passwords' the 'passwords' would be useless since more than one password can hash to the same value, there is no way (on earth or heaven) to go from a hash to clear text!

Nore do we store credit card info in the database. We let Amazon handle all credit transaction and only the cookie that Amazon returns is stored in the database.

I dare anyone to try SQL Injection on the site. It is written in ASP.Net and those controls neuter SQL!

GemsFamily on December 15, 2010 9:35 AM

The only problem I have with the concept of an "Internet Drivers' License", as you put it, is only half-covered by the centralization of risk. I understand that it means less attack points for the same password, which is better than twenty different options for a hacker to determine the thing. However, a successful attack on the site you login from does more than grant access to other sites you visit. Like a fake Drivers' License in the real world, it can be used for access in your name to other sites you never visit as well as the ones you do, allowing criminals everything from easy defamation to - if your payment credentials are accessible from the login site - use of your money to buy just about anything from anywhere that accepts the login information.

It's sad, but for true security, you need a unique password for every site you visit that requires one. And, yes, that requires a level of memorization beyond the capabilities of most persons. My best recommendation is a highly self-critical evaluation of risk, determining what you are willing to live with and should (someone had five tiers of password security above, for example), and implement that as best as possible. In the case of areas where low-security is fine, a common login site may be a good idea, so long as that login does not link to any payment information whatsoever. For anything involving money, use a unique password to that site and, if plausible, refuse to store payment data with the site. If you must store payment data, make sure you trust that site with your life (because you are), and use the strongest password that site will allow. If that site doesn't allow strong passwords, don't trust it with your life.

Vidstudent on December 15, 2010 10:57 AM

Problem is no that developers doesnt know this, problem is when the company says "we need the passwords in clear text because customer are asking for them", and you try to convince them it can be reset and they say "but email is reliable, we need to be to give them the password"...and so on.

Also, the idea that centralizing would increase security is deeply flawed, eventually someone will hack one of these solutions and then tens of millions will be compromised rather than one website.

me.yahoo.com/a/HXUIAGJiw43sYe5WFlUhQtRWZcA_ on December 15, 2010 2:55 PM

"123456", seriously? An actual editor uses that effing password? OK, I use some weakish passwords for sites I don't care too much about, but at least they have letters and numbers. For sites I really care about, I use special chars, capital/lowercase, numbers, and letters.

Seeing all these leaked editor accounts just saddens me.

Kamran Ayub on December 15, 2010 5:22 PM

At first I was kind of amused by the stupid people using 123456 but the more I thought about it, the more this really is the way to go for utterly worthless sites like lh, gawker, and other sites where someone impersonating me can really have no important effect - if EVERYONE on gawker has treated the sites and comments as more or less worthless, no one would care about this breach, because we all always use 123456 or something equally 'stupid' that we would never use for something actually important like a site where I purchase something.

I'm changing all my passwords on these sites to that !@#$%^ which is just shift+'drag finger across 1-6' and also looks a little like I'm giving them the finger.

So not only does this put all these sites on notice - our passwords are this way because you've shown your ability to keep my passwords and your ability to lie about how safe they are (head of gawker posted that the encryption they used was 100% unbreakable) are at odds.

Pretty soon there will be a new exploit, because gawker will require your password to be unique from others. See where that's going?...

Bif Powell on December 16, 2010 6:18 AM

Way too many comments to read them all. Here's my 2¢: I use a strong unique password for a few critical websites that I use (like my email, paypal, bank, etc.) and a common password for all those dozens upon dozens of websites where I simply don't care if they get hacked or not.

This, I believe, is way more secure than a centralized OpenID or whatever other identity provider. For one thing anything can be hacked, for another - I really don't want to entrust my bank account access to any 3rd party except my wife.

Vilx- on December 16, 2010 7:32 AM

Oh, and I forgot to mention - a quick one-step registration for a website beats OpenID-based registration any day. I groan in pain every time I need to use my OpenID to register somewhere, and seriously reconsider, whether I want to go through all that bother. Note: I picked Verisign as my OpenID provider. Pretty much by random, though theirs is the name I trust most in security. And their process isn't complicated or anything - it's just way lengthier still than a typical one-step registration.

Vilx- on December 16, 2010 7:37 AM

Great one.

One pain usually, is that different sites have different "password strength" definitions. Someone is looking for a 6 digit pin, someone asks for a 8-10 characters password, and another website a password with uppercase, numeric, and special characters. This makes it so hard for the user to manage all the credentials.

- How does one know if the site is safe (storing a salted hash) and not a gawker?
- For existing sites on the web, how does one classify the passwords to have different levels of criticality?

Nishith Prabhakar on December 16, 2010 11:07 AM

"This is yet another example of why passwords should never be stored in a sites database (in clear text or encrypted). The only correct way to store passwords is a salted hash.

I knew this two years ago when I created www.my-msi.net. Even if a hacker were able to get a list of emails and 'passwords' the 'passwords' would be useless since more than one password can hash to the same value, there is no way (on earth or heaven) to go from a hash to clear text!"

It wasn't in cleartext.

Unfortunately, they were using DES with a two-character salt. The same technique that UNIX was using 30-40 years ago. The same technique that no Linux/BSD system worth its salt has used for at least 10 years because of how quickly it can be broken.

Heck, the Debian Linux machine I was using 10 years ago was using an MD5-based scheme with an 8-character salt, and even that's no longer used by a modern Linux/BSD system because it's too weak.

Powerlord on December 16, 2010 11:12 AM

This article seems like good knowledge, in-depth analysis, and bad advice. There's no easy solution, but this implementation would be disaster.

Gawker and J. Random aren't necessarily the real problems (especially with the options of cascade of passwords, LastPass, KeePass, Password Safe, SuperGenPass, home-made transform using hash algorithm, etc.). Examples of real problems: Using the same password everywhere, passwords that can be reset via email or challenge questions, and sites that don't allow strong passwords. The idea in this article would be a real big problem.

7 ways, just off the top of my head, to pwn someone with this "centralized risk:"

http://sophware.posterous.com/even-coding-horror-may-not-have-a-good-answer

sophware on December 16, 2010 3:01 PM

I agree with the suggestion that passwords are pre-historic and need to be discarded altogether.

Yet, the internet driver's license is not going to stop hackers from hacking information stored on the server.

I will try to explain why...

There are different sites out there which store user information such as their name, address, email, phone number, etc in free form.. i.e text on the database server.

The authentication using user name / password or internet driver license (IDL) only provides a gateway to access / edit that information by the owner.

This does not in anyway prevent someone from downloading everyone's personal information as described above using a sql injection or by hacking into the database admin password.

Therefore, it is important not just to hash/secure the user credentials but also even more important to encrypt a user's personal information before storing on the server.

Now about passwords. By having a password or IDL (which again is authenticated using a password) in the first place is a security risk.

What if there are no passwords at all.. Then there is nothing to hack. If the information stored on the server is encrypted using a seed that is not stored on the server, then hackers will have a nightmarish scenario where they have to first get to know what is the seed (which again if it is unique for each user) and then use it to decrypt the user information one by one.

I feel the current method of authentication is crap and needs a overhaul completely by doing away with passwords or IDL altogether.

Instead leave the seed/key with the user (in the form of a device authentication) or use an identity server that does not store user credentials and yet authenticate users by generating keys in real time as a combination of user credential plus their device identity.

All this sounds crazy, but I have been able to devise such a method to do away with passwords completely. You can try it out a www.0pass.com

Though there is a password field, you can sign in from a registered device without entering a password.


Gurudatt on December 16, 2010 10:42 PM

I am considering doing this on my web: no user-selected passwords, account creation and login would look the same. User gives an email address and then they would need to prove their own that email address by clicking on a link in a sent email. The link will set a cookie and the user is logged in while the cookie is valid. No need to rely on 3rd party authentication service, so it is more secure if the link in the email is only valid for a short time.

Vlastimil Miléř on December 17, 2010 3:15 AM

"Sure, we're centralizing risk here to, say, Google, or Facebook -- but I trust Google a heck of a lot more than I trust J. Random Website, and this really is no different in practice than having password recovery emails sent to your GMail account."

That's the heart of it. Trouble is, while I might trust Google's ethics or tech savvy more than J. Random's, I can never trust them fully. They aren't invincible, and centralizing the risk is not worth it (and you are not simply centralizing your own risk you are advocating centralizing everyone's centralized risk). If I don't know how to keep my sensitive identities completely separate (including separate email accounts) from my more trivial, throw-away identities then educate me. Don't force me to centralize my risk. I loath the day where I have to use my Google account or iDriver's License to log into other web sites. I would much rather have the freedom to set up a separate account with each entity.

mawrya on December 17, 2010 9:49 AM

While I have an OpenID account and I see it as a good alternative it is far from a perfect solution. There are better solutions out there as some of the commenters already mentioned.

I bloged about it: http://www.cromis.net/blog/2010/12/your-passwords-security-on-the-internet/

Iztok Kacin on December 18, 2010 3:56 PM

@Nishith Prabhakar: "How does one know if the site is safe (storing a salted hash) and not a gawker?"

The most reliable indication is if they let you "retrieve" your password or if they only allow you to reset it. Most f the time passwords are stored reversibly so they can send them out to users who forget them.

Of course, I'm fairly certain Gawker didn't allow password retrieval either. They were the special kind of incompetent that didn't have a requirement for password retrieval yet stored them insecurely anyway.

@Adam Rosenfield (and others): "Gawker did NOT store passwords. You are flat-out wrong there, Jeff. They stored the standard DES hashes of passwords as computed by crypt($password, "xy"), where "xy" is a random two-character salt (http://php.net/manual/en/function.crypt.php)."

DES is reversible encryption. Yes, 'crypt' uses the password as the seed rather than as the encrypted value, so there are theoretically multiple possible decryptions for each "hash", but the entropy there is incredibly low. Almost all of the Gawker password hashes have been reversed at this point. DES reversal is just a matter of time and computing cycles, then throw out the ones with characters the keyboard can't easily produce.

That having been said: yes, if you are just going to brute-force, you can guess the passwords of the strength seen in Gawker's database just as easily had they been storing 5xMD5 hashes or similarly non-reversible storage approaches. No matter how well a site stores passwords, if your common password is "123456" or, apparently, "monkey" (???), it will get guessed and verified with such a database dump.

What Gawker did was expose the guy who has the non-common brute-force-resistant password like "tiaucpw4ts" (this is an un-crackable password 4 this site). That guy's doing everything "right", but if he went to the trouble to do things "right" with that password he is probably using it on more than one site; Gawker just gave away that password everywhere.

Tdibble on December 19, 2010 3:52 AM

You may not know as it's nice to come across a beautiful and interesting blog. It feels good morale. I thank in advance all that have watched over the good and wonderful progress of this blog. Especially keep it up. Thank you again.
Regards
voyance , horoscope 2011 , Marie ange

lora on December 27, 2010 1:22 AM

I haven't really given much though to using an "internet driver's license" type log-in. However I do see your point and think it's a very good one. I do wonder though...

Is it wise to give one company that much control over all of the sites you visit? What happens if one of the companies gets hacked? Goes down? decides to sell, etc?

Htmyell on December 27, 2010 3:57 PM

A big thank you for this article
very good idea to set an example, it often lacks
voyance

lora on December 28, 2010 3:35 AM

Excellent post Jeff. There are site like digg.com also stores user password. Gawker isa perfect example for them to learn!

Sarat on December 29, 2010 3:47 AM

Great article.
I like the "internet driving license".
I need to change some passwords.

And I logged here with twitter :)

Thinkwitty on December 29, 2010 2:30 PM


I hate OpenID and I think its a crazy idea to centralize all your security and identity with one provider. OpenID is like a passport, and sites like stackoverflow and this blog are like walmarts and dollarstores. I shouldn't have to show my ultimate passport ID for the most trivial transactions (buying a bag of chips, for eg).

Jeff, listen to the people, don't be arrogant and please offer local passwords. You sound like google when they didn't want to add a Delete button to gmail because they thought they knew better than their users. Some people just aren't interested in maintaining a consistent, proper and centralized on-line identity, especially not with sites they use very very occasionally (like stackoverflow, for eg).

Posted via the openid host at http://openid.aliz.es/ - whoever made that is my hero of the day.

Throwaway on January 5, 2011 11:33 AM

Another interesting post, I need to use harder passwords, I use simple ones so I remember them, but need to reset many of them.
Flip Sites For Cash

Bob Duryee on January 9, 2011 5:34 PM

Great openid.aliz.es, really proved who I am to make a post.

We also could throw the internet away and design a new one, and everybody could switch to it in fews days, what do you think?

Lerolero on January 25, 2011 5:44 AM

How about don't use password at all? Just pick an ID and use this as your OpenID,

http://opennoid.appspot.com/id

Iamfake on January 25, 2011 6:13 AM

Owch. Double wammy of Facebook asking for real names, (and people went for that), and then using the facebook ID to log into everywhere on the internet. Privacy nightmare.

ACME Squares on March 4, 2011 9:23 AM

Giftnext find, compare, enjoy unique feature that helps the targeted population of UK to have a thrilled weekend break away from home in order to get relaxed by using the spa massage at weekend .

damienmartyn on April 6, 2011 1:42 AM

Just came across a Microsoft 'create account' form which fails validation when a password is supplied longer than 16 characters.

Good grief!
http://thetempdomicileaffiliate.blogspot.com/2011/12/microsoft-windows-live-password-maximum.html

William Cooper on December 14, 2011 4:55 AM

The comments to this entry are closed.