Here’s Why [Insert Thing Here] Is Not a Password Killer

These days, I get a lot of messages from people on security related things. Often it’s related to data breaches or sloppy behaviour on behalf of some online service playing fast and loose with HTTPS or passwords or some other easily observable security posture. But on a fairly regular basis, I get an email from someone which effectively boils down to this:

Hey, have you seen [insert thing here]? It’s totally going to kill passwords!

No, it’s not and to save myself from repeating the same message over and over again, I want to articulate precisely why passwords have a lot of life left in them yet. But firstly, let me provide a high-level overview of the sort of product I’m talking about and I’ll begin with recognising the problem it’s trying to solve:

People suck at passwords. I know, massive shock right? They suck at making genuinely strong ones, they suck at making unique ones and they suck at handling them in a secure fashion. This leads to everything from simple account takeover (someone else now controls their eBay or their Spotify or whatever else), to financial damages (goods or services bought or sold under their identity) to full on data breaches (many of these occur due to admins reusing credentials). There is no escaping the fact that passwords remain high-risk security propositions for the vast majority of people. Part of the solution to this is to give people the controls to do password-based authentication better, for example by using a password manager and enabling 2FA. But others believe that passwords themselves have to go completely to solve the problem which brings us to proposed alternatives.

I don’t want to single any one product out here because the piece I’m writing is bigger than that, so let’s talk about patterns instead. I’m referring to passwordless solutions that involves things like QR codes, pictorial representations, 3rd party mobile apps, dedicated hardware devices or “magic” links sent via email. I’m sure there are others but for the purpose of this post, any pattern that doesn’t involve entering a username and a password into a couple of input fields is in scope. To their credit, some of these solutions are genuinely very good – technically very good – but what proponents of them seem to regularly miss is that “technically” isn’t enough. Despite their respective merits, every one of these solutions has a massive shortcoming that severely limits their viability and it’s something they simply can’t compete with:

Despite it’s many flaws, the one thing that the humble password has going for it over technically superior alternatives is that everyone understands how to use it. Everyone.

This is where we need to recognise that decisions around things like auth schemes go well beyond technology merits alone. Arguably, the same could be said about any security control and I’ve made the point many times before that these things need to be looked at from a very balanced viewpoint. There are merits and there are deficiencies and unless you can recognise both (regardless of how much you agree with them), it’s going to be hard to arrive at the best outcome.

Let me put this in perspective: assume you’re tasked with building a new system which has a requirement for registration and subsequently, authentication. You go to the Marketing Manager and say “hey, there’s this great product called [insert thing here] that replaces passwords and all you have to do to sign in is…”. And you’ve already lost the argument because the foremost thing on the Marketing Manager’s mind is reducing friction. Their number one priority is to get people singing up to the service and using it because ultimately, that’s what generates revenue or increases brand awareness or customer loyalty or achieves whatever the objective was for creating the service in the first place. As soon as you ask people to start doing something they’re not familiar with, the risk of them simply not going through with it amplifies and defeats the whole point of having the service in the first place.

This isn’t a new discussion either, the one about considering usability alongside security. In fact, we have this discussion every time we build a system that defines minimum criteria for passwords; yes, a min of 20 chars would make for much stronger passwords but no, we very rarely do this because we actually want customers! If you look at the minimum password length requirements by large online services you can see the results of this discussion covering a fairly broad spread with Google and Microsoft demanding at least 8 characters, Amazon and Twitter wanting 6 and Netflix requiring… 4. But I’m hesitant to berate Netflix for what seems like an extremely low number because they’re also dealing with the usability challenge that is people logging on to TVs with remote controls. The point of all this is that usability is an absolutely essential attribute of the auth discussion.

What I often find when I have these discussions is a myopic focus on technical merits. I’ll give you an example from earlier last year where someone reached out and espoused the virtues of the solution they’d built. They were emphatic that passwords were no longer required due to the merits of [insert thing here] and were frustrated that the companies they were approaching weren’t entertaining the idea of using their product. I replied and explained pretty much what’s outlined above – the conversation is going to get shut down as soon as you start asking companies to impose friction on their users but try as I might, they simply couldn’t get the message. “What barrier? There is no barrier!” They went on to say that companies not willing to embrace products like this and educate their users about alternative auth schemes are the real problem and that they should adjust their behaviour accordingly. I countered with what remains a point that’s very hard to argue against:

If your product is so awesome, have you stopped to consider why no one is using it?

Now in fairness, it may not be precisely “no one” but in this case and so many of the other [insert things here], I’d never seen them in use before and I do tend to get around the internet a bit. Maybe they’re used in very niche corners of the web, the point is that none of these products are exactly taking the industry by storm and there’s a very simple reason for that: there’s a fundamental usability problem. This particular discussion ended when they replied with this:

I think it is only negativity that doesn’t allow positiveness to excel

Ugh. I’m negative about stuff that’s no good, yes. I dropped out of the discussion at that point.

Almost a year ago, I travelled to Washington DC and sat in front of a room full of congressmen and congresswomen and explained why knowledge-based authentication (KBA) was such a problem in the age of the data breach. I was asked to testify because of my experience in dealing with data breaches, many of which exposed personal data attributes such as people’s date of birth. You know, the thing companies ask you for in order to verify that you are who you say you are! We all recognise the flaws in using static KBA (knowledge of something that can’t be changed), but just in case the penny hasn’t yet dropped, do a find for “dates of birth” on the list of pwned websites in Have I Been Pwned. So why do we still use such a clearly fallible means of identity verification? For precisely the same reason we still use the humble password and that’s simply because every single person knows how to use it.

This is why passwords aren’t going anywhere in the foreseeable future and why [insert thing here] isn’t going to kill them. No amount of focusing on how bad passwords are or how many accounts have been breached or what it costs when people can’t access their accounts is going to change that. Nor will the technical prowess of [insert thing here] change the discussion because it simply can’t compete with passwords on that one metric organisations are so focused on: usability. Sure, there’ll be edge cases and certainly there remain scenarios where higher-friction can be justified due to either the nature of the asset being protected or the demographic of the audience, but you’re not about to see your everyday e-commerce, social media or even banking sites changing en mass.

Now, one more thing: if I don’t mention biometrics and WebAuthn they’ll continually show up in the comments anyway. On the biometrics front, I’m a big supporter of things like Face ID and Windows Hello (I love my Logitech BRIO for that). But they don’t replace passwords, rather provide you with an alternate means of authenticating. I still have my Apple account password and my Microsoft password, I just don’t use them as frequently. WebAuthn has the potential to be awesome, not least of which because it’s a W3C initiative and not a vendor pushing their cyber thing. But it’s also extremely early days and even then, as with [insert things here], it will lead to a change in process that brings with it friction. The difference though – the great hope – is that it might redefine authentication to online services in an open, standardised way and ultimately achieve broad adoption. But that’s many years out yet.

So what are we left with? What’s actually being recommended and, indeed, adopted? Well to start with, there’s lots of great guidance from the likes of the National Cyber Security Centre (NCSC) in the UK and the National Institute of Standards and Technology (NIST) in the US. I summarised many of the highlights in my post last year about Passwords Evolved: Authentication Guidance for the Modern Era. As a result of that piece (and following one of the NIST recommendations), I subsequently launched the free Pwned Passwords service which is being used by a heap of online entities including EVE Online and GitHub. This (along with many of the other NCSC or NIST recommendations) improves the password situation rather than solves it and it does it without fundamentally changing the way people authenticate. Every single solution I’ve seen that claims to “solve the password problem” just adds another challenge in its place thus introducing a new set of problems.

This is why [insert thing here] is not a password killer and why, for the foreseeable future, we’re just going to have to continue getting better at the one authentication scheme that everyone knows how to use: passwords.

Passwords Security