About a year and a half ago my organization was looking at implementing a new password standard. At the time our password rules only required that user's password needed to be at least six characters long. Passwords were good for almost a year and there were no rules against re-using the password. The proposed standard would impose new hardships on our users but would also hopefully make our passwords more resistent to guessing and hacking. We had decided on a standard that required passwords to be at least eight characters long and required some combination of mix case, numbers, and symbols.
To test the new standard out, I took a sample of our passwords and analyzed the resistence of the sample when faced with a simple dictionary attack, an attack with some mutation, and a rainbow table attack. I covered my results here and here.
Well the months have gone by since we implemented the standard in January of 2009 and I decided that it was time to take another sample of our user's passwords and see if our new standard has created a noticable difference in our password strength. I had hoped to do this monthly and chart the trendline, but life got in the way of plans. I followed the same procedure that I outlined in the blog posts above to get a statistically significant sample that would give me a 3% margin of error and a 95% confidence interval.
I started with a simple wordlist attack using basic mutation. I used Cain & Abel to perform the attack and I used a John the Ripper word list called "all." For the mutation, I used the default settings in Cain & Abel. I was able to analyze the sample in about 15 minutes with this approach. In 2008 this technique revealed 313 of the 1027 hashes in the password sample, or about 30% (714). Now only 139 of the 1027 samples passwords were broken with this technique. We can report this as a 24% improvement in password strength or a 55% reduction in badness. Obviously I am pretty happy about this, and I think this really demonstrates that our new standard has resulted in higher-quality passwords.
Now I decided to run my anonymized sample through Ophcrack. With Ophcrack the complexity of your password matters less than it does in a dictionary attack. It only took ophcrack 2 mins and 23 seconds to crack as many passwords in the sample as Cain & Abel did. At the 30 minute mark 59% of the passwords in the sample had been broken. At the 60 minute mark 68% had fallen. When it was all said and done, 712 of the 1027 passwords had been cracked, or just over 69%. In 2008 when we did this analysis over 80% of the passwords fell to this kind of attack. If you remember, each of our samples has a margin of error of 3% so it is possible that there wasn't much of a change in the effectiveness of rainbow tables on our password database.
Still, for an outside attacker trying to gain access to user accounts, a password attacking tool might be the weapon of choice. So I feel good having improved things a bit. Now I can enjoy my weekend.
3 comments:
Could you describe in some greater detail how (from where exactly) did you get the original fgdump list?
@Miha
To gather the master list of password hashes I had a system administrator run the fgdump utility on a domain controller. This can be a bit tricky because anti-virus software will alert on the file. So first we have to temporarily disable real time protection, then run fgdump.
Also when running fgdump, we had to turn off the feature whereby it tries to disable antivirus (which we've already disabled). I believe that is the -a option, but I'm not positive right now.
There are easier ways -- FTK Imager lite does not (as yet, anyway) trigger AV, and does not do anything too unpleasant to the system it runs on.
I'd like to add that password security should not be about about what passwords individual users set. Leaving last line of defense in the hands of users is just not done.
Instead it should be about the authentication situation where those passwords are used. How fast can a password-guessing attack be done? For how long can an attacker do such an attack before he's discovered? And, of course, how many guesses would it take to find a password under those conditions. Increasing password strength (i.e. how long it takes to guess the password) is not necessarily the most efficient countermeasure.
Even a very liberal lockout policy (say, after 20 failed attempts per hour), puts a very effective stop to prolonged password guessing without inconveniencing users or support desk. Add to that logging failed authentication attempts in general, and analyzing the general situation,and even slow-motion attacks can be discovered.
In that kind of situation, passwords only need to withstand a much smaller number of guessing attempts until the attack is discovered and controlled.
In other words, the effort is probably better spent improving the full authentication situation that only passwords.
In general, that is -- in this case, you may already have those things controlled to the point where passwords are the next step.
Post a Comment