Shouldn’t there be huge demand for an alternative to passwords?
The frequency of phishing attacks is constantly increasing, and even bypassing multi-factor authentication is becoming more common (Evilginx says hello). Maintaining and using password managers is also not a pleasant task – so why do we, as the first security measure, use our fingers to type a more or less random sequence of characters into a text field – and then still have to install the fourth proprietary authenticator app?
If only there were an open standard that is directly integrated into the operating systems of our everyday devices and supported by many manufacturers…
Okay, okay, I’ll drop the sarcasm – let’s start from the top – who (besides me) actually wants to tell us what the future of authentication looks like?
Key Figure – FIDO Alliance
Even 15 years ago it was clear that passwords are not future-proof. The alliance originated in 2009 from collaborations between payment provider PayPal and a manufacturer of biometric sensors, to enable secure authentication of payments.
Over the years, more and more companies joined the initiative, recognizing the value of a common authentication protocol. Notable early adopters include Google, Samsung, and Microsoft – those familiar with the azurblue world will recognize an early fruit of the alliance: Windows Hello for Business is a prototypical implementation of the guidelines (even though it had to wait for FIDO certification until 2019).
Today, over 250 organizations are members of the alliance, and the standards defined by and with it are now implemented in countless websites and services. I expect that the protocols and guidelines will continue to gain traction – when users see something good, they demand it. And in terms of cross-platform and cross-company support, FIDO2 is unrivaled.
But what did we really get from the alliance?
New Keys to the Castle
(If the puns are starting to get uncomfortable, I have bad news)
When I say "FIDO2 key", many – well, some – think of USB dongles like the YubiKey. They are the most widespread and well-known result of the FIDO Alliance and promise both phishing resistance AND a simpler login process. Plug in, enter PIN or scan fingerprint, and you’re logged in.
The higher security comes from the fact that communication between the end device and the service provider is truly end-to-end encrypted – no snooping possible. Additionally, the underlying "secret" can never be intercepted because it always remains in the dongle – in technical jargon, the key terms are "hardware-supported asymmetric encryption".
To turn very technical terms into something hopefully understandable, I turn to my favorite visualization: The Wax Seal.
CCBY – Wax Seal by Wikimedia User Xenophon
- When John first signs up for a service, the provider sends him an envelope with information about him and the account to be confirmed. In the illustration, the service provider is exemplarily Apple, another member of the FIDO Alliance.
- John places a wax stamp, which creates an image (= seal), on the envelope. The used stamp creates a negative. An attacker cannot create further copies with the seal itself; they would first have to produce an exact reproduction of the stamp.
- The service stores the seal with John’s user account. However, the stamp that created the seal always remains securely with John at home.
Every time John wants to log in now, the first step is skipped, and the service provider only has to compare the seal on the envelope with the one they know. Even if the provider is breached, the stamp, with which the attacker could impersonate John, is not present.
Disclaimer: This is a highly simplified illustration; in reality, everything is mathematics.
The most important differences:
- The information in the envelope changes the seal, so every message looks different
- John has a “seal” for each provider
- The seal is “indestructible”; if you get the letter in your hands, you can’t read its contents
Doesn’t quite fit
But let’s switch from theory to reality – although I own a YubiKey, I must admit that its usability leaves so much to be desired for me that I hardly ever use it. It is only used for my administrative accounts, where I place a higher value on security.
The disadvantages of such a dongle are obvious: I have to carry additional hardware with me, which then only works with certain services. How conveniently it can be used is also very dependent on the current work setup. When my laptop is in my docking station behind my monitors, the FIDO USB Key is effectively useless. To authenticate, I have to tap a button on the dongle (pictured is a dramatization).
Additionally, the memory of USB keys is limited. For example, my YubiKey can only be used for a maximum of 25 accounts. If I want to secure more with a FIDO2 key, I need to buy more hardware, and actually always two pieces – because what happens if one of my keys gets lost or destroyed? Then I must have a second one registered to be able to recover my user account, otherwise, I might as well stick with the insecure login method – and the hardware isn’t exactly cheap.
So, do we ultimatekey come to no solution that is usable for everyone?
The Key must Pass
It’s not entirely accurate to call the USB dongle a “FIDO2 Key” – the actual “Key” is just stored there. But since this terminology has become established, a new term was needed. So, when we now talk about the actual cryptographic (= mathematical) keys on which authentication is based, we say “Passkey”. Thus, on my YubiKey, there are multiple Passkeys for various admin accounts.
I highlight this not because I like correcting semantics (well, let’s say “not only”), but because this distinction has a practical impact – we can store Passkeys in places other than USB dongles, such as directly on our smartphones or laptops.
Microsoft announced late September ’23 that storing and using Passkeys will be released for all versions of Windows. So, if you are up to date with patches today, the already familiar Windows Hello can be used not only for Microsoft services but for all services that support “Device Bound Passkeys”.
This becomes even more attractive when Passkeys are managed in the Apple Keychain or in the Google Chrome profile. This allows for keys to be shared between devices, at least within one ecosystem. Alternatively, you can use the password managers you currently have as Passkey managers. This way, the used “stamps” can be taken across all platforms.
Makey it happen
This might all be a bit hard to imagine, so let’s look at a live demonstration. This is already possible today with services like Adobe, GitHub, PayPal, and soon with Entra ID / Office365:
Same Device
Here, I want to log into the PayPal app on my private phone without needing to enter a password. After navigating to the relevant section in the app menu (currently Account > Login & Security > Passkey), I press the button to register and am prompted to create a Passkey (PayPal unfortunately doesn’t allow screenshots). The Passkey is encrypted with my screen lock.
 |
 |
|---|
And that’s it. The next time I want to log in to PayPal, my Passkey will be automatically suggested and I’m logged in:
Mobile Phone as Authenticator
The mobile phone and the end device must have Bluetooth enabled to communicate (For those interested: CTAP)
If I want to use a full-fledged YubiKey replacement, I need to be able to log in, for example, to a website on my Windows notebook with a Passkey from my phone.
This is also possible. For example, if I want to log in to my private GitHub account at work, I select to log in with a Passkey. Since Windows doesn’t find a corresponding key in its own storage, it offers me the option to log in with an external device. A QR code is displayed for this purpose.
 |
 |
 |
|---|
I scan the QR code with my camera, confirm the login via FaceID, and am logged in.
 |
 |
|---|
Those who just want to try out how it feels can do so on test sites, such as Passkeys.io. Even better would be to check if one of your most-used services already supports Passkeys.
Doesn’t quite pass yet
Even though Passkeys are an important step in the right direction, we’re not quite there yet. Although many services, especially large ones, have introduced Passkey support, unfortunately, not all have done so. Therefore, we will still be working in a mixed mode for a while, but I will take every Passkey I can get.
The implementation is also not always optimal – in my PayPal example, for instance, I still have to enter a MFA code. If I were to turn off MFA there, it would also apply to password logins (as of December 2023).
From a security perspective, I’m personally not always a fan of transferable Passkeys. While they simplify handling, they open up, in my opinion, too large an attack vector in recovery. However, this can be easily addressed with a good implementation – the protocol allows for a device-bound Passkey to be enforced.
Closing Thoughts
So, we see that while Passkeys are not yet a solution to all our problems, they have the potential to make our logins simpler and more secure. Unfortunately, more and more services must first implement the relevant protocols, and manufacturers need to enable synchronization between our devices. For me, however, it’s enough motivation to finally migrate my password manager – so that at least the master key is no longer vulnerable.
I will not moderate comments and do not want your email address; please join the discussion on meinen Zugehörigen LinkedIn Post.
Translation assisted by ChatGPT
If you are interested in the things I do, please follow me on LinkedIn.
Comments