A Story About Password Auditing

Hi everyone, sorry I haven't blogged in awhile. Life gets busy and with the recent boom of generative AI I wasn't sure about sharing original content like this that will inevitably be scraped and used to train models. Anyway, on to the story.

I enjoy learning from platforms like TryHackMe and HackTheBox. One technique I learned was how to obtain Windows password hashes and crack them using rainbow tables and Hashcat permutation rules. I thought this was really cool and it got me curious, how good or bad were the passwords in production? I got permission from key stakeholders, grabbed the password hashes, and ran Hashcat to crack them. Immediately my screen was flooded with hundreds of very weak very easily guessable passwords. I was shocked, was this real? I tested a couple and confirmed they were indeed real passwords.

 

 

How was this possible? We had a password policy with complexity and minimum length requirements. I began digging deeper and discovered that it was easy to meet the complexity requirements with a weak password. If you have four minutes to spare I recommend this very relevant bit by comedian Michael McIntyre

 

 

Let's take a closer look at a fairly common password policy that:

1. Requires an uppercase letter
2. Requires a number
3. Requires a special character
4. Requires a minimum length of eight characters 
5. Must be changed every 90 days
   

 

Password123!

Welcome2020!

Ihatepasswords1!

 

These are all acceptable passwords according to the password policy. Even worse, with rule number five forcing passwords to be changed on a regular basis, I saw that people were lazy and will simply increment a digit so "Ihatepasswords1!" becomes "Ihatepasswords2!" or "Welcome2020!" becomes "Welcome2021!".

 

I felt a sense of regret having looked under this rock to discover such a huge problem, but I soon started working on a solution. I started by improving the password policy. If you read up on NIST Special Publication 800-63B it says some things like:

1. Elimination of complexity requirements: NIST advises against enforcing arbitrary complexity rules (e.g., requiring a mix of upper-case letters, symbols, and numbers). Instead, passwords should be checked against known compromised credentials and prohibited password lists.
2. Elimination of regular password resets: NIST recommends not forcing users to change their passwords on a regular basis unless there is evidence of compromise. Regular resets often lead to weaker password choices due to user frustration.
3. Preference for longer passwords: NIST encourages using longer passwords or passphrases, as they provide better security than shorter, complex passwords. Longer passwords are harder to crack and easier for users to remember.
   

So here's my plan:

1. Remove the complexity requirements
2. Increase the minimum length requirement and educate users about passphrases
   
3. Remove the requirement to force a password change on a regular interval, it should only be necessary when an external event requires it
4. Create a custom list of banned keywords that are industry, brand, and country specific
   
5. Install a password filter to check the password being set against a list of known compromised passwords (something like 20 billion and growing with every breach made public)
   
6. Setup a password auditing tool to run on a weekly basis. This is important because the list of "known breached passwords" is always growing and it gives us an opportunity to see if a password is in use that was recently added to a breach list. The filter will only check it at the time the password is set.
   

 

I am happy to say that after some time, the project was a success. It took a lot of time and effort. I had to coordinate with many disparate teams, learn new technologies, educate thousands of non-technical people, implement new standards, force a lot of password resets (and probably upset a few people), participate in dozens of meetings, write documentation, coordinate schedules, and work with vendors. What started as a curiosity took me down a road I was not prepared for, but am glad that I did because I learned a lot and felt like I made a significant contribution to improving security.