One place for your second factor, and a code you can scan

A second factor is the cheapest protection a business account can have, and the page that turns it on is the one nobody tests properly. Ours proved that: it gave you a thirty-two character secret and a link, and no code to scan — so somebody securing the account they use to fix everything else had to copy a long string of characters by hand, correctly, first time.

Three ways to take the same secret

The enrolment page now offers whichever of three works where you are, and all three carry the same thing:

• A code to scan, on a screen wide enough for another device to see it — the usual way, and the one that cannot be mistyped.
• A button, on a phone, because a phone cannot scan its own screen. It hands the secret straight to the authenticator app already installed.
• The key, written out, for a desktop authenticator with nothing registered to open that button, and for anyone whose camera will not focus.

One detail matters more than it looks. The scannable code is drawn in the page from the value the server already sent for the other two — it is not fetched as an image from anywhere. A secret that travels to a third party to be turned into a picture is a secret that party has seen, and the whole point of the second factor is that only you and the account hold it.

We drew it with the component the suite already uses for labels, tags and price stickers rather than adding a second way to make one, and checked it by decoding the rendered image with an independent decoder: it reads back exactly the text the key spells out.

Why one store, and not two

Behind that page there was a subtler problem. Two systems could hold a second factor for the same person: the sign-in service’s own table, and the directory that holds people. Two stores is the arrangement where a settings page says two-factor is on and the sign-in checks somewhere else — and nobody notices until the day it matters.

So there is one, and the split follows who owns what:

• The factor — the secret, the counter that stops a code being replayed, the recovery codes, and the lockout after too many wrong ones — is one thing, and lives with the account it protects.
• The challenge — “this password was accepted a minute ago, and I am holding this sign-in until the code is right” — stays with the sign-in service, because that is its claim to make, and capping its attempts is what stops a held sign-in being used to guess.

Every check is made as the person in front of us, with their own token. There is deliberately no way to ask “does this other person have a second factor?” — that question is answered with “could not tell”, which is the honest answer and also the one that gives an attacker nothing.

Two refusals that must not be confused

When a code is rejected there are two very different reasons, and telling a person the wrong one wastes their afternoon. “That code is wrong” means look at your phone again — the clock may have drifted, or you may have read the next one. “Your session has gone” means the sign-in itself expired and there is nothing to do but start again.

The two arrive as the same status code from underneath, and are told apart by which layer refused. Reading the second as the first would send somebody back to their authenticator app to try codes that could never have worked. It is the same discipline as three different noes: a refusal is only useful when it names the thing to do next.

Recovery codes belong beside the secret

Recovery codes, the replay counter and the lockout all describe the same factor, so they live with it. Anything else invites the failure where a factor is removed in one place and its recovery codes keep working from another — a back door with your own name on it.