Common Sense Password Policies

When you overcomplicate security, you compromise user experience. When you compromise the user experience, your users have to fight back. When your users fight back, they compromise security. D’oh!

We recently purchased a new car, which came with a free 3-month trial for a WiFi hotspot provisioned from an included cellular data plan. I connect to the hotspot and am then taken to an AT&T Captive portal to create an account.

I’m already painfully aware that I’m likely about to subscribe to a lifetime of spam emails from AT&T, as well as consent to sending them a bunch of personal information and telemetry data about my driving habits, but as usual, I’m considering, once again, selling my privacy in the name of convenience.

After entering my personal info, it’s time to provide a password for my account. No problem! I fire up my password manager, and ask it to generate a new secure password that will be used only for this service. I paste the password into the form, and voila. Error! The password policy for the application is as follows:

• Length between 20 and 41 characters (pretty good)
• Password must include at least one uppercase letter and one number (ok)
• Password can only include the following 2 special characters “-” and “_” (WHY?)

This isn’t the worst password policy I’ve ever seen (until 3 years ago, my bank only allowed a max password length of 8 characters and only allowed letters and numbers), but I don’t understand why you would want to limit the entropy of my password. What is the motivation?

Similarly, I frequently run into websites and apps that go out of their way to prevent pasting or auto-filling of password fields, forcing users to type their passwords by hand. Doing so puts users in a position where they have to pick a less secure password in order to be able to memorize it and type it.

If you’re about to implement a password-based authentication system for your application, here are some easy guidelines to get you started:

• Encourage long passwords: password length is the single largest source of entropy. As such, you should have a minimum password length rule, and allow very large passwords if your underlying infrastructure can handle the associated encryption/decryption/storage workloads for your target scale.
• Don’t limit character sets. Complexity has less bearing on entropy than length, but it still helps. Also, remember that any rule you impose to users is potentially inconvenient, so don’t impose them unless there is a valid technical reason to do so.
• Don’t force users to pick from multiple character sets. The benefit in just adding one number and one “special character” is rather minimal, but you are making the system more complicated for your users than it has to be.
• Allow pasting into the password input. If you prevent pasting, users have no choice but to pick a simpler password that is easier to compromise.
• Do not block password managers. Password managers allow users to use a different, strong password for each website or application. Without them, users are left reusing variations of the same password, slightly altered to fit the arbitrary validation rules of every application they use. Blocking a system that allows your users to leverage strong password only puts your users at further risk of a breach.

With all the security breaches going around, and the sorry state of user education, it’s hard enough for users to keep up with very basic security practices. When you make them balance their security against user experience, they’re going to choose user experience every time.

In addition to adopting a reasonable and flexible password policy that doesn’t get in the way, I recommend adding support for Passkeys- a cryptographic standard that is gaining mainstream support across browsers and mobile devices. Passkeys (also called WebAuthn) rely on strong public key cryptography to respond to authentication challenges from the service you are trying to authenticate into. Access to your key on your own device is often secured through biometric data, adding another layer of protection.

I don’t really know what the future of passwords looks like. I’d love to do away with them altogether, and I think there is finally some industry momentum to move in that direction. I’m excited about the prospect, but I also know the transition is going to take a very long time, and in the meantime, I’d love to see common sense prevail.

Bonus XKCD: https://xkcd.com/936/