WebAuthn moved stronger login into the browser
WebAuthn gave web services a common interface for public key authentication. Browser support opened distribution, while enrollment and account recovery still demanded careful product design.
A stronger login method is difficult to distribute if every website needs a different device integration. On 20 March 2018, the World Wide Web Consortium published Web Authentication, or WebAuthn, as a Candidate Recommendation. It described a common browser interface through which websites could create and use public key credentials. That moved an important part of authentication from a collection of proprietary integrations toward shared web infrastructure.
Candidate Recommendation meant the document was considered stable enough to encourage implementation. It was still work in progress, with interoperability evidence required before advancing. Security companies had an opportunity to make the emerging capability usable across real accounts, devices and organisations, including the integration and support that a draft interface alone could not provide.
Two specifications joined different parts of the journey
The specification defined registration and authentication as related operations. At registration, an authenticator creates a credential and the service associates its public key with the user's account. Later, the authenticator produces an assertion that the service can verify. A browser mediates access, while the credential is scoped to the relying party: the service asking the user to authenticate.
Register a credential
The authenticator creates a credential; the service associates its public key with the account.
Approve an authentication request
The user interacts with the authenticator, which signs data for the requested operation.
Verify the response
The service checks the assertion, including its challenge and the expected origin and relying party information.
The Candidate Recommendation keeps private key operations under the authenticator's control. The server verifies the returned assertion.
On 10 April, W3C and the FIDO Alliance publicly explained how WebAuthn fit alongside the Client to Authenticator Protocol, or CTAP, within FIDO2. CTAP allowed an external security key or mobile device to communicate locally with the user's computer or phone using transports such as USB, Bluetooth or NFC. Authenticators built into a device offered another route. These components solved different integration problems and should not be treated as interchangeable names for a single browser feature.
The announcement said Google, Microsoft and Mozilla had committed to support and had started implementations across several operating systems. Implementations were underway, but suppliers still needed to establish compatibility across browsers, devices and websites. A supplier planning a rollout needed to test the combinations its customers actually used.
A different kind of secret
With a reusable password, someone who obtains the secret may be able to submit it elsewhere, especially if the user has reused it. WebAuthn's design used a credential key pair. The service received the public key needed for verification, while the private key remained under the authenticator's control. Copying that public key from a breached service would not give an attacker the private key required to produce a valid signature.
Scoping and origin checks also changed the phishing problem. A convincing imitation of a website should not be able to request another service's credential through a conforming implementation. This is more than asking a person to notice a suspicious address. Part of the decision about which credential can be used becomes an enforced property of the browser and authenticator.
A fingerprint or another local gesture can authorise the authenticator's operation without sending the biometric template to the website. That does not make every deployment equally strong: the specification distinguished user presence from user verification. A service needed to decide which properties it required and verify the returned evidence correctly.
The difficult cases begin around the login
Cryptographic verification does not establish that the right person enrolled the first device. A service that allows an attacker to add an authenticator after a weak account recovery process can undermine the benefit of a strong everyday login. Enrollment and recovery therefore need to be designed as part of the same product, with explicit rules for who may create, replace or remove credentials.
Consider an employee who loses a security key before a critical deadline. An organisation needs a usable route back into the account, but an improvised helpdesk exception may be precisely the path an attacker tries to exploit. Spare authenticators, supervised replacement and clear records of account changes are possible operational responses. Their suitability depends on the organisation; the browser API does not choose or fund them.
Nor does stronger authentication remove every route to account misuse. A compromised session or an already authorised endpoint presents a different problem from a stolen password. The practical benefit should be stated narrowly enough that a customer can see which risk is reduced and which controls still have work to do.
Where an identity company could earn its place
Standardisation can expand a market while reducing the value of proprietary plumbing. A young identity company could increasingly rely on a common interface, but would have to offer something beyond access to that interface: reliable integration, policy administration, device lifecycle management or a recovery process that customers could operate. The browser vendors' involvement was both a distribution opportunity and a reason to be precise about what remained chargeable.
A commercial evaluation should follow actual account journeys. How many eligible users completed enrollment? Which device combinations generated support work? Could administrators remove a lost authenticator promptly? These observations connect a security proposition with the cost of delivering it. A common interface made wider deployment more practical; successful businesses still had to make it dependable for the people using it.
Sources
- Web Authentication: An API for accessing Public Key Credentials Level 1 — W3C Candidate Recommendation, 20 March 2018 (opens in a new tab)
World Wide Web Consortium
- FIDO Alliance and W3C Achieve Major Standards Milestone in Global Effort Towards Simpler, Stronger Authentication on the Web (opens in a new tab)
World Wide Web Consortium and FIDO Alliance
Published
