At the February Microsoft 365 Security & Compliance user group, Eric Woodruff (@msft_hiker), author of Eric On Identity, gave an excellent presentation on the topic of passwordless authentication. This struck a chord with my recent experience in the field, particularly in terms of the new Authentication Strengths feature in Azure AD. This post is based on my Q&A with Eric and feedback I submitted to the Azure AD team (thanks to the brilliant @merill for that) and sets it in a wider picture, namely that we’re making better technology than we’re using; there seems to be a gap in terms of getting the security we know we need into widespread practice.

A glacial pace isn’t what it used to be

It strikes me that the landscape of authentication – verifying an identity with a computer – resembles Antarctica in the climate crisis. For many years unchanged, following the familiar contours of knowledge-based methods (passwords), then a gradual erosion of trust leading to basic multifactor authentication (password plus something else), then more rapidly to passwordless and phish-resistant MFA. With the trend toward implicit authentication (monitoring biometrics and behaviour in the background) and zero trust (constantly validating identity at every point of interaction) the topography will soon barely resemble that of the earlier epoch.

Where did the humans go?

These advances are fascinating and necessary in the face of overwhelming malicious efforts to undermine them – but there seems to be a greater focus on technology than on the humans who use it when in reality these should be given the reverse priority. Authentication is 80% humans knowing what to do, 10% doing it correctly and 10% computers checking it. It’s a user-facing process and generally the first point of user interaction with any system. Adding security controls at this point can cause an increased cognitive load and impose a burden in time and stress. Enforced password resets are a perfect example of this (and something I’m glad we are distancing ourselves from nowadays); somehow they always seemed to kick in at moments of great urgency.

One would think that with rapid change to a critical user-dependent element of our infrastructure, we’d start by talking about adoption and planning for efficient onboarding and upgrading from legacy methods and yet – at least in my experience – this isn’t the case. That surprises me because there are obvious practical benefits; it doesn’t have to be a zero-sum game in which safety only wins at the cost of our convenience. I converted my organisation to MFA by using the death of password expiry as an incentive; my colleagues were only too happy to jump on board to save themselves that future stress. Newer methods promise an end to the routine entering of passwords entirely which by Yubico’s estimates may save each of us as much as 12 minutes a week!

Sadly this reflection from the authors of a recent paper seems a fairly good summary of where we’re at with this process.

“Users will need to get educated about this novel authentication paradigm as no metaphors exist to help users form a mental model of respective mechanisms.”
Beyond passwords: challenges and opportunities of future authentication

That’s comedy gold right there. Imagine the security consultant at the company briefing on their new security system: “It’s like, well, it’s not like anything really as no metaphors exist to help you understand it so good luck and thanks for the canapés!”

Joking aside, how can users educate themselves in a vacuum about a subject IT specialists have barely wrapped our heads around yet are already demanding that they adopt?

I’d be more inclined to invoke this logic:

“If your people are doing stupid things, it’s not because you have stupid people, it’s because you have a stupid system.” —Ira Winkler

As I see it, not only are we at risk of letting our people down by failing to help them understand the changing nature of authentication but by failing to provide systems which can assist them to easily adopt safer methods, we are setting ourselves up for continued use of weaker ones into the future.

Example: Authentication Strengths

Caveat: I’m a huge fan of Azure AD and the feature I’m about to talk about is in preview so I’m in no way criticising it or the folk who are working hard to make it a success; I have already shared this perspective as feedback.

Microsoft recently released an Azure AD feature called Authentication Strengths which allows authentication requests to be filtered for specific MFA methods rather than treating all MFA as equal. This is a great step forward and can help ensure that access to sensitive systems or actions requires truly strong authentication.

Unfortunately in the current implementation there is no mechanism for remediation where an attempt is made by someone who doesn’t have a sufficiently secure MFA method enabled on their account. They are instead sent into a continual authentication loop, the proposed solution to which is “make sure the user is registered for the method before the policy is enforced” – with no mention of how we actually accomplish this at scale in a diverse organisation with many different MFA methods in regular use.

An alternative process would present a fantastic opportunity to close the authentication strength gap, for example:

  • System captures authentication requests with insufficient MFA methods and redirects them into an MFA onboarding or upgrade process.
  • This process begins with a simple explanation of where the user is and where they need to be in order for their access to be approved while also making other restrictions clear (e.g. Conditional Access restricting security changes to known locations). This is my own terrible illustration of what that might look like:

MFA idea

  • The user clicks through to activate the method they need to have enabled, e.g. being directed to a QR code for the Authenticator app.
  • User completes MFA method activation and is automatically redirected to the resource they originally accessed, prompted for their new credentials and allowed access.

A process such as this would help support awareness campaigns to inform people of these changes, reduce the burden of an all-or-nothing MFA rollout and encourage admins to aim high by enabling more secure policies in the knowledge that those who don’t comply won’t be locked out, or if they are that they will at least know why and what to do about it.

Example: Twitter

In an enterprise environment, there’s a high degree of control and to a reasonable extent we can inform and direct user behaviour but here’s a curve ball for the conversation: what about personal accounts? On this side of things it’s more like being in charge of public health during a pandemic; encouraging safe practices is important but if there are too many barriers to adoption, there’s a greater likelihood people won’t bother with them at all. Better to have most people marginally protected than a small number invulnerable; anything is better than nothing. This brings us to Twitter.

Quite a lot seems to have been going wrong with ’the bird site’ lately but one in particular pinged on the radar of the security community; the demand to pay up or lose access to SMS-based MFA, presumably imposed as a cost-saving measure. Given that SMS is the least secure MFA method, the result is a confusing state of having to pay for insecurity, as Mike Niehaus noted:

This is an interesting case for two reasons:

  1. It has highlighted that we are doing really badly in the MFA stakes. Twitter is a hugely popular social network with a major global presence from businesses, journalists and professionals and yet their own data reveals that only 2.6% of their subscribers have MFA activated and of those 74% are using SMS. This is a paltry number, mostly reliant on the weakest MFA method. SMS is still winning on convenience because of the low barrier to entry (everyone has a phone), low complexity (everyone knows their number) and lack of backup concern since it’s effectively taken care of by the carrier.
  2. It has shown the lack of agreement on a way forward. Some are elated at the revocation of a less secure method while others point out that the likely reason for someone to have used it is that they lack the understanding of its importance, the hardware to use it or the technical skill to set it up. In short, will removing the less secure method result in a flood of uptake directed to the more secure ones or will what scant protection SMS offers be stripped away and not replaced? Time will tell, though I’d be surprised if it wasn’t the latter.

Some would say that no MFA is fine for personal accounts that hold no private information; if my Twitter account is just for my cat pictures then what’s the problem? That theory falls down in practice though as Spycloud’s report from last year showed that 64% of passwords exposed in breaches had been reused elsewhere. Clearly we should all be using strong MFA ubiquitously, but how do we get there from here?

Words matter

Standardising around terminology would be a start. For example, it seems there isn’t a consensus on something as basic as whether passwordless refers to all post-password authentication or whether it only refers to an app or device that can replace the logon action without using keystrokes but that may not be as strong as other methods.

Aside of making sure we’re all talking about the same thing, words inform expectations of use. We undoubtedly need more than one category; Microsoft has opted for MFA, passwordless and phish-resistant, which is clear as mud to a non-technical person and even confuses me (isn’t phish-resistant FIDO2 also passwordless?).

I’d argue we need a bold reset for the sake of clarity: what used to be called simply ‘MFA’ becomes weak MFA (SMS / voice), then good MFA (passwordless / phone app) and strong MFA (phish-resistant / FIDO2). A simple ranking such as this would require no explanation as anyone could understand a message such as ‘sorry, you only have a weak method and you need a strong one’.

Further, individual methods could be deprecated and replaced within these categories over time in much the same way as TLS cipher suites in a browser. When a particular cipher is shown to be weak, the industry decides to categorise it as such and browser behaviour adjusts accordingly. Push notifications used to be considered good, until we saw the damage that MFA fatigue attacks can cause and we now consider them to be weak. Equally with new methods that must be added; when the dreaded florp attack of 2045 inaugurates the era of florp-resistant MFA we don’t have to redefine the categories and add to the confusion again, rather it just becomes the new standard for strong.

I very much hope that the industry can rally around the need for change in a way that will promote widespread awareness of the new world of authentication and uniformity of behaviour and terminology across systems, services and apps. That will assist those of us responsible for promoting understanding and good practice in the enterprise and when it is normal there, it will likely spread into personal use. The key is to keep it simple; my colleagues are experts in their own fields and I should not require them to become an expert in mine in order to be able to protect themselves or my organisation.