Password analysis from the Stratfor hack

I will return to blogging about theoretical computer science and algorithm-related mathematics next week, but I wanted to take a few minutes today to mention a rare research opportunity that has arisen as a result of the hack of the private global intelligence company Stratfor.  This opportunity is the list of 860,000 (MD5 hashed) passwords to accounts of people in journalism, government contracting, the military, etc. — in short, people who “should” know how to create and maintain strong passwords.  Most of the MD5 hashes have now been cracked, and preliminary analysis indicates that even people who “know what they are doing” use weak passwords.

Stratfor, by the way, finally has their website back online, with a Hacking News section, in which they tell their side of the story.  (They verify that they stored credit card information in cleartext, as Anonymous had claimed, and they state that they were working with the FBI on an investigation into a hack of their systems before the hack went public on Christmas Eve.)  About a week ago, the hackers released a zine which includes a press release about the Stratfor hack and two others, and a log of the hacks themselves.

Passwords have always been weak

Zviran and Haga published Password Security: An Empirical Study in 1999.  They analyzed passwords used at a Department of Defense facility in California.  They discovered that the vast majority of passwords in use were extremely insecure.  80% of the passwords were 4-7 characters in length, 80% used alphabetic characters only, and 80% of the users had never changed their password.  Fast-forwarding to the present, passwords of Stratfor subscribers are not much better.  The most common password is “stratfor” and there are single-character passwords.

Steve Ragan was one of the first to publish an analysis of the Stratfor passwords.  His conclusion:

We’re sorry to report that the state of password management and creation is still living in the Dark Ages.

Ragan cracked almost 82,000 of the hashed passwords in under five hours, using one desktop computer and Hashcat, an off-the-shelf password cracking tool.  He provides lists of the most common passwords, and his own “favorites” from the database, including the password *****  (five asterisks).

The most comprehensive analysis of the Stratfor passwords I have seen is by Gerrit Padgham, who cracked 86% of the unique hashes using GPU technology.  Padgham writes:

Probably the surprising and under-reported insight we found is that a majority (about 630K) of the passwords we recovered appear to be randomly generated by the Stratfor site at registration time.  These passwords all have a very specific set of characteristics.  They are eight characters long. They consist of uppercase and lowercase letters, and digits (‘mixedalphanum’).  With a mid-range dual GPU machine, we were able to test and recover all passwords for that entire character set and length in just over 24 hours.

So what does this tell us?  It’s likely that during enrollment, the system generates a password automatically, and e-mails it to the user.  Normally users are required to change the randomly generated password on subsequent logins.  So it seems that well over three-quarters of all the breached accounts were created but never used. It’s possible that Stratfor auto-generated a password and didn’t require a change on next login, but based on our discussions with users exposed by the breach it appears that this was not the case.

Better security protocols going forward

There have been a lot of posts on security blogs about lessons to learn from the Stratfor hack.   One, by Ben Tomhave, lists the errors in Stratfor’s (lack of) security.  Tomhave was a Stratfor customer, and his information was compromised.  He is clearly very angry at Stratfor, and hopes they go out of business as a result of their incompetence.  (That scenario seems unlikely to me.)  However, tone aside, Tomhave makes strong points.

More constructively, Nick Selby calls on security professionals not to blame the victims who had their information compromised.  Selby’s point is that it is incorrect to say that someone should just make a stronger password next time, because “the passwords are the problem, yo.”  His suggestion:

Rather than continue to make the users do the stupid and useless things we as security professionals tell them to do, let’s remove them from the equation. First, some basic common sense in building web applications  would be nice, as would testing regularly with competent people doing the testing. Don’t let this be the end: secure stuff properly on your endto protect your users. Stop being such a cheapskate and spend some money on your security people. Test your assumptions regularly by having competent people test them. Follow the instructions of what these people say – don’t just sweep them under the rug or plan it for the 2016 fifth quarter budget cycle.

Regarding passwords suckage, Hey! Allowing passphrases would be nice – I don’t know how much more secure a passphrase such as

Ooh, yo – this is my secret passphrase!

is than something random and stupid like


but I can tell you that it is a lot easier to remember, doesn’t force your users to fill their desk with Post-It reminders and, oh yeah, is harder to crack.

I will conclude with a link to an xkcd comic that says the same thing visually that Selby said in his blog: passphrases are strong and easy to remember; passwords weak and forgettable.

Moshe Zviran, & William J. Haga (1999). Password Security: An Empirical Study Journal of Management Information Systems, 15 (4), 161-185


4 responses to “Password analysis from the Stratfor hack

  1. Hi Aaron, thanks for the mention. Just a note on pass phrases though: I believe they can be almost as easy to guess if we change our password cracking algorithms to use words from a dictionary, instead of individual characters. Put in some fancy rules to put spaces between words (or not), add punctuation, etc. and you can start getting some predictable results again. With GPU’s that are able to try billions of combinations per second, you’re bound to get something. It put’s us back to the onion paradigm, protect yourself with strong, unique passwords (whatever they are), and build security into the applications and infrastructure supporting them.

    • Thanks for your thoughts, and I enjoyed your blog post. Your comment is a bit disheartening for an individual user, because it seems to imply that, no matter what password I choose, I have to hope that the company/organization is practicing good data stewardship. One thing I forgot to say in the post was that “unique password” means “never been chosen by anyone else ever,” at least if the password is protected by MD5. Rainbow tables have become so huge, and shared, that if any other person ever used your long, “smart” password, it will be broken immediately.

      • Gerrit Padgham

        Yes, I tend to agree with you. It’s not my intention to spread FUD around the community, but in the end there are only so many things we can do as consumers to protect ourselves. If the products we are consuming are “weak” to start with, what do we do? The average person shouldn’t be expected to know if a product they use has taken all precautions to protect their data, and its ignorant of us to assume they have. Even if they did, what’s to say some newly discovered vulnerability doesn’t place the data at a greater risk anyway? Because of this, I think it then becomes our responsibility to be very aware of what information we provide to other parties, and assume that at some point it will be disclosed. Given that, you can take steps to protect yourself. Don’t use the product (this speaks the loudest, provided the company knows why), give a limited subset of data, or if it doesn’t matter, provide false data. Each of those has its own caveat. Just remember to take a step back and think twice before you click submit.

  2. Pingback: Counting passwords more than just a homework problem « Foundations of CS II

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s