Caleb Cushing's Blog

Jeff Atwood fails at password security

This was originally written for a class assignment and as that has not been modified (much) for the web.

Jeff Atwood’s password was compromised, the following includes a summary of how it happened, and how better security policies could have avoided it. This was written for Advanced Report Writing at Baker College.

Summary of Article

On May 3, 2009, Jeff Atwood reports that his Stack Overflow password was compromised an that he received an email explaining the details. The following is an excerpt of that email, that was posted in his blog post.

How? Well, there were two pieces of the puzzle, the password and the openid provider. I had a possible password; today your blog post revealed the openid provider. I logged in, freaked out that it actually worked, then logged out. The only reason I had the password is because your password is totally inadequate for someone running a site like StackOverflow. I don’t want to go into any more detail than that, but man - dictionary password! -A friend of the site (Atwood, 2009)

Jeff confirmed that the authentication logs for Stack Overflow did include a valid login from an unrecognized IP address. Although Jeff defends that his password was not a dictionary password. He also states that this particular OpenID account is for low security transactions online, and not particularly valuable. He digresses that because this account is a Stack Overflow moderation account, with special privileges, that he should have used a more secure login.

Jeff goes on to explain, the various ways which the account could have been compromised. The first method he describes is the “educated guess”. An educated guess basically uses what you know about someone to guess there password. The second is “Brute force dictionary attack”. Jeff describes this as an attack vulnerable to non-rate limited logins where the password is a word out of the dictionary. The third method described is “interception”. This method is basically where the password was captured at some point between the user and its destination, this could be kelogger, packet sniffing, and/or simple lack of encryption. The final method was “Impersonation” where a site pretends to be a different site, and prompts you for credentials, this is also known as phishing.

Jeff presents that none of these methods were used to compromise his account.

I guess I can tell you, so you don’t fall into this trap again. There’s a site I help out with that doesn’t salt their passwords. They’re MD5 encrypted, but if you’ve got a dictionary password, it’s very easy to use a reverse-MD5 site to get the original. I was able to figure out you were a user on the site some time back, and realized I could do this, if only I knew your openid provider… (Atwood, 2009)

Jeff then re-iterates that he is to blame, and this is a problem with programmers at large. He then suggests that programmers should get out of the business of storing credentials, if they don’t want to take responsibility for it.

Evaluation of the Article

Jeff Atwood, is a fairly famous full time blogger entrepreneur, software developer and blogger, and often seen as an authority in the community. He is self admittedly not an expert and these articles truly show this. Jeff’s articles will undoubtedly lead many programmers to be confused and ignorant about the types of attacks possible and the type of attack that actually took place. One good thing does come from these articles however. It increases developer awareness (and hopefully user) awareness of just how easy it is to compromise a password and how inadequate there own authentication systems may be.

Jeff seems to not understand the basics of all the attacks he’s described so I will elaborate on what they really are.

1. Educated Guess: Jeff mostly has this right, however, in the article he calls this in with social engineering. It is in no way shape or form social engineering. Social Engineering generally requires convincing someone to give you information. An educated guess requires that you use information you already have to break the password. In a sense this was used to gain the login name, although it was not a guess, it was known. I once used an educated guess to break into the account of someone based on there age, gender, race, and password hint, none of which I had to gain any additional information on. note: my cracking of this account was 100% legal as it was authorized by the computer owner.

2. Brute Force: This is combined with ‘dictionary attack’ and although the two are often combined they are separate attacks. A brute force attack is simply generating account credentials (username password typically) with an automated computer program and sending them to the system you are attacking until it lets you in, until you are permanently blocked, or until you give up. A brute force attack is 100% successful unless somehow stopped as it will eventually try all combinations. The exception to this is when the password could be changed to a password already tried during the attack. This only works on a live system however, if the attacker manages to gain a copy of the password db they can attack at their leisure and may instead get a stale password. It can mostly be prevented by locking users out after a certain number of failed attempts.

3. Dictionary Attack: A Dictionary attack, although it does reference words from an actual dictionary, such as Webster’s, it is not limited to just those words or even words. Dictionary attacks consist of lists of words which may come from any language, including fictional ones like Star Trek’s Klingon, slang, names and pop culture references. Because of modern security standards they will often append, and prepend numbers to the words, and even change case around. Dictionary attacks may also include coded words such as 1337 also know as leet or l337 or l33t, etc. 1337 is a substitution cipher popularized online which substitutes letters for numbers that slightly resemble letters. A dictionary attack is usually run before a brute force as it is much faster, and has a high probability of success compared to time used. It can be mostly prevented by forcing users passwords to be compared against known dictionaries (such as cracklib) and making sure their password isn’t in them, and forcing them to pick something else if it is.

4. Interception: Interception is another name for “the Man in the Middle” attack, which is
what it more commonly goes by. Jeff seems to be under the assumption that “Man in the Middle” requires the attacker to get the credentials verbatim. “Man in the Middle” basically means getting the data after the user enters it and before it reaches it’s destination, this include keyloggers, screen scrapers, and packet sniffers. it may include other methods I’m forgetting. “Man in the Middle” is easily prevented by user strong ‘stream encryption’ in which all data sent between the client and the host is encrypted, SSL is commonly used for this on websites, note the ‘lock’ icon, in your browser. This is different from hash encryption which is how the password is (should be) stored as it encrypts all data being transferred including the username and password hash.

5. Impersonation: Or Phishing is a form of social engineering in which you pretend to be something you aren’t and attempt to get people to give you sensitive data such as account credentials. It is most commonly done by creating a website which closely resembles the site for which you are trying to get credentials for, and then sending out emails to try to get people to log in.

6. Social Engineering: Social Engineering is simply misrepresenting yourself to get information. It can go as far as full blown fraud, or as simply as talking a person into giving me what they may not even believe is sensitive data. One could for example talk to someone, get there name, mention that they knew a woman who married a man with that last name and ask for a mother maiden name, pretending like they knew her. A mothers maiden name is a highly common question to prove identity in account verification and password resets online. People have also dressed up and walked into nuclear power plants with clipboards making themselves look like they belonged there, and were never stopped. An IT guy asking for your password may also be social engineering, as you think you should trust him. Social Engineering may be used to get account credentials or to formulate an educated guess.

7. Rainbow Tables: Rainbow Tables are databases of all possible straight password hashes up to a certain number of characters, and there corresponding passwords, these hashes may or may not be included with a dictionary attack, they typically include the full contents of a brute force. The largest Rainbow tables includes all possible combinations up to 8 characters for md5 hashes. These make reversing a hash from a password instant and easy. It still requires the attacker get the hash in the first place, this is usually done by “man in the middle”, SQL Injection, or compromising the database server. This can generally be avoided by salt-ing the hash making it more difficult for the attacker to get the original password.

Jeff’s Password was lost due to a combination of attacks. Firstly was public information, his ‘user’ credentials (OpenID) were publicly available (this isn’t actually an attack), the second was “Man in the Middle”, as obviously no one published the hash, so it had to be gotten somehow enroute (unless the db was cracked). The third was “Rainbow Tables” which allowed the attacker to reverse the hash into a real password. I don’t believe that Atwood truly understands the attack vector’s, and I don’t think that people should read these articles for learning purposes. It is good though that he accepts some responsibility for lack of proper security practices on a sensitive account.

In my opinion this is what’s wrong with programmers, they think they know better and instead of learning how to do it correctly and all the things that could go wrong, they just go ahead and do.

Atwood, J. (2009). I Just Logged In As You. Retrieved
May 6 2009, from Coding Horror
Web site:

Atwood, J. (2009). I Just Logged In As You: How it happened. Retrieved
May 6 2009, from Coding Horror
Web site:

EDIT: Sincerest apologies for originally spelling Atwood as Attwood and spreading misinformation about about his profession. Thanks to Stu for pointing this out. For some reason I thought those were both true, and did not check them, since I’ve been reading Coding Horror for at least a year.

@Grade I’ll post it next week when I get it

@Spelling errors, I had reinstalled my system the morning of writing and apparently had forgotten to configure it. They should be corrected now.

@Assignment the assignment was not an essay but the evaluation of an article, and its content. It didn’t require me to cite any sources for why I agree or disagree with the article.


comments powered by Disqus