When extracting hashes from an active directory database for password auditing purposes, it can also possible to extract hashes of a user font-size:11pt">I work for a global Fortune 500 company where employees number in the several tens of thousands. Our password policy isnt monolithic, but at the core it varies some from the nebulous industry standard. One of the elements that is different is that we ask users to rotate their passwords more frequently than most. For our most sensitive users, that is every 30 days.
ze:11pt">Password discussions are numerous out there on the internet and there have been many articles of late suggesting that frequent password rotation just causes users to iterate their passwords on the same core string. Password1 becomes Password2, then Password3 and so on. We had some spirited internal discussions about whether we should relax our policy in accordance with this guidance. Ultimately, we decided that we wanted some data on password security in our environment. People can blog all they want about opinions, but the best security decisions are made with data to support them.
font-size:11pt">So we set out to measure how often our users made use of a shared string when constructing their passwords, and also how secure our users passwords actually are. To be clear, Im using the term measure here in the sense that we are trying to reduce uncertainty about a subject, not trying to know exactly the size/shape/scope of a thing. (For more on that, I recommend How to Measure Anything font-size:11pt">Measuring passwords meant (to us) password cracking. Before going further, I want to be clear that we obtained permission from our Legal department to conduct our password auditing after satisfying them that we were taking due care with user passwords and privacy. Im not going to go into those details here, but suffice to say that permission is essential for activities like this.
font-size:11pt">One of the things that we wanted to demonstrate was the effectiveness that password cracking could have - and in what timeframe. Accordingly we built a very moderate cracking rig for both financial reasons and also to show what a simple setup could achieve. We bought a motherboard which could handle two modern graphics cards, a cheap Intel Celeron processor, and 2 GeForce GTX 1070 graphics cards. We scraped together some stray RAM, scavenged an old desktop case, and with some ingenuity, crammed the new hardware into the old case. Its a Frankensteinian monster - nothing sleek or sexy about it. But its functional and cost less than $2000 all told.
font-size:11pt">In an enterprise, the best place for a treasure trove of passwords to crack is the ntds.dit file on an Active Directory Domain Controller. That, in combination with the SYSTEM hive gives you access to all the passwords in AD. In our environment, ntds.dit turned out to be 5 GB. Thats...pretty large.
font-size:11pt">this tool). Happily, secretsdump worked much faster and gave us what we wanted within our lifetime.
font-size:11pt"> wanted to crack a password currently in use if we could help it.
font-size:11pt"> and the default rules available in hashcat for a series of hybrid attacks. We tried various iterations with that wordlist as well as some created from observations about our environment in a hybrid attack (wordlists plus rules generated by hashcat). Eventually, we turned to a little brute force cracking to bat cleanup. We brute forced all passwords from 1 through 8 characters in length in our environment. All told, we spent roughly 6 days of cracking time (several weeks of real time juggling other projects and troubleshooting this or that), 5 of which were just the straight brute force attacks.
font-size:11pt">Below are some statistics about what we learned by analyzing our cracked passwords. Please note, these observations are only on the passwords which we cracked, not the 80% which we havent (yet). By necessity, we cracked the easy ones first of course, which included the ones with shared strings. So although these observations are certainly interesting, they are necessarily skewed towards users with poor password hygiene. Just something to keep in mind.
font-size:11pt">19 characters - the longest shared strings observed. One of them was Thisisalongpassword - maybe so, but not good enough to avoid being cracked.
font-size:11pt">With the help of Didiers script, we certainly learned a lot about the use of shared strings in our users passwords. However, we were not able to find the data to conclude anything concrete about the relationship of our password rotation policy and the use of shared strings. Thats ok though, because by running through the cracking process we did show that the difference between a 30 day rotation policy and something longer is not going to make much difference.
font-size:11pt">We clearly demonstrated that a moderate cracking rig run by people who don font-size:11pt"> of them within days. No password rotation policy will stay ahead of that.
font-size:11pt">Therefore we should a)make sure that all our passwords are longer than that, b)make sure that its really really hard to crack passwords at an enterprise scale (protect your Domain Controllers!) c)adjust our password rotation cycle to ease the burden on our users and d)continue to emphasize the importance of good passwords and educate our users on how to construct them.
font-size:11pt">There are other obvious conclusions that can be made here - two-factor all the things for example. None of these conclusions are ground-breaking or anything that you, as a security professional, did not likely know before reading this article. But this wasnt really an exercise in demonstrating that passwords are dead or the weakness of relying on passwords as a sole means of authentication. It was an attempt to measure user behavior, justify security policy changes with data, and track the impact that adjusting those policies may have on our users/our security posture.
font-size:11pt">In the first two of those goals, we feel that we have succeeded well.
font-size:11pt">I said it before, but its worth saying again: thanks to Didier for his contributions to our efforts and the community at large.
Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com