Blog post

Research into dealing with weak domain passwords

Created:  14 Aug 2017
Updated:  05 Feb 2018
Author:  Andy P
broken lock
We are no longer looking for participants for this study, but we would like to thank everyone that has contacted us for their interest.
A follow-up blog post, including a link to the tools we used here, has now been published.
Andy P
EUD Security Research Lead

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.
Mark Richards - 21 Sep 2017
Let's start by doing salting hashing on the client side (no password over the network, means it is harder to capture... I wonder how many Equifax passwords were sitting in memory for months during the attacks). It was the only good thing about the idea of http-digest... Although easily compromised given no TLS.

New html5 input attributes would help: hash_value=true salt=".." hash_alg="sha-256".

Then I recommend 2fa enhanced Keypass style management.
Mark G - 22 Sep 2017
This kind of trivial password list approach is exactly what I was using on the AS/400 in the early 1990s! The world of technology is oddly circular.
Andy P - 22 Sep 2017
Hi Mark. Sometimes the simplest things can be the most effective.
Graham - 22 Nov 2017
So - like the guidance to use a password blacklist - which one? The 'top 10,000' would work for me - I don't need the 306 million 'pwned' passwords.

There are providers of a password service which involves checking against their server - I don't see a need for passwords to go offsite....

Then applying the password blacklist in a Microsoft environment - is there a simple method that does not require development? References to 'custom password filter noted'
Andy P - 24 Nov 2017
Hi Graham. Part of this research is to try and find the most appropriate number of common passwords to blacklist. We think it’s around 10,000, which is a nice balance between being effective but not logistically difficult to move huge lists around around.

The 300 million + databases are multiple gigabytes of data and would be cumbersome to move around, and there’s naturally a reduction in marginal benefit for each additional password on the list. The best solution would be to have something built in to the operating systems, and I’d encourage readers to raise this feature request with their operating system manufacturer of choice.

Alternatives are third-party products, custom filters developed in-house, or doing restrospective audits of passwords that users set to highlight any weak passwords. The tools we’re using to collect data for this project can be used for the latter option, so get in touch if you want to try them out.
Huw W - 01 Dec 2017
How complex would it be to make the blacklist a little more subjective? Lets say I work for Contoso then a password of Contoso123 is very weak, but if I work for Apple then a hacker assuming they know who I work for is unlikely to try Contoso123. Similarly <<firstname>>123 should not be allowed, but probably won't show up in the lists of common passwords as there are lots of different first names out there!!
Andy P - 05 Dec 2017
Huw, that's a great suggestion. If you are making feature requests to your favourite OS vendors, please do include such a suggestion with it.
Tabitta - 07 Mar 2018
good to know some of the new tips
Zarif M - 09 May 2018
Andy P - It would be good to obtain some further information on the tools which were used throughout this study. Sadly we've missed the opportunity to participate in this but would be interested in hearing about the results and outcomes.
Andy P - 15 May 2018
Hi Zarif. You may be interested in reading my latest blog -

Leave a comment

Was this blog post helpful?

We need your feedback to improve this content.

Yes No