Your Password Complexity Requirements Suck
We’ve all seen it. Probably multiple times a week these days.
Almost any time you have to create an account somewhere, or reset a password, you are presented with something like this:
PASSWORD REQUIREMENTS:
- at least 20 characters long
- at least 1 lowercase letter
- at least 1 uppercase letter
- at least 1 numeral
- at least 1 symbol (approved symbols only: ©∆¬∑©∫åµπ¢™∂ß≈)
- at least 1 irrational number
Sure, this would make for a password very hard to guess, and very hard for a computer to discover through brute force. But it would also make for a password nearly impossible for a human being to remember.
Now, it’s true, people should use a password vault so they don’t have to remember their passwords. I used to be very fond of saying “If you can remember your password, it isn’t strong enough.” There’s only one problem with this: most regular people, and your users and customers are probably regular people, don’t use password vaults. They’ll either end up writing the crazy password you make them concoct down on a piece of paper, or forgetting it altogether.
Or they just won’t sign up / use your product or service / ever come back.
None of these are good things. Not one.
So what’s the answer? While I like xkcd’s suggestion in the comic above, most people still won’t do something like that. Worse, most developers won’t let them. Password complexity schemes usually don’t allow for passwords to be long but “simple,” containing only lowercase letters and maybe spaces.
The fact is, password length is more important than password complexity. An 8-character selection of upper and lower case letters, numbers, and symbols, is orders of magnitude easier to brute force than a 20-character selection of simple, unrelated lowercase words and spaces. But requiring “simple, unrelated lowercase words and spaces” is difficult from a development standpoint, while validating against the bullet list above is trivial.
So what’s good for the password-overloaded user, simple for the developer to implement, resistant to brute-force attempts, and at least as secure as a user’s own email inbox?
The answer’s at the end there.
Email.
I’ve adopted the concept of the Passwordless Auth for all of my projects now. You can start by using an engine like NoPassword, or a 3rd-party service like Auth0, but really, implementation from scratch is incredibly simple.
Really all you need to add beyond what you’d have in a simple User model are login_token and login_token_valid_until parameters. Give the login_token_valid_until a very near-future datetime, like 15 minutes from the login attempt, and randomly generate a string for the token itself. Send a link to the user, when they click it, find them by the token, and log them in.
It’s incredibly simple. The kind of thing I’m using was written about with great code examples by Premysl Donat back in May 2016 (Password-less hassle-free authentication in Rails) so I won’t repeat his work here.
The fact is, while users can’t be counted on to use password managers/vaults, and while they can’t be counted on to set up 2FA even if you give them the option, or to create secure, long passwords they never reuse, they can be counted on to have email. So use that to your advantage.
