For decades, signing in to a website usually meant proving that you knew a secret. The user typed a password, the website checked it, and access was granted when the submitted information matched what the account expected.
Protecting that process became increasingly sophisticated, but the basic weakness remained. A password was something a person could reveal. It could be copied, reused, entered into an imitation website, captured by malicious software, or exposed indirectly when authentication records were stolen.
A different model was beginning to emerge in web browsers. Instead of giving a website the secret used to prove identity, the computer could keep an important part of the credential locally and provide cryptographic evidence that the correct credential was present.
The website did not need to receive the private cryptographic key. It could receive a public credential during registration and later verify a signed response produced with the corresponding private credential.
The Secret No Longer Had to Be Shared
Passwords are commonly described as shared secrets because the authentication system ultimately needs enough information to determine whether the secret supplied by the user is correct. Secure servers do not need to store ordinary readable passwords, but password authentication still depends on the user’s ability to reproduce the expected secret.
Public-key authentication works differently. It uses two mathematically related pieces of cryptographic information with very different responsibilities.
The distinction changed what had to cross the network. A reusable private key did not have to travel from the computer to the website simply because the user wanted to sign in.
Registration Created a Relationship With One Website
Before the website could recognize a cryptographic credential, that credential first had to be registered. The browser, authenticator, and website participated in establishing information that could be recognized during a later visit.
The relying party asks the browser to participate in creating a credential for the user.
Cryptographic information is established so the authenticator can later prove possession of the appropriate private credential.
The relying party receives the information it will need to identify the credential and verify future authentication responses.
The sensitive cryptographic material is not simply transferred to the website as though it were another password.
Creating a credential established the relationship. A later authentication used that established credential to prove that the appropriate authenticator was still available.
Returning to the Site Started a Challenge
A later sign-in did not require the server to ask for the private key. Instead, the website could issue a challenge that had to be answered using the registered credential.
This challenge mattered because authentication should prove something about the current sign-in attempt. Simply replaying an old successful response should not be equivalent to producing a valid response for a new request.
The relying party provides the information needed to begin a new authentication operation.
The browser acts as an intermediary between the web content and the authentication mechanism available to the user.
The authenticator can require an appropriate local action before allowing the credential to participate.
The private credential participates locally in generating the response rather than being transmitted to the remote website.
The relying party uses its registered public information to determine whether the returned response is valid.
The website could verify evidence produced by the credential without needing possession of the private credential itself.
Windows Hello Could Authorize the Web Credential
Microsoft Edge demonstrated an early version of this idea using Windows Hello. A Windows computer that already supported local user verification could participate in web authentication without turning a face, fingerprint, or Windows Hello PIN into an ordinary website password.
That distinction is easy to miss because the visible action might still be extremely simple. A person could look at the camera, touch a fingerprint reader, or perform another Windows Hello verification step. Behind that familiar action, however, the website authentication mechanism could be based on cryptographic credentials rather than the transmission of biometric information.
Windows Hello could determine whether the person using the computer was authorized to perform the authentication operation.
The website did not need a copy of the user’s face, fingerprint, or Windows Hello PIN merely because one of those methods was used locally.
Facial or fingerprint recognition could help unlock or authorize use of a credential. The remote service could authenticate cryptographic proof rather than receiving the biometric measurement itself.
A Database Breach Changed Meaning
Password databases are valuable targets because password-derived information can sometimes be attacked after it has been stolen. Weak passwords may be guessed, and reused passwords can create consequences on services completely unrelated to the original breach.
Public-key authentication changes what the website needs to retain for authentication. Public information can verify a response, but possession of that public information does not provide the corresponding private key.
This did not make the server unimportant or impossible to compromise. A malicious party controlling a website could still expose private information, alter content, manipulate accounts, or attack other parts of the service.
The narrower security improvement was significant nonetheless. Stealing the website’s authentication database did not automatically mean stealing the private credentials used by authenticators.
Protecting the credential addressed one important part of authentication. Secure browsers, trustworthy software, protected account recovery, server security, and careful implementation still mattered.
A Credential Could Know Which Site It Belonged To
Passwords have another unusual property. They can be typed almost anywhere.
A convincing phishing page can display a familiar logo, reproduce a login form, and ask a person to enter the same secret used on the legitimate website. The user may recognize the appearance of the page but fail to notice that the password is being submitted somewhere else.
Cryptographic web authentication was designed around the identity of the relying party. The browser and authenticator could participate in binding a credential to the web context for which it had been created.
Once somebody knows the characters, the secret can potentially be entered elsewhere.
The authentication system can associate the credential with the relying party for which it was registered.
Authentication is no longer only a text field accepting whatever secret the person chooses to type.
This property offered a fundamentally different defense against credential phishing. Instead of expecting the user to perfectly recognize every fraudulent login page, part of the decision about credential use could be enforced by the authentication system itself.
The Browser Had More Responsibility Than Before
Traditional password entry made the browser look deceptively passive. It displayed a form, accepted characters, and transported information to the website.
Web authentication required the browser to participate in a more structured exchange. It had to connect the website’s request with an appropriate authentication mechanism while preserving the security boundaries expected by the credential system.
Four participants
User authorizes the authentication operation.
Website requests proof for the registered account.
Browser mediates between the web request and authentication system.
Authenticator uses the appropriate private credential to produce the required proof.
That arrangement also explains why the technology was more than simply adding fingerprint support to a web page. The important development was the standardized relationship among these participants.
The Standard Was Still Moving
The Web Authentication technology of this period was not yet the mature WebAuthn ecosystem that would become familiar later. Standards work was still evolving, browser implementations were early, and interfaces could change as the specification developed.
Early Microsoft Edge support demonstrated the direction of web authentication, but the interfaces and capabilities available during this stage should not be assumed to match later finalized WebAuthn implementations exactly.
This experimental stage was important because several previously separate ideas were converging. Browsers were gaining a standard way to communicate with stronger authentication systems. Devices were gaining local user-verification mechanisms. FIDO technologies were pushing authentication away from reusable shared secrets.
The result was not simply a more convenient password box. It was an attempt to change what a website needed from the user in the first place.
A website could recognize an account through verification of a cryptographic response tied to a registered credential rather than depending entirely on a memorized string.
The Important Part Stayed on the User’s Side
The most consequential part of this model was almost invisible. The website could know that the expected credential had answered without receiving the private credential that made the answer possible.
That separation changed several familiar assumptions at once. Authentication information stored by a server could be less useful to an attacker. A credential could be associated with the intended relying party. Local biometric verification could authorize a cryptographic operation without becoming remote biometric identification. The browser could enforce rules that an ordinary password field could not.
Passwords would not disappear overnight, and early web authentication still had substantial development ahead of it. But the architecture had shifted in an important direction.
A website no longer had to recognize a person only because that person was able to type the correct secret. It could recognize cryptographic proof from a credential whose most sensitive part never needed to leave the user’s side.
