Re: Test the Strength of Your Password Policy

Reading sraveau's twitter posts, I was directed to this article by Robert Grimes on evaluating password policies. It's an interesting read and it includes an Excel spreadsheet where you can enter in your password creation policy, (aka passwords must be 8 characters long and contain an uppercase letter), the expected attacker strength (number of guesses per minute), and your password expiration policy. In turn it will output the probability of an attacker being able to crack one of your user's passwords. I do have a few issues with it though, hence this post.

1)I'm becoming more and more convinced that the protocols that govern login attempts are a bigger deciding factor on password security than password creation policies. This actually merits it's own post, but the short answer is that login attempts need to become more "costly" as the number of incorrect logins increases. This prevents a legitimate user from being locked out due to a password guessing DoS attack. On the flip side, if you can limit an attacker to one guess every two minutes it can make even a "weak" password fairly resistant to password cracking attacks. Of course, the downside is that your normal user/sysadmin usually can't do anything to implement this as they are dependent on the tools/operating system they use. That's why I have a blog though, to hopefully convince people this is something they need to demand from their vendors ;)

2) The size of the user-base should also be taken into account. Trying to crack 1,000 passwords vs 1 is much easier because you are almost guarenteed to have one person who selected the password 'Password123!'

3) While trying to measure the entropy of password creation policies is useful, I agree with about every single written paper on the subject that measuring the entropy is a HARD problem. Humans just don't do random well, and an attacker can take advantage of that in various ways that are hard to abstractly model.

4) While this doesn't apply to evaluating password policies, I do think evaluating the strength of individual passwords is a much easier problem. This is the engineer in me speaking, (vs the scientist), but we already know the main attack techniques out there. Access Data makes their ruleset available online. We can download Cain&Able, and L0phtcrack (It's back!!!), to see their rules. John the Ripper is a little trickier since many users create custom rules, but some samples are available here and here, (or my own examples here). Same goes for Hydra or any of the other popular password cracker programs.

5a) The problem is that even when there is no hashing, running these password crackers can take a long time, (especially Access Data's PRTK which will run pretty much forever). To help solve this, one approach is to use a modified edit distance to evaluate passwords to try and figure out what base words + mangling rules were used to create them

5b) Take the password 'P@$$Word123'. It's fairly trivial, (as a human), to look at it and say that I created it by taking the word 'password', capitalizing the 'P' and 'W', changing the a->@ and s->$ and finally adding '123' to the end. I can then look at the various password cracker rulesets to try and find a rule that would match it. Once you have that it's a piece of cake, given an input dictionary, to find out how many guesses it would take to crack that password. This gives you a very accurate idea of how strong your password is.

5c) As I said, my main approach to this is to use a modified version of edit distance to identify the mangling rules it required to create a password. I very briefly mentioned it in my Defcon talk last year and you can see a horribly coded version of this in my defcon submission packet.

5d) The advantage of using edit distance is it's really fast, (seconds), though I admit that I use a bunch of shortcuts so I probably should use "finger quotes" when mentioning the term edit distance, (calculating the true edit distance isn't really necessary).

5e) The main downside is that to calculate edit distance it requires an input dictionary similar to one that you expect to be used by the attacker. This is the hardest part to estimate since input dictionaries vary widely depending on the attacker.

6) As to the conclusions presented in the article: I've said it before but I'm not a big fan of password change policies to prevent password cracking attacks. Password length does help a lot, but once again it puts the burden of security on the users which never ends well. Ideally the security to limit password guesses should be built into the back-end of the system. In the meantime I think checking passwords against existing password cracker rulesets as part of a user's password selection, (rejecting the password if it is deemed crackable),  has a much better chance of increasing security vs. forcing everyone to choose a long password and then having users take shortcuts, (such as typing the same password two/three times, using keyboard combinations, etc).

7) Of course, what do I know? If you disagree please leave comments as I truely value the feedback. I admit, I've been wrong about many things before and I have no delusions that will change in the future ;)