Doing authentication right

Any substantial website is going to need to customize itself for individual users. Thus, it is going to have to authenticate those users — that is, let them log in. As a software developer, it is your job to make the whole process as smooth and secure as possible.

Of course, doing this creates all sorts of issues and problems. Sure, you have to protect your users’ data, somehow get the user to create good passwords, assume that they’ll forget their passwords, and assume that they’ll probably not be secure in general.

Like encryption, authentication is one of those things that you are tempted to “roll your own” but absolutely should not. The industry has progressed enough that you should definitely “buy and not build” your authentication solution. Plenty of vendors offer easy-to-implement solutions and stay diligently on top of the latest security issues. 

Authentication also becomes a tradeoff between security and a good user experience. Most third-party solutions offer many options and capabilities, and it is incumbent upon you, the developer, to make good choices that keep your customers and internal security folks happy. 

So, here is some advice for properly balancing all of that as you create a solution for your website.

What to do when implementing authentication

Do use passkeys

Do use OAuth

Do use magic links

Do use multi-factor authentication

Do let users view their passwords

Do use passkeys

Passkeys are a relatively new technology and there is a lot of FUD floating around out there about them. The bottom line is that they are safe, secure, and easy for your users. They should be your primary way of authenticating. Several vendors make implementing passkeys not much harder than inserting a web component in your application. 

By leveraging public/private key encryption and biometric scanners on your devices, passkeys are a great solution that users love. Does anyone prefer typing in a password to scanning your face or your thumb on a phone? No, no one does. Admit it — you love accessing your banking app via Face ID rather than typing that secure, arcane, hard-to-type password into that little keyboard.

Do use OAuth

Passkeys can be your sole means of authenticating users, but some users might prefer more traditional login methods. Once you have passkeys in place, you should implement OAuth authentication. OAuth is most commonly done via the “Login with Google” or “Sign up with Apple” buttons. Users like OAuth because it enables them to log in to your site without having to type a password or even create an account. You can offer login services from any number of popular sites including Google, Apple, Facebook, Microsoft, and GitHub. It’s a rare user indeed who doesn’t have an account on one of these systems. 

Do use magic links

Another way to provide login is the use of “magic links.” A magic link is a link sent to the user, usually via email or text, allowing them to log in to your site merely by clicking on it. It is convenient in that the link can only be seen by the user and lasts only a limited time. The downside is that it does require the user to leave your site to check their email, but at least clicking on the link brings them right back.You might have noticed that these recommended solutions don’t require your user to create an account on your site, or require them to remember a password, or require you to save any information about the user. You can provide secure and user-friendly authentication without knowing anything at all about your users.

Do use multi-factor authentication

If, however, you do feel the need to allow users to create accounts in your system, you should absolutely require them to use multi-factor authentication (MFA). In this day and age, the ability for a user to log in with nothing more than a password is simply inviting trouble.

When doing MFA, you should prefer doing things in this order:

Have the user use an application that generates the one-time password (OTP). This is the most secure way because it doesn’t involve transmitting the OTP via any interceptable means. In addition, password managers can serve as providers of OTPs, automating the whole process — by far the easiest solution for your end users.

Email the OTP. Email is harder to intercept than a text message, so more secure.

Finally, if for unforeseen reasons you can’t do either of the above, text the user a OTP. But frankly, I’d avoid this if possible. Text messages are insecure, and a determined hacker could easily spoof this.

Do let users view their password

You should always have the option for users to reveal their passwords. Sometimes a user just needs to see what she typed, and it’s irritating not to be able to. Of course you should default to masking the password, but let the user reveal it if they so choose.

Okay, so I’ve discussed what you should do when implementing authentication. Now, let’s discuss some things that you absolutely should not do concerning authentication.

What not to do when implementing authentication

Never store user passwords

Don’t require complex passwords

Don’t use one-time passwords longer than six digits

Don’t use special questions

Don’t limit sign-in attempts

Don’t force users to change their passwords

Never store user passwords

This should go without saying. You should never, ever, ever under any circumstances store a user’s password in your database. Never. Instead, store a “salted and hashed” version of the password and compare that value each time. If a user forgets their password, let them create a new one. Nothing screams “My website is begging to be hacked” like emailing a user his password when he forgets it.

Don’t require complex passwords

This one is counterintuitive for many, but it is far more secure and user-friendly. If you are going to let your users create their own account with a password on your site, do not set onerous password requirements for letters, numbers, case, special characters, etc. Instead, merely set a minimum length for the password of at least 12 characters. 

Forcing users to use hard-to-remember passwords means they will be more likely to write them down or use a simple password that meets the requirements. Again, it may seem counterintuitive, but XKCD has it right. In addition, the longer the password, the harder it is to crack. 

Let your users create long, easy-to-remember passwords rather than force them to use shorter, difficult-to-remember passwords.

Don’t use one-time passwords longer than six digits

Six digits is the outer limit for OTP links, and you should consider shorter ones. Under no circumstances should you require OTPs longer than six digits because they are vastly harder for users to keep in short-term memory. 

Don’t use special questions

Do not, under any circumstances, use this so-called security feature. I cannot tell you how many times I’ve typed in my favorite movie or the name of my first pet, only to be told “Nope, what the hell do you know? Casablanca is not your favorite movie, and your first pet was not named Lucky,” when I know full well that those answers are exactly right. Worse, this information is very easily “phished” on social media or via other means. Just don’t use this “feature.”

Don’t limit sign-in attempts

Do not lock a user’s account after some pathetically small number of sign-in attempts. This only irritates your users. Maybe I have fat fingers today. Maybe my password is easy to remember but hard to type. And while we’re at it, never, ever “freeze” a user’s account. What a hassle for them — and for you — when it becomes a customer service ticket.  

Don’t force users to change their passwords

Forcing users to change their passwords after some arbitrary period does exactly zero to enhance security. It merely causes users to add an increasing number at the end of their normal password.  

Authentication is critical and far too important to get wrong. Given the solutions available to you, there’s no excuse for clunky, unfriendly logins or insecure systems. So, don’t over-complicate it. Avoid requiring passwords altogether by using passkeys and OAuth, and ditch the outdated practices that frustrate users and compromise security. Today, a secure, easy-to-implement, and user-friendly authentication solution is not hard to find.