HaveIBeenPwned - THE database of breached credentials
Thanksgiving is a special time for me because, being Canadian (we get Thanksgiving in October), I don’t have a holiday but many of my colleagues and most of my customers are away. This leaves me some time to catch up and do some other things I don’t normally get to try. This year, feeling particularly thankful for the latest additions to the HaveIBeenPwned database and the great work that its founder Troy Hunt does for the community, I decided to look into what was added in the latest HIBP update - and put on a white hat for a day.
The HIBP pwned passwords Database is a 2 billion line file of password hashes from known bad passwords. We are lucky enough to get access to that database (thanks to haveibeenpwned.com) to check for existing bad passwords and our customers can leverage this to stay NIST compliant and make sure their users are not using passwords that have previously been breached. This includes a lot of bad passwords. Some random examples:
-
Summer2025
-
Password123!
-
Maytheforcebewithyou
-
Netwrix123
-
F@rnham
Some of these passwords are ones users tend to want to use - especially 1 or 2 are extremely common patterns and customers tell me they are found in PEN tests on a daily basis. They are often meet length requirements, contain an upper and lower case character and a number or a special character. This means, that they satisfy password requirements for Windows out of the box GPO driven password rules. These kinds of patterns are exactly why we need a tool like Password Policy Enforcer.
Having longer passwords will block some of these. (Everyone should have a minimum of at least 12 characters for AD passwords nowadays). So 1, 4 and 5 are out. However, #2 would still be accepted and is the worst in the list. #3 (Maytheforcebewithyou) is arguably the strongest password in the list but is breached. Which is where checking the HIBP database comes in. We really want to check those long, strong passwords against passwords that may have been re-used by your users elsewhere. In fact, the shorter passwords are just noise as your length rule should block those.
This brings me to my revelation: The HIBP database is mostly junk.
The majority of the passwords in the HIBP (or any other breached database) are really uninteresting since they are shorter than 10 characters and under no circumstance should your password length requirements be less than 10 characters… or even 12.
But what’s important about the HIBP database is not the junk, but the rest… the long, strong passwords that are also breached. These are the reason we want to see those frequent updates with the latest known bad passwords.
So, with the latest, huge addition to HIBP, I set off to evaluate what was in the latest release. Is it really fresh content or just more weak passwords (Answer = it’s a mix). Since all we get is a list of hashes, I had to do some cracking myself to see what some of those passwords are. My assumption based on the source of this new data was (correctly so) most of this is also just old data that has surfaced and was not previously added. But there are some strong passwords that users would use or may be linked to other credentials.
To do this check, I used a couple of techniques. First, I grabbed 5 random hashes from the addition and ran them through Hashcat on my Kali Linux VM. I was able to crack 3 of them on a on the slow VM on my old desktop within a few hours. If I was using proper hardware this would have likely taken minutes.
The ones I was able to crack easily were:
-
Fr*U5rie
-
917382587
-
F@rnham
None of these are long enough. But it’s interesting that #1 looks like what we would normally consider a great password. I’m sure whoever is using that password is quite confident it’s a good one. After this result and since I was using rockyou.txt (a very common, famous list of compromised passwords) I thought that maybe checking the hashes against this list directly might be a more efficient method than trying to crack them with hashcat. So to do this I built my own tool that builds a database of all the HIBP hashes and then hashes the rockyou.txt passwords and compares against the database. My tool looks like this and I was able to find 275,802 passwords in the new HIBP update that are in Rockyou.txt.
I was a little surprised to find that these were not already included. What’s more is that a test of Rockyou.txt which has over 14 million known bad passwords returns 19498 that are not in the HIBP database (even including the latest update).
One great example of a very bad password is “sonlymylove” listed at 19490 and if tested in HIBP shows “Good news — no pwnage found!”. This password was likely ‘onlymylove’ but had the s added at a password rotation, showing the kinds of weak patterns humans will apply to password resets and why we should be moving to longer passphrases and not requiring password rotations unless the passwords are found in the breached database.
The good news is that IF you are using Netwrix Password Policy Enforcer and/or using at least 12 characters, this oversight won’t matter. All of these passwords will be blocked by one of PPE’s other rules.
The bottom line is that checking a breached password database is an important aspect of password protection. However, its value is in finding good passwords that have happened to be re-used by users and breached - then accessed by bad actors and used to log in. Most of the HIBP database is weak passwords but those should be blocked by good password policies.
The HIBP database is full of garbage but it still has great passwords in it. Likely, the 2 of 5 that I was unable to hack represent long, strong passwords that were breached and the users may have used in multiple places - and that is the importance of having both strong policies and checking HIBP. Each method on it’s own is not sufficient.