Passwords are a mostly necessary part of almost all web applications. A lot of research has gone into how applications should deal with passwords, from the UX of password creation, to the storage of passwords. Large password breaches have taught the security industry a lot about the types of passwords people create and how (not) to store passwords. Troy Hunt has published a rather exhaustive article on this topic. This article dives in on one aspect of secure passwords: the UX and UI of password entry—specifically, how to implement a decent password strength checker.
Why a Strength Indicator
If you have not read Troy’s article, you are strongly encouraged to do so now before continuing. Or you can take it on faith that, at most, your web application should only be enforcing a minimum password length and no other complexity metrics. If this makes you uncomfortable, welcome to this brave new password world. The short version is, users are not good at passwords. They don’t know what they don’t know about passwords, but we do know. If your application enforces a bunch of zany requirements, such as forcing them to use arcane magic symbols and perform a seance before your application will accept their password, the chances are quite high that the users will cast the most simple spell possible to defeat your password checker.
User: types in his favorite password ‘goats’
Application: NO. Your password must be blah blah blah blah
Application: Excellent. Thank you for playing
Did this complexity enforcement increase the security of your web application? Counter-intuitively it probably didn’t. It probably decreased your security. It turns out password cracking technology combined with the glut of powerful and inexpensive GPUs can destroy passwords like that in no time. The goal of the password strength indicator is to influence user behavior to help them make a better choice about their password. And, if they really, really just want to use the same bad password, we can’t stop them and we don’t gain any extra security enforcing complexity requirements.
Our password strength indicator will use two primary tools:
Check out our example implementation.
In the image above the user entered the password
12345678. Go ahead and try some other common dictionary words. Passwords are kept secure because only a (hashed) portion of it is sent to HIBP. An attacker will not be able to use anything sent to HIBP to recover the user’s password. Have I Been Pwned API
Disclaimer: No tool is perfect. It is easy to come up with an easy to crack password that does not exist in any breach and the password strength indicator will say is “strong”. Also, the UI has some small issues and is meant to be illustrative of how to implement a password strength indicator. The key elements are running the password through zxcvbn and the HIBP API and then presenting that information to the user and giving them guidance on how to improve their password strength. How to implement this will vary for each UI framework.
Also available as a GitHub gist.