The unprotected path: enrollment and recovery

Discussions about authentication are almost always about the sign-in: FIDO2 instead of SMS, phishing-resistant instead of push, get rid of passwords. All correct. It just secures exactly one of three routes into an account.

The other two are the way in, meaning registering an authentication method for the first time, and the way back, when somebody is locked out. Both come out at the same place: a working means of access. And both are often protected considerably less well than the sign-in the discussion was about.

Why this is the more interesting attack surface

Anyone who can register their own authentication method on somebody else's account does not have to defeat an existing one. The question is no longer “how do I bypass MFA” but “how do I become one of the MFA methods”. That is a considerably easier question.

The classic route to it is not technical. It runs through a call to the help desk, a new device, a plausible name and a little time pressure.

Securing the way in

The first registration is the most delicate moment, because there is nothing yet to secure it with. That is exactly what the Temporary Access Pass is for: a time-limited code that counts as a full credential and lets somebody sign in once in order to register a permanent method afterwards.

The benefit is that there is no password at the end of that chain. New joiners can land directly on a security key or in the authenticator app, without an initial password ever having existed, travelled over an unsecured channel and then stayed behind in a chat history.

• —Lifetime as short as is organisationally workable
• —Single use as the default; multiple use only with a reason
• —Issue it over a channel other than the one the person then signs in from
• —Log the issuance, because whoever may issue a TAP can grant access

The second building block is an access policy on the registration of security information itself. That action can be targeted in its own right and tied to a condition, a trusted location for instance, or a managed device. That turns “anybody can add a method from anywhere” into a controlled action.

Securing the way back

Self-service password reset takes work off the help desk and is therefore switched on almost everywhere. It does, however, move the security question: from that point on the account is protected exactly as well as the methods that can reset it.

Two points matter to me here. First the count: two required methods is a different statement from one. Second the quality: security questions do not belong in the list. Something a person can research is not a factor.

And then there is the help desk. The decisive question here is less how a reset happens than who may reset whom. The role that permits everyday resets should explicitly fail against administrator accounts. Otherwise a successful phone call to the help desk is the shortest route to a privileged account, and the whole edifice of strong authentication rests on a phone conversation.

The rule behind it

There is a rule of thumb that covers all three routes: an account is as strong as its weakest route to a valid session. Raising the sign-in to phishing-resistant methods while leaving recovery over a mobile number in place improves the sign-in and not the account.

In practice that means: every time an authentication method is tightened, registration and recovery belong in the same piece of work. Not in a follow-up ticket.