Password Reuse and Data Breaches

Password Reuse and Data Breaches

Everyone knows the story of registering for a website we only ever intend to use once, where we lazily re-used a password. Fast forward 15 years later, you find out that website’s password database was storing everything in plain text, someone bad got a hold of it and you never knew.

It’s a surprisingly common story and there is a stigma of shame around talking about personal password hygiene. One thing we can all do is tell the people we are close to that it’s never too late to start improving, recommended password managers and good multi-factor solutions to get the ball rolling for them.  Password reuse is hard to get out in the open as it is a very private issue.

Luckily, there is now a solution. Troy Hunt has teamed up with Cloudflare to provide a free API that allows passwords to be checked against known passwords that have been seen in reported breaches. Steer people in the direction of Troy Hunt’s Have I Been Pwned website and it may give them the wake up call they need, when a big scary red box flashes up on the screen letting them know that their data may not be safe.

What can we do then on an organisational level?

The personal touch of reaching out to people directly doesn’t scale well and can often come across as intimidating when coming from “the security team”. The experience of setting a password is a very private one and the strong password guidelines need to make their way into this personal experience. We have been asking users to set things like reasonable password lengths and complexities through web frameworks for a long time now. The instant responsiveness of this has been training everyone that password length and complexity matter, but what about reuse?

Troy teamed up with Cloudflare to deliver a free API endpoint to check if a password has shown up in reported data breaches last year. What this means for organisations is that on your password reset page or even login page you can query this API endpoint every time you type in a password so see if it has shown up in a breach before.

Doesn’t that mean Troy now has my new password?

Nope! The API has been designed so that only the prefix of the hash of your password is sent to the API endpoint and you get back all hashes that match that prefix, you then check to see if your hash matches any of the returned results. Hashes are designed for obfuscation so sending through the first five characters of your hash doesn’t reveal your password.

Passwords that will have the same first five characters will have no relevance to one another. For example the first five characters in the hash for “alexguo029” is “21bd1”, while the first five characters in the hash for “lauragpe” is also “21bd1”. Therefore if an attacker was able to capture the data sent to the API they will not be able to gather any sensitive information. Read more about the technical details in Troy’s blog.

Can I easily implement it on my infrastructure?

Yes! We can query this API in client-side code without ripping apart any of our current systems. Client-side code works for this as it’s more of a user education exercise than another security layer. Check out some implementations on GitHub like passprotect-js to see just how easy it is. There is a great demo video and example code showing how the prefix of the password hash is generated and sent to the API and instantly gives the user feedback showing the tangible evidence that the password is not safe to use. 

This is an easy win and with the recent password collection dumps it is more valuable then it has ever been. Run it in a development environment today as a proof of concept. To lead by example this is a demo I ran up on the AUSCERT website just this morning using passprotect-js.

What do I do about the latest breach?

We can’t eliminate password reuse for our user-base. Password rotation policies feel like a natural solution to this however NIST warns of aggressive password rotation lowers the overall password strength due to user fatigue.

Check out if your organisation shows up in a breach. Hopefully the passwords are not reused but you should still encourage resets where possible especially for users which could be high value targets.

Use MFA!

Human brains will never be great at password based authentication, that is why we need to supplement it with another factor. This takes the urgency out of password breaches with respect to password reuse in your organisation because of the second line of defence. We use one time password based MFA on the AUSCERT website and hope to extend it to our other services in the future.