The Dirty Truth About Web Passwords

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.

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

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.

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.

@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.

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.

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

http://supergenpass.com/

"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.

"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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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).

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)