I Just Logged In As You: How It Happened | Hacker News Reader

I Just Logged In As You: How It Happened

codinghorror.com

64 pointssant0sk133 comments

In other words, the attack was nothing new or special: if you use the same password in many places, they're all in the same "pool". If one is compromised, they're all compromised. It's ironic (and stupid) that Jeff Attwood's OpenID — which is supposed to obsolete passwords — was compromised like this.

The lesson's simple: before you re-use a password think about what's in it's pool, and for fuck's sake use a unique password for OpenID and your password manager.

Good advice! Thinking of passwords in pools is a good way to limit the number of passwords you use, and still maintain decent security. Since a lot of my financial stuff is linked together, breaking one account breaks all of them - so I gave them all the same password, and made sure it was extra secure.

My work and my school share servers, so I use the same password. Personal stuff gets a separate password, etc.. At the end of the day, I only have to remember 4 passwords and maybe 2 or 3 usernames, but I don't feel that it's lowered my security at all.

I must say, between Jeff's first post on this argument and another discussion I saw this morning here on HN I got a bit paranoid and just now finished changing _all_ of my passwords, each generated and stored using an automated tool. I acted on impulse, and yet I don't think I'll regret it, even if it was probably overkill. I "fortunately" lost just two accounts too, among which there was my "old" HN one.

Or better yet, don't use a password at all: Use a client-side SSL certificate.

Set your password to something random, and use a client-side SSL certificate to authenticate yourself to your OpenID provider. You can use the password reset feature if you lose your SSL certificate.

I've got instructions on how to do this on my website here: http://joel.franusic.com/How-to-set-up-a-client-side-SSL-cer...

Here's a useful bookmarklet for replacing all your passwords with a unique hash: http://supergenpass.com/. I need only remember a single master password, and all my actual passwords that get saltlessly hashed and stored in some jerk's leaky database are unique and look like some variation of "dxQ1V9EAs2". I can't recommend this thing enough.

Reading Jeff's blog is like watching a big budget Michael Bay/Jerry Bruckheimer production of... an old guy playing solitaire. Huge wind up and little payoff.

But, but, but... he just put a three on a four, after building suspense for the whole week! How can you be so flippant?

About 12 years ago or something, I used to chat on a 'talker'. Telnet talker.thevillage.something:8833 or similar. You had a login etc, and it was good fun.

So, I started learning about network programming etc, and built my own talker. Registration etc etc. I got quite a few people to register on it, and was surprised when I realized they were just using the same login details as they used on the 'main' talker we talked on.

So I logged in as one of them on the main talker and impersonated him... got banned for a bit. It really is surprising how easily this is done. (I was young, and foolish).

"Hey can you just try out this webapp for me? register here." <-- Always use a 'throwaway' login.

I just had a brilliant idea (or, at least, I'd call it brilliant if it were foisted upon me): a demonstration of the true possibilities of phishing, in real-time AJAX in front of users' eyes. Have a one-page lure for an attractive webapp, with registration right there on the front page ("all you need is a username and password!")

When you put in your details, however, instead of doing any "registration", it works for a few seconds in the background, and then pops up a box listing all the sites it just logged into successfully using that username/password combination. As long as it's done by someone reputable enough that users won't think they actually got their password recorded by the server (Microsoft? Bruce Schneier?) it could be a very successful educational technique.

Corrections to post:

1) Palin's password was not compromised directly. Instead, the backup "private security questions" had answers which were in the public domain -- such as "name of your high school" -- to a sufficiently dedicated adversary. (There are four in Wasilla. Sort of narrows the search space a bit versus trying to brute force a password, right?)

2) This doesn't prove OpenID is a good idea, at all. Let's review facts: the site which was compromised uses OpenID and presumably an OpenID provider which has bulletproof security. The problem with this is that, for most users, the vulnerability is not the strongest provider but the weakest one, since they share credentials everywhere. Equivalently, you could say that the weakest link is the user. (Even on an Internet where EVERY site used OpenID, most users would fall for a compromise-anywhere-compromise-everywhere phishing attack.)

The weakest link is nearly always the user... but, unfortunately, they're not a link you can do without. All you can do is look after your end and force their hand as much as you can - password strength meters, salting and hashing passwords, etc.

Regarding 2), I think it would be fair to say that the compromised site was in fact the one that did not use OpenID and instead stored passwords poorly. Once compromised, it exposed user credentials which could then be used elsewhere. Had they used OpenID, this would not have happened.

According to the article, the site which was compromised does not use OpenID.

There were two sites that were compromised. The first did not use OpenID; it stored an unsalted hash, which lead to the compromised password. The second compromised site -- StackOverflow -- uses OpenID. It was compromised because Jeff used the same password on both sites.

Patio11's point is that this is common user behavior, so OpenID doesn't offer any better security than its weakest point, which becomes sites not using OpenID but storing the same password as OpenID. I have to disagree, though: The alternative to OpenID is many more login/password pairs, which has exactly the same problem to a worse degree: too many passwords to remember, so the users reuse them.

StackOverflow wasn't compromised, Atwood's password was. The actual site that password is entered into is irrelevant. If this is a compromise of SO, then banks are compromised every time somebody steals a credit card.

If that credit card had access to all of the funds in the banks, then you would be right. Atwood has an administrator's account on StackOverflow, and presumably administrator powers.

  Oh, and for those who claim my password was a dictionary
  word, and thus this is a de-facto dictionary attack. Well,
  I just went to http://www.merriam-webster.com/dictionary/
  .. and entered my old password there:

  "The word you've entered isn't in the dictionary. Click
  on a spelling suggestion below or try again using the
  search bar above."

  Like I said, it *ain't a dictionary word!* It might be in
  cracking tables somewhere, but it isn't a dictionary word,
  at least not of the type you can use in Scrabble without 
  getting challenged..

Uh, Jeff? If you password isn't long, it's going to be in the rainbow table, no matter how complex. Nobody uses their machine to hash the lines from /usr/share/dict/words anymore! They just download a highly-compressed rainbow table, which will have every non-dork password in it.

So the summary is that he got hacked because he reused an insecure password for his administrator account on SO. The guy who logged into his account seems to have broken ethical and legal obligations to the original website that he got the password from.

Hmm..not so black and white I think. He helped out Jeff and there was nothing malicious done. If I was in Jeff's position I would be thankful.

Yeah, tough call. Since he knows better, he shouldn't have let the passwords be stored on this other website so insecurely, and he shouldn't have been snooping. He did help Jeff out, technically, but he definitely crossed the line to do so.

I don't understand how the attacker got his hands on the MD5'd password? Does Open ID expose that data to anyone?

He didn't. The attacker helped out with a site that didn't use OpenID and doesn't salt their passwords.

And Jeff used an insecure password on both the "evil site" and his Open ID provider.

The attacker only had access to Jeff's hash because he had access to a site that Jeff used.

To be explicit: the attacker was given trusted access to the password database on another site and violated that trust. The fact that the site used poor security and that Jeff was stupid enough to use the same password in two places doesn't mitigate it.

I was expecting the answer to be that Jeff somehow revealed his real password publicly somewhere, not that this idiot stole it from a database that he had trusted access to.

This would be grounds for instant dismissal or even legal action in my book.

But that's irrelevant once your identity is stolen.

It might be irrelevant to Jeff, but it wouldn't be irrelevant to me if I was the one employing this person to work on my web site.

This sound about right?

Add a column named 'salt' to USER, then the PASS column=PASSWORD(salt+'text');

PASS column = MD5(MD5(plaintext_pass) + salt)

SALT column = salt

Is the way used in most distributable web applications.

I think what you actually want is:

PASS column = HMAC(plaintext_pass, salt)

I might be wrong? As I understand it there are issues with MD5(MD5(password) + salt) that HMAC avoids. I'm still not 100% sure I understand the difference, but I think that is what the wikipedia article on HMAC is saying: http://en.wikipedia.org/wiki/HMAC#Design_principles

HMAC is mostly useful when you want to verify that some text hasn't been altered. The client sends message + HMAC(message, secret) and then the server (which also knows the secret) can verify that no-one has changed the message.

Dunno if it helps anything when it comes to salting. Anyone else who knows?

I'm a fan of RIPEMD-160 with salts, it is my default hashing algorithm that i use in my apps. MD5 sits alongside CRC checksums for me when I think about security. For symmetric encryption, I like AES.

In this case though, the choice of hashing algorithm is at least as important as the salt.

If the attacker was motivated to have Jeff Atwood's password, he could have grabbed the salted hash and used a password cracker against it. We're talking a single password for a high profile user, so why not spend a few hours of CPU time on it?

Only an adequate password hashing algorithm (ie, SLOW) would have really prevented this.

Paul Buchheit has a blog post on this. The summary of his blog post is this: "Using a salted-hash such as MD5 or SHA-1 isn't much better. Use bcrypt."

http://paulbuchheit.blogspot.com/2007/09/quick-read-this-if-...

Right idea. However, if you're using MySQL, the docs recommend against that: http://dev.mysql.com/doc/refman/5.1/en/encryption-functions....

Use a different hashing function, probably bcrypt. (Note to self: go back and check some of my old code that did/does exactly what you describe...doh!)

Reply on news.ycombinator.com