Blog post

Research into dealing with weak domain passwords

Created:  14 Aug 2017
Updated:  14 Aug 2017
Author:  Andy P
broken lock

In 2015 we published some pretty revolutionary password guidance which highlighted widely accepted password policies that we thought caused more harm than good.

The feedback from this guidance has generally been very positive, but certain parts of it have proven difficult for some of our customers to implement. This blog post discusses these issues, and what we're trying to do about it.

Two of the key recommendations in the guidance are:

  • Help users cope with password overload
  • Help users generate appropriate passwords

One of the things system administrators would like to do (to address both the above points) is to turn off password complexity rules, and let their users pick memorable passwords which work for them. However, this would mean that there’s nothing stopping users from picking passwords like password or letmein, which frequently appear in the "most common passwords" lists worldwide. To mitigate this, we tell users not to pick "obvious" passwords. But of course not all users have the same idea of what an "obvious" password is. And when we can't see or control users' password choices using technical means, we don't really know if they're following our advice or ignoring it.

So is this approach effective? If you assume an organisation has a policy where password complexity is not enforced, but an account locks out after repeated failed login attempts (say, 10), there are two key attacks that need to be prevented:

  • An attacker brute forces the most common 10 passwords for every user of the system;
  • An attacker trickles in 9 passwords per day from a list of common passwords; the user logs in and resets the count.

To stop these attacks, we added an extra mitigation into the password guidance – “Blacklist the most common password choices”. If you’re developing your own application then that’s fairly straightforward to do, but if you’re a Windows network administrator then it’s not obvious what action you can take here.

We’re working on a number of solutions to try and address the common passwords problem, but first we’d like to collect some data on how much of a problem they are in Windows domains. We’ve built a simple tool that generates some high level statistics on how many "Top 10,000" passwords and variants there are in your organisation, and therefore how much of a risk it is for you. It's simply a Powershell script which takes a few seconds to run and outputs a simple text file. This text file contains anonymised data which we can use as part of our research study, and we’d be grateful if you’d share those statistics with us (though there is no obligation to). As the script looks only for known passwords that generally don't meet any complexity rules, the results are only going to be meaningful if users can choose their own passwords and you don't enforce complexity on your domain.

So if you're a network administrator who doesn’t enforce password complexity on your Windows domain, and you want to know how much of a problem commonly-used passwords are in your domain then drop an email to and we’ll be in touch with the necessary tools. For now, we'll limit participation to organisations that handle OFFICIAL information, but we'll share our tools more widely afterwards. We look forward to hearing from you in the near future.

Andy P
EUD Security Research Lead


Martin R - 16 Aug 2017
This topic is interesting given the recent 'U-Turn' on 'guidance' from NIST: in their SP800-63-3 suite of documents... From SP800-63b, Section Passwords (memorised secrets): - verifiers SHOULD permit subscriber chosen passwords at least 64 characters in length. - verifiers SHOULD NOT impose composition rules (character types, capital letters, numbers). - verifiers SHOULD allow ‘paste’ functionality for password entry. - Verifiers SHOULD NOT force passwords to be changed periodically.
Andy P - 16 Aug 2017
Martin. Thanks - we’re aware of the NIST guidance and it nicely aligns with the recommendations we published in 2015 (linked above), and we’ve been blogging about for some time now (
Darren D - 18 Aug 2017
I'd be interested to see how a simple PowerShell script can generate a list of the most commonly used passwords in a Windows environment in a few seconds. Passwords are (almost) never stored using reversible encryption in the AD database. Only the encrypted hash is available unless you intercept passwords at the client at login or at password change at the DC. If you have access to the database you can decrypt the hash (if you have the PEK) but you can’t reverse the hash function. Can we see sample code?
Phil Ashby - 28 Aug 2017
I suggest this will be a simple brute-force comparator, working through the top 10,000 passwords in common use (for English-speaking people?), hashing with the readable salts from AD and comparing the results with the hashed data stored in AD. If you want to go it alone, you could obtain a similar password list and an AD dump, then run those through a tool like hashcat or JohnTheRipper. I suspect this blog entry is aimed at people with less time on their hands...
Andy P - 30 Aug 2017
Yes we work forwards from a wordlist, generate the hash and do an online compare to the database held on the DC. We can also identify duplicate passwords by comparing hashes directly on the DC. If we have a match we’ll know which password generated the hash. If we don’t have a match, we won’t. This is nothing one can’t do already with numerous pentesting tools, but we also generate some anonymised statistics to use in our research.
Will Robinson - 28 Aug 2017
When you say this is limited to handlers of OFFICIAL information, are you saying this research is limited to public bodies only? Darren - I'm not too sure what hashing algorithm is in use for AD, but an MD5 hash can be checked against common passwords by simply hashing the password and testing the hash Vs the hash (assuming no salt).
Andy P - 30 Aug 2017
Will – yes we’re testing some hypotheses about password strength in organisations that handle OFFICIAL information. Of course the tools themselves work on any domain, but we don’t have the capacity to provide much technical support just now - hence the restriction. We’ll make the tools more widely available afterwards.
David - 06 Sep 2017
How about using Certificates ? We've been working on this idea for a few years, no product / clients / revenue yet - just lots of effort and prototypes.....But, if it's good enough for Banks to 'prove' their identity - Surely it could be an option for people / cars / IoT too ? Just a thought....
Penny Lavie - 18 Sep 2017
I find through my work on a daily basis that many people have little to no idea of how best to formulate or manage passwords. Blogs or other forms of information are sort only by specialists. A national media campaign in my opinion would go a long way to bridging the gap.

Leave a comment

Was this blog post helpful?

We need your feedback to improve this content.

Yes No