Monday, March 30, 2009


I ended up writing my own password cracker, since John the Ripper does not do well with auditing large password lists. Looking through JtR's code was interesting because it's fairly shocking to find out that A) The guesses per second it displays in its status updates are only loosely related to reality to put it nicely, B) It doesn't use binary search to check to see if it cracked a password or not.

I'll admit my password cracker currently is a quick and dirty implementation, (aka I put it together this weekend), and there is a lot of room for improvement. Still I'm finally able to make guesses fairly quickly which has been a godsend. Seeing the newly cracked passwords flash across my screen is proof enough. In a couple of days I should have enough passwords cracked where I can post a detailed analysis of them.

*Edit: I want to specify that this custom password cracker is different from the one I mentioned previously. That one only generates password guesses but it generates those guesses in probability order. More on that later ;)

Wednesday, March 25, 2009

Another preview

I'd never thought I'd say this, but Cain & Able is actually much better than John the Ripper for auditing large password sets. It took those 300,000 passwords and was ripping through them like a champ. Even though the rule selection is poor and it doesn't support the ability to perform targeted brute force attacks, it's at least letting me prune down the list so I can crack the hard passwords using John.

Also, I've been trying our custom password cracking program, (more on that later), on subsets of the list and it's doing amazinly well. Unfortunatly I use John the Ripper as the backend to handle all the hashing and checking, (What can I say, I didn't feel like reinventing the wheel), so it has issues with trying to audit the whole list.

Sunday, March 22, 2009

A quick preview

John the Ripper really doesn't like it when you try to load around 300,000 password hashes into it...

Friday, March 20, 2009

Password Expiration Policies

Directly after my Shmoocon talk on Rainbow Tables someone asked me how often should they force users to select new passwords. I was trying to get off the stage and make way for the next speaker so my reply was a bit disjointed, but the core of it was, "Password expiration policies are worse than useless when it comes to stopping password cracking attacks. They can be useful to limit insider threats, but at that point it becomes a policy, not a technical issue." Since this is a blog, I'd like to spend a little more time explaining that position.

With any security procedure, policy, or technical solution, it is very important to identify the problems you are trying to solve with it. When it comes to password expiration policies, most people's views are as such:

Myth 1) If a hacker breaks into our system, by the time they crack our password it will have expired so it won't do them any good.

Reality: Thanks to pass-the-hash attacks, most hackers don't need to crack your passwords in the first place. Even if that didn't work, they already have admin access to the box and keystroke loggers are wonderful things. Basically, you're already hosed and the password change policy isn't going to help you. Even if they gained access via an online attack, (aka they didn't break into the box but simply guessed the correct password. Think the twitter attack), a password change policy won't help you that much because the vast majority of people choose similar passwords when their own ones expire. Finally, there's the fact that a vast majority of passwords, (due to weak password hashes), don't require that long to crack.

Even worse reality: A password change policy invites people to be lax and sloppy with their password selection since they will just have to change it in a couple of months. Also it increases the amount of forgotten passwords, and the number of passwords written down. Finally it dramatically increases user frustration with security. User patience and acceptance of security measures is a valuable resource more important than any firewall or IDS. You shouldn't squander it needlessly.

Myth 2) If an attacker gains access and the password, it will kick them out of the system once we update our passwords.

Reality) That's cute. See the above.

So now that is out of the way, why am I being wishy washy and not saying to never use password expiration policies? Well, because I think it does help with two different problems to various degrees.

Problem 1) Helping to prevent against "Privilege Escalation Creep." I can't name the number of places where I've gone back a year latter for some reason and all my old accounts are still valid. Let's be honest, proper authentication revocation almost never happens when people leave, move on, or are promoted. This goes double for anyone who is a system admin, network admin, or basically has access to the good candy.

Where it can help: What a password expiration policy does is to help automate authentication revocation. If someone hasn't logged in to the system in six months, then they are locked out regardless if someone remembered to delete their account or not. For this to work though you have to have true password expiration. You have to lock the account after a certain amount of time. If they log in two years later and all the system does is force them to choose a new password this doesn't help. This actually can cause a lot of problems. You know that firewall that's been up for the last eight months? When it goes down and nobody can log into, that's a problem.

Problem 2) "The gossipy insider threat." Let's be honest, people share their passwords ... a lot. If it's 3am in the morning and the firewall is down, I'm going to be fairly receptive to the idea of giving the NOC guy my password so we can troubleshoot it over the phone.

Where it can help: If I change my password later, that persons access to my account is cut. This assumes though that I truly change my password instead of just going from "password1" to "password2". Also though my research I've found that once you know one password someone uses, it becomes much easier to break other passwords of theirs. "Wow they like !!!exclamation marks!!!", or "hey, they put numbers in front of their password."

What this means: When selecting a password expiration setting, it really does become a policy issue. The main questions should be "What is our concern about insider threats?" "How good are we are removing old accounts?" "Can we make it infrequent enough that we can convince users to significantly change their password when it does expire."

Personally I generally support a six month to one year password expiration policy simply to get rid of old accounts. I can see three months, but with the amount of passwords people have to remember I think that's a little too aggressive of a timeline and inches more into the self-defeating category. Quite honestly I think it is better to instead focus on getting users to use different passwords for different jobs. You can make a deal. "We won't make you change your password every three months, but we want you to use a different password when logging into the webserver vs the firewall." I think that would be more productive.