We all use passwords, yet we all struggle to remember them. Some people reuse the same password across multiple websites. Others turn to password managers to create unique passwords for every site. It’s been a challenging problem with no clear solution.
Even with excellent personal security hygiene, data breaches and password-related attacks dominate cybersecurity headlines. Sites like HaveIBeenPwned show just how frequently our credentials are compromised. The industry has tried various solutions, such as multi-factor authentication and hardware security keys, to dampen the impact of data breaches. Layers of additional authentication are complex and come with user experience challenges. There has to be a better way, right?
In this blog series, we will explore passkeys, the next evolution in secure authentication. Passkeys promise to replace passwords with something stronger, simpler, and inherently resistant to phishing attacks. Future posts will cover how to implement passkeys in ASP.NET Core web applications.
For now, let's start at the beginning: we'll take a look at passwords, the evolution of authentication standards, and the cryptographic principles that are behind passkeys.
The Problem With Passwords
Passwords have served as the primary authentication mechanism for decades, but they are flawed in many ways.
Most people choose passwords that are easy to remember, but also make them easy to guess. The burden of remembering unique, complex passwords for dozens of services leads to password reuse, which means a single breach can compromise multiple accounts. Even with password managers, the risks remain: one leak, and several accounts could be compromised.
Passwords are also vulnerable to social engineering. Phishing attacks continue to succeed because users can be tricked into entering their passwords on malicious websites designed to steal credentials. Shoulder surfing and other low-tech attacks still work surprisingly well.
Technically, passwords can be attacked in several ways. Brute force attacks are easier than ever thanks to cheap computing power. Dictionary attacks exploit predictable patterns, and credential stuffing takes advantage of password reuse by testing leaked credentials across multiple services. Even when passwords are stored securely, application databases are attractive targets, and techniques like rainbow tables can crack hashed credentials.
The burden of passwords has reached a tipping point. Breaches are expensive to fix, password resets waste time, and complicated requirements frustrate users and even drive them away. On top of that, new regulations keep raising the bar for security. Passwords aren’t enough anymore.
Evolving Passwords and Authentication
Over the years, passwords and authentication have been evolving. Multi-factor authentication was introduced, and an attempt at hardware security keys introduced concepts that later evolved into passkeys.
Multi-Factor Authentication (MFA)
Multi-factor authentication (MFA) was the industry’s first big move to fix the password problem. The idea is simple: don’t just rely on something you know (like a password), but add something you have (like a phone or hardware token). Perhaps even add something you are (like a fingerprint or face scan). By combining these factors, MFA makes it much harder for attackers to break in, even if they have your password.
But MFA isn’t perfect. Phones can run out of battery. An MFA text message may not be delivered because you're in a region where cellular connection is spotty. SIM swapping may cause the text message to be delivered to someone else. Hardware tokens can get lost, and biometric systems don’t always work smoothly. And where did you store the recovery codes again?
In terms of security, MFA is a significant improvement over passwords alone, but it's not user-friendly and still relies on passwords as the first line of defense.
Universal 2nd Factor (U2F)
Universal 2nd Factor (U2F) was a big step forward when Google introduced it in 2014. Instead of relying only on shared secrets, U2F introduced public key cryptography for authentication. A hardware security generates a private key for every app you use, and the service stores the matching public key. The hardware key signs a challenge using the private key, and the service validates the signature using the public key. Even if someone gets hold of the public keys, they can’t use them to log in.
U2F did come with its issues. It was primarily used as a second factor, so you still needed a password. Support in browsers and operating systems was inconsistent; you need to keep the hardware key around. The device may be USB-A, but your computer only has USB-C. U2F provided a solid foundation for authentication, but the user experience was not the best.
FIDO2 and WebAuthn
FIDO2, created by the FIDO Alliance, is a set of standards that make passwordless authentication possible. WebAuthn is a key part of FIDO2. It's an API that lets applications use strong, cryptographic credentials instead of passwords. It integrates with the browser, various operating systems, supporting both hardware and software authenticators.
Note: There are (many) more components and protocols involved, such as CBOR, CTAP, and more. Refer to the Web Authentication spec if you want to dive into the details.
With FIDO2 and WebAuthn, or passkeys in short, you can log in using the security features already built into your device. No passwords are needed anymore: a device with Windows Hello, Touch ID, or Face ID is all you need. Credentials (called resident keys) are stored securely on your device (or on a hardware key), and the operating system synchronizes credentials across all of your devices.
How Passkey Authentication Works
Passkeys work using public key cryptography. Your device creates a pair of keys: one private, one public. When you sign up for a service, your device keeps the private key safe and only shares the public key with the service.
When you log in, the service sends a random challenge to your device. Your device signs it with your private key, and the service checks the signature using your public key. This proves your identity, without ever sending your private key over the internet.
Passkeys are bound to the service domain (origin), so even if a phishing site tries to trick you, your device won’t sign a challenge for the wrong site. This makes phishing attacks much less likely to succeed. Every login challenge is also unique and only valid for a short time. Even if someone records your login, they can’t reuse it later, preventing replay attacks.
Because your private key never leaves your device, server breaches don’t expose your credentials. Even if breached, attackers can’t use the public keys to impersonate you.
Your device’s authenticator is what keeps your private keys safe. This could be a hardware security module, a secure enclave in your phone or laptop, or a Trusted Platform Module (TPM) chip. These technologies make it extremely hard for anyone to steal your keys, even if they have physical access to your device.
Passkeys and Authenticators
Authenticators are a big reason passkeys are so much easier to use than passwords or other login methods. They handle all the security behind the scenes, while you just tap, scan, or enter a PIN to complete the signing process.
Passkeys support two primary types of authenticators. Platform authenticators are built directly into devices, including technologies like Windows Hello, Touch ID, and Face ID, all integrating with the user's existing device security. Cross-platform authenticators, such as YubiKey and other external security keys, offer portability and can be used across multiple devices and platforms.
To improve user experience, platform authenticators like your operating system, and password managers such as 1Password, Dashlane, and Bitwarden, synchronize passkey credentials with your devices, making them more portable and significantly enhancing user experience.
In addition, your browser or operating system may also support cross-device passkey support, where you can use a service on one device but complete authentication with a passkey on another device.
Passkey APIs and Ceremonies
We already saw how passkeys work, based on two flows: registration, where a key pair is created and communicated, and authentication, where a challenge is signed and validated. These flows are also called ceremonies in WebAuthn. From a technical perspective, these ceremonies involve coordination between the server and client through well-defined APIs.
During registration, the server generates a cryptographic challenge and sends registration options to the client. The client calls the navigator.credentials.create() API, which prompts the user's authenticator to create a new key pair. The private key stays on the device, while the public key and attestation data are returned to the server for storage.
const credential = await navigator.credentials.create({
publicKey: {
challenge: challenge,
rp: { name: "Your App" },
user: { id: userId, name: userEmail, displayName: userName },
pubKeyCredParams: [{ alg: -7, type: "public-key" }]
}
});
For authentication, the server generates a fresh challenge and sends authentication options to the client. The client calls navigator.credentials.get(), which prompts the authenticator to sign the challenge with the stored private key. The server verifies this signature using the stored public key. The flow (for logging in) looks like this:
The navigator.credentials APIs abstract away the cryptographic complexity while maintaining security. Developers work with simple JavaScript calls, while the heavy lifting happens securely in the background. Operating systems provide similar APIs for native applications. This means passkey support isn't limited to web browsers: native apps can use the same underlying technology.
We'll look at these APIs in more detail later in this series.
Conclusion
Passkeys are changing how we authenticate with web and mobile applications. They address the flaws of traditional password systems and bring a much better user experience. Using public key cryptography and standardized protocols, they provide a secure, phishing-resistant alternative to passwords.
Although not yet supported by every application out there, there is a growing momentum regarding adoption. There is widespread browser support, platform integration, and growing acceptance by companies and users. Large technology vendors like Microsoft, Google, and Apple are making passkey support more approachable and are actively promoting it as integral to their products’ user experience.
In the next post of this series, we’ll look at the practical implementation of passkeys in ASP.NET Core applications.
Have questions about passkeys or WebAuthn? Curious about specific scenarios or challenges? Let us know in the comments below.