Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: Analysis of the Stratfor Password List - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
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)

Rick

277 Posts
ISC Handler
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.
Anonymous
Posts
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.
Anonymous
Posts
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.
Anonymous
Posts
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.
Johannes

3294 Posts Posts
ISC Handler
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.
Anonymous
Posts
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. http://en.wikiquote.org/wiki/George_Mallory :-)

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.
Anonymous
Posts
@jj
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...
Anonymous
Posts
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.
GeoffB

3 Posts Posts
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.
Povl H.

71 Posts Posts
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:

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.
Anonymous
Posts
It's funny, as I got bit in the hind end of actions that I suggested.
I worked for a DoD contractor and went, largely by default and disposition, into the IA position for our hind teet installation.
I suggested to the DoD CIO, after numerous fails in getting local command support, to make the directives mandatory, WITH an expiration date for certain non-compliant configurations.
FIRST amongst those was password requirements, even for service accounts.
We also had a theater level communication issue, so the directive was missed in being transmitted.
EVERY account in our theater expired at once. I noticed my account expired on start of work and set a password with no problem, a few exclamations and obscenities were heard in the rest of our office as other SA/NA/OU administrators had problems making a password. That triggered a memory of the old directive I had discussed with, following our chain of command, "upstairs" and we had less of an issue after in passwords.
We THEN, over the course of the morning, noticed services failing randomly.
I burst of intuition suggested to me, look in AD and see the service account properties, as in password properties. Change password on next logon was selected.
A call to the theater NOSC was replied with, yes, we did that, under orders (with zero information, as nobody there knew WHY the order was given). I passed the word to the admins locally what was done and ordered and we ALL set about resetting service account passwords.
I privately explained, in our morning meeting, WHY it happened and all had a laugh at our theater folks being in the dark, along with annoyance at the thunder from above with zero warning.
I expanded my review of directives after, with greater results.
Initially, when I assumed my IA position, I was the greatest PIA in the universe, even IF I also patched systems for the shorthanded LAN/WAN group.
After that day, I sent bulletins with upcoming directives, intelligence briefs of known vectors and phishing (and my shop's response) and assorted other tidbits that "made sense" of what we required.
From that password mess day, we had ALL accounts with admin level access with 15 digit, complex passwords that had clear a mandatory and annoying password filter. A filter I use even today, mentally, when making my own passwords, whether at home or at work.
And passwords that passed 5 days of John with zero success at all.
That was only ONE facet of our security. Rather strict patch schedules, antivirus UP TO DATE AND WORKING and our perimeter security were all monitored and rapidly responded to.
When the entire theater was infected by W32.Silly, my are of responsibility wasn't. The infection elsewhere wasn't due to failure of AV or "zero day", but due to inattention to the antivirus operation and definitions AND patches ONLY. It only cost the DoD a billion dollars to clean that mess up.
WE stayed clean.
Due to basics.
Strong passwords. End user education, at LEAST ANNUALLY (GET INFECTED AND GET RE-EDUCATED). Patch and AV up to date. Perimeter defenses were the LAST resort.
Wzrd1

8 Posts Posts

Sign Up for Free or Log In to start participating in the conversation!