Prelude: First off, if you haven’t already read The Quest to Replace the Password stop reading this and give that a read first. To paraphrase my computer security professor, If you haven’t read this paper before you design an authentication system you’re probably just reinventing something already created or missing a piece of the puzzle. So go ahead take a read of that paper first before you continue on. In fact, I just re-read this paper before I started working on it because it does an excellent job of framing the problem.
Over the past few years, I’ve spent a fair amount of time thinking about what the next generation of authentication and authorization systems will look like from a variety of different perspectives. I started out looking at the problem from a user’s perspective originally just looking to get rid of passwords. Then I looked at it as an attacker working as an intern penetration tester which gave me a unique eye into understanding the attacker mindset. Unfortunately, I didn’t find myself enjoying the red team side of security too much (combined with having a 2-year non-compete as an intern - that was a joke in hindsight) so by happenstance, I found myself into the standards community where the next generation of authentication (AuthN) and authorization (AuthZ) systems have been being built. Combine this with the view of a software engineer attempting to build the standards that are being written by some world-class experts with centuries of combined experience. Throughout this experience, I’ve gotten to view the state of the art while also getting to keep the naiveness that comes with being a fairly new engineer relative to some of the experts I get to work with. During this time I’ve become a bit more opinionated on what makes a good authentication system and this time around I’m going to jot down my current thoughts on what makes something useful.
However, one aspect that I think that paper lacks is that it frames the problem of authentication on the web as something where the next goal is to move to something different other than passwords, but we just haven’t found that better thing yet. While I think this is probably true for some aspects of low-security systems I think that fundamentally passwords or more generally, “Things I know” are here to stay. The problem is that we haven’t done a good enough job of understanding the requirements that the user needs to intuitively use the system as well as making sure that the system sufficiently gets out of the way of the user. As the paper does point out though, this is likely due to our specialization bias which doesn’t allow us to take into considerations the holistic view points necessary to approach the problem. What I’m proposing I think is a way in which we can jump this hurdle through the usage of hard data. Read on and let me know if you think this can solve this issue or if I’m just full of my own implicit biases.
So what’re the important insights that I’ve been thinking about lately? First off, the user experience of authenticating on the web has to be joyful first and foremost. If the user doesn’t have a better experience than what they do with passwords, which is a very low bar to beat when considering all the passwords they have to remember, then it’s simply unacceptable and won’t achieve the uptake that’s needed to overtake passwords.
Secondly, I think it’s important that we recognize that the security of any authentication system is probabilistic, not deterministic. By reframing the problem to understand that with each additional security check we do under the classifications of “what I know”, “what I am”, and “what I have” it allows us to better understand the problem we’re actually trying to solve with security. To put this idea in perspective think about the problem this way. What’s the probability that a security system will be broken for any particular user during a particular period? For example, a user who chooses to reuse their password that’s set to “#1password” for every website is a lot less likely (my intuition - happy to be proven wrong) than a user who can memorize a password like “p2D16U$nClNjqLseKTtnjw” for every website. However, there’s a significant tradeoff on the user’s experience which is why the case where a user reuses an easy to remember is a lot more likely to occur when studying users than the latter case even though we know it’s less secure.
So what gives? This all sounds obvious to a semi-well thought-out engineer, right? The difference is we simply don’t know the probability of a security system failing in an ideal scenario over a pre-determined period. To put this in perspective - can anyone point me to an academic research paper or even some user research that tells me the probability that a user’s password will be discovered by an attacker in the next year? What about the probability that the user shares their password with a trusted person because the system wasn’t deployed with a delegation system? Or how about how the probability will drop as the user reuses their password across many websites? Simply put I think we’ve been asking the wrong question here and until we can have hard data on this we can’t make rigorous choices on the acceptable UX/security tradeoffs that are so hard to decide today.
This isn’t relevant for just passwords either, this extends to many different forms of authentication that fall under the other two authentication classes as well. For example, what’s the probability that a user’s account will be breached when relying on the Open ID Connect protocol rather than a password? Furthermore, what’s the likelihood that the user prefers the Open ID Connect system rather than a password for each website, and is that likelihood worth the increase or decrease in probabilistic security under one or many attack vectors?
The best part of this framing is that it changes how we look at security on the web from the user’s perspective, but that’s not the only part that has to be considered as is rightly pointed in the paper. There’s a very important third factor that has to be considered as well which is deployability, which I like to reframe as “developer experience” or DevX.
By evaluating a constraint of a system in this way we reframe the problem into a measurable outcome that becomes far more tractable and measurable between the variety of constraints that need to be considered including the developer deploying or maintaining the system, the user who’s using it, and the resistance to common threats (Don’t worry about unrealistic threat models for now - mature them over time) which the user expects the designers of the system to protect them from.
Once we’ve got that data let’s sit down and re-evaluate what are the most important principles of designing the system. I’ll make a few predictions to wrap this up as well.
First prediction: I think once we have this data we’ll see a few different things which will be obvious in hindsight. A system that doesn’t prioritize UX over DevX over probabilistic security resilience will be dead in the water since it goes against the “user should enjoy the authentication experience principle”. Additionally, DevX has to come before security because without a good devX it’s less likely to be implemented at all let alone properly.
Second prediction: I’d venture to guess that we’ll learn a few things about the way we frame security on the web with the clear winner being that we should be designing for MFA systems by default, but “what I have” categories need to be the basis of the majority of experiences for the user with the “what I know” categories being an escalated approach with “what I am” categories only being needed in the highest assurance use cases or at the time of more red flags having been raised (e.g. new IP address, new device, etc) and being enforced on-device rather than handled by a remote server.
Final prediction: Recovery is going to be the hardest part of the system to figure out with multi-device flows being only slightly easier to solve. I wouldn’t be surprised if the solution to recovery was actually to not recover and instead make it super easy to “burn and recreate” (as John Jordan has advocated in the decentralized identity community) an account on the web because that’s how hard recovery actually is to get right.
So that’s what I’ve got for now. I’m sure I’m missing something here and I’m sure I’m wrong in a few other cases. Share your comments on this down below or feel free to send me an email and tell me I’m wrong. I do appreciate the thoughtfulness that others put into pointing these things out so let me know what you think and let’s discuss it further. Thanks for reading!