Analysis of the Stratfor Password List
As reported at the isc.sans.edu 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 thetechherald.com 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 - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)
Comments
JJ
Jan 3rd 2012
1 decade ago
Sean
Jan 3rd 2012
1 decade ago
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.
fordpref
Jan 3rd 2012
1 decade ago
Dr. J.
Jan 3rd 2012
1 decade ago
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.
JJ
Jan 3rd 2012
1 decade 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.
JJ
Jan 3rd 2012
1 decade ago
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...
Sean
Jan 3rd 2012
1 decade ago
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.
Geoff
Jan 3rd 2012
1 decade ago
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.
PHP
Jan 4th 2012
1 decade ago
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:
Summer11
Summer10
Password1
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.
JJ
Jan 5th 2012
1 decade ago