Authentication design for websites is tricky business, and we’re finding more and more websites are falling behind the times. Let’s talk user login design and how to get decent security without stamping all over your user experience. It’ll be fun, I promise!

TL;DR

We still need users to choose a password, but the strength of these matter less if you have other protections in place. If you don’t, then you should teach people to choose passphrases and enforce that behaviour.

MFA is now almost always a requirement. A weak form (SMS or email based, trusted IP range based, device enrolment, etc) can be enough, depending on what you’re protecting and UX requirements.

Login anomaly detection should be in place and is required if your users can’t handle MFA. Simple stuff like rejecting logins from a country or device the user doesn’t normally login from is super helpful. You don’t need no fancy AI for this one.

Authentication Security Controls

There are three common security controls for authentication. Let’s go over each of these for background:

Username (or email address) and Password

This is the go-to for 99.9% of people when they think website login. Requiring some kind of username and password is a good start, with the giant caveat that relying solely on username/password pairs very (very) rarely good enough. It’s not 2010 any more folks!

An example: if you force Mavis and Theodore in HR to have crazy symbols in their password and change it every three months, they’re going to struggle and choose either terrible passwords (Winter20!) or start using post it notes attached to their monitor. Is this their fault? Definitely not, it’s our fault for giving them bad tools to protect their accounts and generally being mean about their ailing memory while doing it. Poor Theodore and Mavis.

(Pulse Security offers incident response and digital forensics services as well as penetration testing services. Just saying.)

Multi-factor Authentication

MFA is the “other thing” checked at login - alongside the username/password pair. Often, it’s a code generated in a mobile app, but we can consider weaker forms like a code in an SMS message or email to still be OK. Although these are less good for many reasons including SIM hijacking and password reuse between a web login and an email account. MFA of some kind is now a requirement for most internet facing websites warranting security consideration.

Login Anomaly Detection and Response

This is a more recent thing we’re recommending. Anomaly detection is being widely implemented by the big guys (Google, Facebook, etc). This kind of anomaly detection is generally some logic that runs when the user logs in. The focus is on sanity checks to decide if this login might be suspicious or not.

Is this a new device they’re logging in from? Is this login from a new country?

If these basic checks show anything new or unusual then flag the login as suspicious. What you do from there is up to you, some websites will block the login and require the user enter a code from an SMS message, some will allow the login but email or SMS the user an alert with guidance on how to secure their account if they need to. I tend to side with blocking these logins until another factor of authentication is supplied, but that’s just me.

Editor’s note: Like BitBucket emailing users when someone logs into a BitBucket account proxying via Sydney and burning my freshly stolen username and password pair!

The Balancing Act

Here’s where things get complicated: we need to implement authentication controls but balance user experience with security. Where the balance point is will be wildly different depending on the data you’re protecting, how users interact with your website, organisational risk appetite (are you a “invest in bitcoin” kind of company, or a “low interest term deposit” kind of company). Which is a fancy way of saying there isn’t really an easy, one size fits all solution here.

A modern, secure authentication design will generally implement a form of all three controls we’ve discussed. When all three are implemented, none of them need to be 100% totally secure or fool-proof when weaknesses in one are made up elsewhere. In my opinion, this is the way to go.

A good password policy these days should (more or less) force users to choose a simple passphrase (e.g. Living room lamp is red). But the strength of the password itself matters less if you’re doing good MFA and anomaly detection.

Your users may push back on passphrases, but you can sneak in SMS based MFA with little disruption. Or it may be the opposite, this is for you to work out with your user base. What’s going to work for them and still be secure enough.

One thing I do want to stress is that 98% of the time old style passwords as the only protection is a terrible, terrible idea that could end in disaster.

The Threat Model

I’m a fan of a threat led approach to cyber security when resources are constrained which is a whole other article. For now, let’s just say you should design your authentication around protecting against actual and reasonable threats. Or to put it another way: What types of attacks are possible, which ones do we care about (there’s probably few we can ignore as far too unlikely), and how does our authentication design mitigate those? What’s the point in kicking goals if there’s no goal posts, ya know?

Quick and dirty threat modelling is surprisingly useful. Understand what you’re protecting and the level of acceptable risk, then research what attacks against user authentication are likely. List out the relevant ones along with how the design will mitigate them.

To give an idea, here’s an incomplete list:

• Password brute force guessing – account lockouts, passphrases required, MFA required, anomaly detection
• Password spraying (exploiting password reuse) - MFA required, anomaly detection
• SIM card porting attacks – anomaly detection
• Lost or stolen MFA device - anomaly detection
• Password auto-complete on a shared computer – MFA required, auto-complete disabled

You may also want to assign a risk rating (high, med, low) to each threat without mitigation, and a risk rating after mitigation. Anomaly detection is probably weak when the threat is a stolen MFA device when that device is also the phone the user is logging in from. Knowing that kind of thing is definitely useful even if you don’t do anything about it right now.

Even if you do a pretty bad job of the above, you’re doing better than a lot of recent website projects I’ve had some involvement in. This doesn’t need to take all day, quick-and-dirty will put you in a much better position to make good decisions around how your authentication should work.

Conclusion

So, there you have it, hopefully you can apply some of these ideas to your website user login design. If the only take away you get from this is username/password pairs alone are generally bad, then I’m calling that a win.