Going passwordless with passkeys in Windows and .NET

Passwords are a problem. While they remain the main way we secure applications, services, and systems, they’re increasingly vulnerable. Cloud compute makes it economical to brute-force valuable passwords, while poorly-thought-out password policies drive users to inherently risky behaviors. And while password managers make it easier to have separate complex passwords for everywhere we need them, other “security” policies block us from using those passwords.

What was intended to be a secure internet is increasingly insecure, with our files, data, and finances at risk. It’s still a Wild West out there, and the question is, who will win that frontier? The good guys or a myriad of bad actors?

One option is a move away from passwords to a password-less world where biometrics and strong cryptography provide better security, working with our hardware to add new layers of protection. By moving away from increasingly complex, hard-to-remember passwords, and learning to rely on secure hardware, we can take advantage of cryptographically complex keys that are both hard to steal and hard to break.

Windows as a secure platform

Microsoft has put security at the heart of Windows 11, requiring processors that support key cryptographic standards, as well as hardware that’s built around TPMs (trusted platform modules). Now the company is building on that effort to bring passwordless authentication to its platforms and encouraging developers to draw on those same tools and APIs in their own code.

At the heart of Microsoft’s approach are two key technologies: Windows Hello and the WebAuthn protocol. Windows Hello is a set of APIs that work with Windows’ certified biometric sensors, either 3D face cameras or fingerprint sensors, to provide a verified identity for a device user. Initial biometric data is captured during enrollment and a hash is saved in the secure storage of a TPM. That data is used to create a credential that is tied to a device. The combination of user and device creates a unique identifier that can be used to unlock authentication, working as either primary or secondary identification.

FIDO2 passkeys and Windows Hello

Windows Hello has evolved from being part of the Windows login experience to being a component of the Windows implementation of the FIDO2 authentication protocol, along with WebAuthn. Now Windows Hello can be tied to passkeys, the common name for FIDO2 discoverable credentials. Passkeys are used both to authenticate and to attest the user, providing both identification and verification, automating the complexities of a modern authorization process.

Passkeys managed by Windows Hello are “device-bound passkeys” tied to your PC. Windows can support other passkeys, for example passkeys stored on a nearby smartphone or on a modern security token. There’s even the option of using third parties to provide and manage passkeys, for example via a banking app or a web service.

Windows passkey support allows you to save keys on third-party devices. You can use a QR code to transfer the passkey data to the device, or if it’s a linked Android smartphone, you can transfer it over a local wireless connection. In both cases the devices need a biometric identity sensor and secure storage. As an alternative, Windows will work with FIDO2-ready security keys, storing passkeys on a YubiKey or similar device. A Windows Security dialog helps you choose where to save your keys and how.

If you’re saving the key on Windows, you’ll be asked to verify your identity using Windows Hello before the device is saved locally. If you’re using Windows 11 22H2 or later, you can manage passkeys through Windows settings.

Adding FIDO2 to your .NET applications

You can take advantage of Windows’ support for FIDO2 and the WebAuthn APIs to work with strong credentials in your code. Much of the necessary functionality is built into the Edge browser, with JavaScript APIs for web applications. A set of Win32 APIs provides support for C and C++, which can be used as the foundation for .NET libraries.

To get started adding passwordless features to your applications quickly, you can use the FIDO2 .NET library, available on GitHub and managed by the .NET Foundation. Like most .NET libraries, the FIDO2 library can be added to your code via NuGet. The library works with all .NET applications including ASP.NET Core web code.

The FIDO2 .NET library contains everything you need to build FIDO2 support into applications, from registering users to verifying them, with support for all classes of authenticators including Windows Hello. It can be used for basic multifactor authentication (MFA), as well as for more complex passwordless scenarios. You might want to consider using it for MFA as a first approach to moving users to more secure authentication techniques, allowing them to get used to using a second device as part of the login process.

Passwordless authentication in .NET

Once you have implemented a MFA solution, you can build on it with passwordless features. That’s perhaps one of the most important aspects of FIDO2—it’s designed to support the journey from traditional authentication to more modern techniques, and eventually to using passkeys.

It’s not hard to use the FIDO2 .NET library as part of a server. You first create a new user with a username and a display name. The library can check that a user doesn’t already have credentials stored on their machine or in an external store. Service attestation options are delivered to the requesting client, which are rendered using its FIDO2 implementation. The client creates and stores the passkey, saving the credentials. Once the requesting client returns the required attestation data, you can create the user data adding credentials to the server store, along with a user ID.

Logging in to the service is the reverse of the process. The server receives the user ID from the client, checks if it exists, and requests an assertion. The client uses biometrics to unlock the passkey, and sends assertion data to the server, where it’s verified using FIDO2’s public key cryptography features. Finally, after verification, the user is allowed to use the service. They’ve not needed to enter a password; everything needed for access is handled by a local passkey store on their PC or phone. The client’s FIDO2 implementation provides those credentials to the server after passing biometrics.

Bitwarden passwordless APIs

Another good option is Bitwarden’s Passwordless.dev APIs. These offer a quick way to add passkey support to existing applications, along with a cloud-based management framework for credentials and the necessary cryptographic framework. Bitwarden is not too expensive, either. A free account gives you support for a single app and 10,000 users. Larger deployments could use a pro account, which offers support for unlimited apps for $0.05 per user per month for the first 10,000 users, dropping to $0.01 per user per month for additional users. If you prefer to link to existing authentication infrastructure, like Microsoft Entra ID, an enterprise plan costs $3 per user per month.

FIDO2 and its associated passwordless patterns are a much more secure way to control access to applications and services. With Windows now providing support for creating and managing passkeys, it’s time to start thinking about using these tools in your code, using Windows’ biometric tools to control access and TPMs and FIDO2-ready authentication hardware to manage keys. The more we rely on these technologies, the more we reduce risk for everyone.