Reusable Security

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...

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.

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

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 crac...