I think passwords will give way to another type of authentication—one that is less annoying to users, less vulnerable to attack, and that’s more sustainable over time.

Out of band challenges.

The concept here is that you are already authenticated in another service, and that service is used to authenticate you to the current resource you’re trying to get to.

It’s being done already to some degree, but not nearly enough.

The problem with passwords

This is covered territory, so I won’t go into too much detail, but the basic problems with passwords are these:

1. They’re hard for for humans to remember but easy for computers to crack
2. Managing passwords (especially good ones) for dozens or hundreds of websites is a burden that humans are not set up for, and tools like password managers are a little more than a band-aid.

A better way ?

The concept for out-of-band authentication is basically this:

1. You go to sign into a website and you provide an identifier, e.g. a username or your email address
2. The website sends a challenge to the authentication service associated with that identity. If it’s a username it could be tied to an authentication option within the account itself, or it might go to the user’s email if the identity is an email
3. You receive a challenge at the authentication channel that was used, which you usually just click on to approve. The challenge will often have some information about where it came from, e.g., device, location, etc. so you can be sure it was you and not an attacker

Some options for implementation

One way to do this is to simply send an authentication link or button to an email address, and when the user clicks that they get access to the other account.

But a better (and slicker) way to do this is with a dedicated service and associated application(s). Twitter does this nicely, which is shown in the header image. They send you an application-based notification of an authentication request, which you can just hit a button to accept.

What would be supremely slick would be a service that does this for any type of account, and companies like Duo and Authy are flirting with the concept.

The idea would be the following:

1. You sign up with the authentication service, using very strong security
2. You install its associated application(s) on your mobile and desktop platforms
3. You link your various accounts to this service as your authentication method
4. When it comes time to log in, you just enter your username and it prompts you on your mobile (or desktop) to accept

What’s cool about this is that 1) you’re not having to create and remember many passwords anymore (which you’re probably doing poorly anyway), and 2) you’re proving security more robustly by showing you have access to the device running the authentication app. Keep in mind that device is probably secured further with your fingerprint at this point.

So the old way has you using probably crappy passwords—which are an endless annoyance and allow anyone to make attempts against your account—versus the new way which you enter no password and the attacker would need your device and your fingerprint to gain access.

An added benefit is that you get automatic multi-factor authentication, although not in the classic sense.

• You’re signed into the authentication service (which required a password)
• You must be authenticated to your device to authenticate the request (both something you have (the device), and something you are (fingerprint)

So that’s something you have (1) and something you are (2) instead of something you know (password). If you add the fact that you have a password to enable the authentication app then you might get to like 2.5 (you don’t get a third factor because you’re not doing it each time).

What about social login?

Alert readers will notice that many websites already have this in the form of social logins. And this is pretty good, but there are some issues there.

First, it could be that a separate authentication service is a better way to do this than stacking it on top of something like Facebook or Google, just from a trust and segregation of duties type of thing. Or maybe it’ll be just another layer on top of those services and overall security will improve enough to make it trustworthy.

The second issue is that the user experience still isn’t great with the social login. It’s usually a couple of prompts, clicks, and redirects that don’t leave a great feeling for the user. It would be far better to receive an in-app prompt that is elegant to approve.

Finally, the current social login system doesn’t require a second factor.

Adding factors

The authentication application could add factors according to business rules as well. So if it’s a certain type of account raise the security, or if the authentication attempt is coming from a strange place, or from a new device, etc.

Downsides and complications

There are some drawbacks.

• you’d have to link all your accounts to this new service (or services), and you’re basically creating a single point of attack and failure at that new location
• not all websites would support this type of authentication, so you’d probably still have a mix of authentication types: some passwords, some using auth services
• offline access to services will have to be solved. Even though you’re likely to be online if you’re trying to log into an internet resource, there could be situations when you need to authenticate without being online

Summary

It’s time for passwords to go, and I hope this out-of-band option starts taking over sooner rather than later.

Notes

1. Twitter’s use of this technology is for a second factor, not the primary. The real magic comes when this is used as main authentication, and not just a second factor.
2. Standardization and adoption are the primary obstacles here.
3. I just made up that business with 2.5 factors of authentication. Would be interested to hear if anyone has thought more about that.