Analysis of the Stratfor Password List

Published: 2012-01-03
Last Updated: 2012-01-03 02:50:05 UTC
by Rick Wanner (Version: 1)
11 comment(s)

As reported at the on Christmas Day by Deb Hale, Stratfor had personal data of its customers compromised, including a list of 860,000 passwords hashes. Today Steve Ragan over at published an analysis of the password list.   There is nothing original about the methodology used.  It is very similar to what Marc Hofman described in his diary from late 2010 on measuring password security and most likely very similar to what the bad guys will use. Unfortunately Steve Ragan's analysis shows how poor Stratfor's password policy was, and how poor the passwords were in general. Nearly 10% of the passwords succumbed to cracking in under 5 hours. More importantly, this analysis reiterates the weakness of passwords in general, and the general failure of user education in good password creation and management, highlighting that the weakest link in security is the user.

It is clear that we need to continue to work on educating the users. The minimum we need to instil on our users is:

  • reiterate good password creation and management processes
  • discourage password reuse
  • promote the use of tools like Password Safe or Keepass

It may be a difficult battle, but lets try and win it one user at a time!

-- Rick Wanner - rwanner at isc dot sans dot org - - Twitter:namedeplume (Protected)

11 comment(s)


i wonder how long it will be before someone who downloads leaked data like password lists and card number lists is charged with receiving stolen property.
PFFT on the passwords, we already know that portion of the equasion. Those will always be compromisable in one way or another. The important question is "How did the attackers have access to unencrypted credit card numbers and CVS numbers. One's supposed to be encrypted and the other's not to be stored after the card's been authorized.
It isn't entirely the users fault.

Pick any random 10 sites that require passwords and you'll find 3-7 different password policies and or character issues. Some only take up to 10 characters. Some can't use special characters. Some can't use specific special characters. Some will take 25 characters, but really only look at the first 10. Some can't take more than 14 characters. Some require 1 capital. Some require 1 number. Some only take 10 characters and require 2 capitals, 2 lower case, 2 numbers, 2 special characters but not ! or # or % or &, and certain unidentified patterns can't be used on Tuesdays or Fridays.

It isn't entirely the users fault.
In my opinion, password safe applications are probably the only way to maintain a unique hard to guess password for each web site. I would just recommend to stay away from applications that store your password "in the cloud" vs. on your own system.
Not all data needs to be protected the same and they don't all need wildly insane password complexity rules. That's called "risk assesment."

You protect that which has value and that which has high value gets more protection or so the theory goes. The reality is companies and people use thinking along the lines of "What are the chances this will happen to me personally?" and "This will raise my costs of development and support as we keep having to reset people's complex passwords. What are the chances something will happen to my little old website out ofthe hundeds of millions of sites out there? Higher costs and customer complaints will lower my bonus so we're not going to do it.".

And usually they're right. Until "it" happens to them, they've saved a lot of money and made their site more convenient for their customers. And when "it" happens to them, we'll all sit around clucking our tongues while knowing our sites have the same issues.

The only reason we continue to use passwords is because they're free and you get what you pay for. See note above about raising costs and reducing bonuses.
Sean, your question of "The important question is "How did the attackers have access to unencrypted credit card numbers and CVS numbers?" was answered by English mountaineer George Mallory almost nine decades ago. :-)

The reality is someone probably decided to save them "just in case" they might need them. This is one of the negatives of storage costs getting so low and mass storage being so available.

The cost of storing the data has been decoupled from the value of the data and storing them properly would have raised costs. Lowest cost almost always wins.
Which is why in a sick sort of way, it's really hilarious that a security risk assessment company has been hit by such a ridiculous outing of data. Schneier has written much on how humans are horrible at assessing risk...

"Because it is there." What a horrible excuse...
The issue as I see it vis' password strength, is that password complexity in a properly architected site only protects the site owner in situations like this (theft of the credential store). Otherwise most attackers seeking a credential go to the source (the end-user's browser) and just steal the password from that end.

So 'complexity' becomes really a tool not of the end user, but the to the risk/liability manager of the host site. So shame on them for not enforcing complexity.

But as for the end users, 'aaaaaa' is a perfectly reasonable password if you assume the site actively manages against online password guessing. and '@r$k8l8hK203#0)?/kIP' is a useless password if your machine, their machine, and any machine in between is compromised. At best, it just delays the cracking to months... and at worst, it's lost already, and you don't even know it.
I use 1Password in the cloud. Gives me sync of my passwords across my Mac, Windows and iOS devices. at work and at home.
If I could use only local versions, I would not use complete random passwords, then I would use something that was easier to type, and probably not the 15+ chars I use today (always use something longer than the Windows 7+7 hashes) .
Just use a good password for the cloud service and for your password database, and you are safer than most.
Good comments and observations, people. "Weak passwords" is more a reflection on the site's controls and design than it is on the end user because Geoff has it right. If good lockuts are used with a decent self-reset feature (there I go again raising development costs), a "poor, weak" password is about as good as any password.

Just don't use the season and the year. On a recent pen test, the attackers used their acknowledge of our password lockout policy to try these passwords on every account:


and hit paydirt without locking a single account. If it had been a bit later, Fall2011 and Winter11 would be used. "Password1" was particularly egregious because it was a Windows service account password, an account where the password never needed changed and where the admins had failed to restrict logon rights.

PHP's comment about LANMan passwords is also on target. Even if you set a GPO to disable LANMan passwords, every password set prior to the GPO still retains its LANMan hash until its actually changed. Yes, there were a few six year-old Windows service accounts (again) where the LANMan hashes were stored and used against us.

Diary Archives