Yubico and Microsoft Introduce Passwordless Login
yubico.com
yubico.com
- Q: Doesn't passwordless mean single factor? Isn't that insecure?
A: It could mean single- or two-factor. FIDO2 and the new YubiKeys support an on-device PIN that isn't shared with the server, like conventional smart cards. This allows the key to act as both "something you have" (the key itself) and "something you know" (the PIN for the key). The PIN is optional, though, so both the single factor and two factor use cases are possible.
- Q: Is this Azure/Windows/AD only?
A: This post highlights the partnership with Microsoft and the integration with their products, but FIDO2 is not Microsoft-only (and Yubico will not be the only key vendor). CTAP2, once finished, will be published as an open standard like U2F, and the accompanying Web Authentication API [1] (WIP) is an OS-agnostic W3C standard enabling the same features in browsers.
[1]: https://www.w3.org/TR/webauthn/
- Q: Will I need a new YubiKey?
A: For passwordless (PIN) login, yes. However, existing YubiKeys with U2F support will be usable as a 2nd factor in Web Authentication, and sites that currently use U2F can upgrade to using the Web Authentication API without needing their users to re-enroll their keys.
Full disclosure: I'm a Yubico engineer and one of the editors of the Web Authentication spec.
P.S. just ordered a yubikey security key, excited to add this additional layer to my own personal byzantine security labyrinth. Or maybe simplify it, who knows!
At least Web Authentication platform credentials should let you have multiple authenticators without having to buy an extra YubiKey.
https://github.com/Yubico/libfido2
Doesn't this PIN become a master password for all the websites at that point?
What you do is you take this key that unlocks the kingdom.
And then you keep it safe.
Unlike before there isn't 20 keys that unlock parts of the kingdom that might lead to unlocking other kingdoms via roundabout ways. Your attention for security can be focused on a single key.
The average users will be much safer if we force them to only have to remember one single password that can be securely used for everything without the usual drawbacks (that's why security people recommend password managers)
With personal password managers, no third party is issuing tokens for access - just you. So it’s unlikley to be chosen for an attack - because it’s too hard for the attacker to acquire the credentials for access without detection.
With a hardware key you gain the advantage of the attackers having to physically gain access to that key.
Password managers don't protect against this. People have given attackers their entire password vault, all you need is a convincing story about some security audit and you needing to review all their passwords. Users believe this.
The solution there is to take away the things a user can leak (passwords) and replace them with things that can only be stolen (tokens). We can train users to never give away their yubikey. Of course some will still fall for social engineering but for a yubikey/equivalent it's fully acceptable to say "never ever never give to anyone, no matter what they say".
No third party issues tokens in WebAuthn either - you have your one or a couple of authenticators you use everywhere, and those authenticators create their credential keypairs locally on the device (and a separate keypair is created for each site - they're not shared between sites).
There might be a way to steal the PIN if the user enters it on a compromised machine, but you can't do anything with the PIN. You need the physical device as well.
Needless to say, this is much, much harder than stealing someone's password.
About 15% of the user population really cares about security and will take the right precautions. It’s the other 85% that are soft targets that keep attackers in business.
It seems like the scenario you're describing in further replies is this: 1) Alice has an account at service A and an account at service B, and authenticates to both with the same FIDO2 token. 2) Eve calls service A and convinces them she's Alice and needs a new token. 3) Service A sends Eve a new token registered to Alice's account. 4) Eve uses the new token to log in as Alice at service B.
The above attack is not possible, since the keypair for service A is not usable at service B. This separation of credentials for separate services is a fundamental FIDO/WebAuthn design feature for damage control and user privacy. Eve can use the new token to log in to service A, yes, but only to service A.
Even if service A and service B were to try to cooperate out-of-band to support each other's credentials, the browser would not let them unless they're on the same domain.
So the ‘passwordless’ option here is either rename the password to PIN or eliminate it to provide single-factor login. The latter is a dream for smart attackers, since there is always some social engineering route they can use to acquire a legit token.
Also: unlike a shared secret like a password you share _everywhere_ (and let's face it, most people do), an on-device PIN can be changed in a single place should it ever be compromised.
Undoubtedly the same holds true for these Microsoft services.
No, since passwordless login is available, the lowest denominator applies: single factor. Despite all your efforts it will most likely be possible to perform a passwordless login even when password is required in a few years (as these things get broken). The something you know is useless, as it can be ignored. And because it can, it will. Either by force, by negligence or by laziness.
It's also allowed for authenticators to always require PIN even if the server doesn't, but the current YubiKey obeys the server's preference.
But yes, there will of course be bugs. But that is also true for password logins, so I don't see it as a particularly convincing argument.
It was all in vein; the browser support is still horrible, no one want to use it and it's not possible to use on mobile. How can you make a security solution that doesn't work on mobile?
Making a new "Web Auth" standard is a huge mistake, and I will not fall into that trap again.
If anything, the web needs technology that allows browsers to present secure third-party auth to web services (e.g. through TouchID, the way that Apple Pay works on Safari and Mobile Safari).
> A: It could mean single- or two-factor. FIDO2 and the new YubiKeys support an on-device PIN that isn't shared with the server, like conventional smart cards. This allows the key to act as both "something you have" (the key itself) and "something you know"
If "something you know" is physically stored on "something you have", doesn't this make "something you know" completely moot?. Please explain how this doesn't simply reduce to "something you have". In other words, if someone steals your Yubikey, can they login as you without knowing anything additional?
Private keys are way, way more secure than passwords for that reason alone. You don't have to give anything secret to a third party.
If that's the one problem this solves and revocation and recovery and 2-factor are all still as difficult and broken as they are now with passwords that's still a huge win.
EDIT: more thoughts. I also really hope that hardware tokens like a yubikey are not required for every site or app. I'd like to be able to keep private keys on my phone or laptop for some things (how many of us keep our ssh keys exclusively on hardware tokens?).
But on the security note. There are several types of security. Security from the people directly around you and security from everyone on the internet.
Without any malware, I could pickup my friends keys and log into their account on my computer in seconds and without their knowledge. This is harder to do with a password. At the same time a password is much easier for someone who doesn't even know who I am to attack.
It's why 2FA is so necessary, it helps defend against both methods of attack.
And like I said in my edit, I really hope that Yubikey is not the one and only one way to store private keys. I personally would be perfectly happy, for most websites and apps, to manage keys just like I do for ssh. On my hard drive, backed up to another hard drive or two of mine, protected by a passphrase. I imagine most people would be pretty comfortable letting a service like lastpass manage most of their private keys for them, with multiple copies synced between devices and encrypted with a strong passphrase.
If I'm worried about 'people on the internet' that's threats like brute forcing my weak password, or determining my password on one site (through phishing, password leaks, whatever) and trying it everywhere else and finding I reused it; potentially using malware to slurp up passwords.txt from the desktop where I keep my varied passwords. If I keep a strong password for each site in a journal near my computer, I'm fairly well protected from internet threats as long as I don't get a keylogger. If I make sure I keep a copy of my passport journal somewhere else too, I won't lose access.
If I'm worried about people next to me, say roommates, office mates, or any one else who is near my computer, I'm more concerned about the physical security of my password journal; it might not be a good idea to keep it next to the computer if untrusted people will be there. These people could also be looking through password leaks, but they probably aren't.
This is a huge improvement!
But FIDO has more competition than that. Since it's not backwards compatible with most existing systems, we have to choose which new protocols to support: passwordless, ssh-like keys, certificates, SQRL, etc. There's limited trust and resources to go around.
Clearly you didn't read the email.
The password was potentially logged to twitter's servers in plaintext.
They have no evidence anyone collected those passwords, but various employees could, in theory, have seen those logs.
Presumably those logs are now all deleted.
Even if you didn't reset your twitter password, it's very likely you'd be fine since it's not "leaked" (to the wider internet), but could have been seen by some employees who, for fear of being fired, no doubt did not save it (and in all likelyhood didn't see it in the first place).
I trust Twitter’s story about the plain text logging but don’t trust their software engineers more than others.
https://blogs.msdn.microsoft.com/azuresecurity/2015/10/19/an...
Too bad if something like twitter happens your yubikey is probably useless after it would've prolly logged anything to their servers.
P.S.: it's possible to change passwords, but hardware keys need to be destroyed and changed. Also Yubikeys can also have bugs. https://www.yubico.com/2017/10/infineon-rsa-key-generation-i... So basically it's not more secure. even worse the more code you throw at a problem the more likely it is to be unsecure.
most engineers have trouble implementing simple logins with password. do you really think that having a complex system will be better?
No, this is also incorrect. That's not how public key cryptography works.
>your hardware is useless if key generation is too weak
This is true, which is why you choose an authenticator vendor that's widely trusted to make high quality hardware. If you don't trust Yubico, there are competitors.
>the protocol is so complex that chances are high that even implementations can contain bugs
This is only partly true - most of the complexity is in the browser and authenticator layers, and are implemented by cryptography experts in the browser teams and authenticator manufacturers. Almost all of the server layer complexity can be encapsulated in reusable open source libraries - app developers will only have to implement their business logic on top of it, just like they have to do for password authentication too.
>do you really think that having a complex system will be better?
It will eliminate the problems with phishing and password reuse. That is definitely better in my book.
Like krupan also points out, this is flat out incorrect. The FIDO2 protocols are designed so that such a failure case is not possible, for two reasons. First, no secrets are shared - the server only sees _public_ keys and signatures. Second, a different public key is generated for each website - there is no globally correlatable identity.
Web Authentication supports this with what's called "platform authenticators" - some kind of TPM/secure enclave etc. built into the computer (most likely a laptop/phone), possibly integrated with a fingerprint scanner. The expectation is that sites will let you register more than one credential (like many (most?) do for U2F), so you can have a keyring device for initial logins on new computers (or for logging in on a friend's computer) and then use a platform credential on each for most daily use. Intel's built-in U2F thing is something to this effect, and might be compatible.
It's also theoretically possible that a phone could expose its platform authenticator to other computers via Bluetooth/NFC/USB, but that's still hypothetical at this point.
I would love to have a hardware (or even phone-based) alternative to passwords, with no third-party and better privacy, but I feel like this solution only handles the happy path.
For an example of a happy-path-only system that makes me nervous, look at Google Authenticator. Recovery is made with backup codes, but they are also "resolved by each website" (https://security.stackexchange.com/questions/167563/where-to...), which often means no support at all. Not to mention having to create a new backup after creating a new account. I still use Google Authenticator myself, but I dread the day I lose my phone.
If the protocol doesn't handle recovery/authentication, the fallback is a trusted third party (e.g. email) or legal identity (e.g. scanned passport). Aside from being a huge hassle and creating a weak point, it weakens the user's privacy.
99% of the websites (I have accounts on) rely on my email for recovery and revocation. But my inbox is not an impenetrable fortress, it's a communication channel; every device I own has access to it, and could be used as a backdoor to my entire digital life.
Then there's the risk of the third-party (Google banning me, being hacked, subpoena'd, etc), the privacy factor (see the Ashley Madison leaks), the often custom code implemented by each website...
and this sucks. Why can't I use my google account with my tablet without it automatically getting access to gmail sync?
Gandi doesn't even have a non-human method of recovery.
I use KeePassXC, and always add the Google auth code to both my phone and KeePassXC, and I back up my password DB (got burned big time there once....).
But yeah, your point is valid. As a tech savvy guy who thinks about this stuff, it's a pain but works. But for most people manually managing and backing up multitudes of keys, passwords, and login data is just so ridiculous a thing to ask that I can't believe it's 2018 and we haven't solved this yet. There must be a better way!
Emphasis added. Device needs to be paired with Company's AD first.
I also imagine that there are options for making e.g. the device unlock only require yubikey, but login to SSO require 2nd factor.
In this context, it would be reasonable to have the Yubikey require a PIN entry from the computer. You could use the same PIN for all sites because it stays local; the relying party never handles it, only the Yubikey.
FIDO2 adds more options to the login process:
Single Factor: This only requires possession of the security Key to log in, allowing for a passwordless tap-and-go experience.
Second-Factor: In a two-factor authentication scenario, such as the current Google and Facebook FIDO U2F implementations, the Security Key by Yubico is used as a strong second factor along with a username and password.
Multi-Factor: This allows the use of the Security Key by Yubico with an additional factor such as a PIN (instead of a password), to meet the high-assurance requirements of operations like financial transactions, or submitting a prescription.
It's an option, not a requirement.
Friends or family can't read your mind, but they can steal your physical key.
People putting pins on their phones or password on their laptop are not afraid of being pirated. This is a vague, abstract threat to them. Becoming part of a botnet is really not important to them, and they getting their credit card stolen from the web is really not credible enough for non tech saavy user.
What they are afraid of is other people looking at their stuff. Internet history. Pictures. Their clear text personal document.
Beside, a key is annoying. Where do you think they will store it when they travel ? In the same bag than the laptop. So you steal the bag, you steal the password.
Not only infeasible - physically impossible, in fact (barring quantum computers). Just 128 bits of entropy would take 1e16 (10 quadrillion) years to brute force at 1e15 attempts per second. :)
And of course you need a duplucate for the key.
Your example of people leaving the key with the laptop is a good example of one of the potential flaws, but just like if your credit card gets lost or stolen, you report it and it becomes unusable.
I agree that there is room for 2FA, but this is also surely preferable to the current system.
This is a false equivalence because knowing someone's credit card data only allows you to do one thing which happens to be pretty detectable: using their credit card for yourself.
Knowing someone's password allows you to know one or more of their secrets, including many applications that are virtually untraceable for the average user. So the deterrence factor is much lower in the second example making it much more likely that a nosy parent / sibling / SO will take a person's key.
There's no reason that using a password/key can't be just as detectable as using a credit card.
Also trying to trace logins application side is rather foolish IMHO, this should always be done at the authority that is granting the authorization.
That's not my point. The status quo is that people get alerted if something uses their credit card inadvertently and don't have similar alerts for uses of their password other than in a handful of situations like Gmail logins.
It's definitely not impossible for people to keep tabs on their logins, but this isn't how the Average Joe operates.
Plus, there's also the obvious solution for potentially stolen and misused keys .. just add a PIN.
This is a big part of why you always want one of your factors to be something you know.
[1] https://en.wikipedia.org/wiki/Fifth_Amendment_to_the_United_...
For example if you have good physical security and limit passwordless login to physically secure machines via AD computer groups, this may protect you from remote attackers.
If however organizations allow the use of this over the internet from "any" endpoint then this completely replaces a password 1:1 and theft/loss of the Yubikey could be a major problem.
This could also be used only on a single layer of your security. For example passwordless VPN authentication but then a password/2F is required for actual user login.
That's completely outside the scope of what I was describing. You've taken my words out of context.
Also if it's at least approximately to password security this is very welcome options. Most services I use I just want access easily.
If you go from MFA to fido2, maybe. If you go from single-factor password, to single-factor fido2 - it's likely security will improve. A lot.
> Depending on whenever hardware key is more or less secure than the password
It is:
A password can be sniffed, filmed, inferred from sound recording.
You don't know when someone knows your password; a key will be missing (or copied, but that's supposed to be Very Difficult (tm)).
A password is unlikely to encode as much entropy; certainly any password/phrase you actually type in. 128+ bits of entropy is surprisingly hard to encode in a manageable size (it's 16 completely random binary bytes).
Now, if the assumption is that the alternative is a ssh key locked on a device, additionally protected by a pin... Maybe The fido2 is slightly less secure.
But if you try and list the failure modes / do some threat modelling ; I think you'll see it ends up a close race.
It would certainly pair well with "something you know" - eg a pin/password with somehow proper rate-limiting.
"We recently identified a bug that stored passwords unmasked in an internal log."
Because all they will have is a public key, not your secret password.
If your password is leaked, your username/email has probably been leaked as well.
If your hardware key is lost, assuming it wasn't stolen by someone who has specifically been trying to get your credentials, then there's nothing to tie it to you. You're still going to get a new key and change the locks, but you know it happened.
Maybe the introduction of FIDO2 will spark some interest in that again? https://bugzilla.mindrot.org/show_bug.cgi?id=2319
Yes, sure, you could use pam-u2f, but that will never be as seamless as having it supported upstream in ssh.
Or you could use the OTP mode instead, but that has other disadvantages (you have to depend on yubico's servers or run your own KSM+validation servers).
This also goes well beyond just Facebook and Google and if you use it to lock a physical device like a phone or a laptop that isn't something Google or Facebook would be able to help law enforcement with.
Also while I don't want to make a statement or start a debate on the level of compliance and attitude that Google and the rest have towards search warrants (because it's not relevant and I don't have sufficient knowledge to actually form an informed opinion on the matter). Google and Facebook's legal departments have more funding than most state attorneys yet alone local DA's if they want to fight on your behalf (or on the behalf of their business model) in court they would be able to do so much more effectively than you ever could.
Google and Facebook also require a full and lengthy process with FIDO tokens they can do it on the spot, heck they are legally able to do so if you either agree to a search or law enforcement has an alternative sufficient basis to invoke a lawful warrantless search:
https://en.wikipedia.org/wiki/Warrantless_searches_in_the_Un...
TLDR; Officer: May I search your vehicle You: Yes
At that point they are legally are allowed to take the FIDO token from your keychain and unlock your laptop.
Specifically, I have one use case computer where I have no screen, and getting through Windows login without it can be troublesome. I'd love to use this key to unlock it instead, but it's an offline machine.
I had this plan with Yubikey for Windows Hello, which has been out a while, and I bought a Yubikey, and discovered it could only unlock my Windows machine if it was locked (not logged out), which defeated the purpose entirely.
And second thing - is exposing connector safe against mechanical damage? Will it withstand constantly being scratched by keys?
https://www.yubico.com/product/yubikey-4-series/#yubikey-4-n...
I still wonder about the exposed connector - what its durability. After all, I would like for such a tool to serve me for years fault-free.
> but I assume it lacks the "touch" protection against remote attacks
It has the touch protection. There is a small strip of metal that protrudes beyond the USB port that you touch.
> what its durability
I've used it daily for about a year. Granted this is not "years" but so far it still feels very solid.
I have two of this form factor on my keyring, one of which is a couple years old now. Neither show appreciable signs of wear on their connectors beyond what you'd expect from regular insertion. They feel pretty robust, though I've never actually tried to break one...
EDIT: minor clarification
They're pretty sturdy. Of course if you take some pliers to them I have no doubt that you'll be able to break them in half but for normal use you won't have a problem IMO. The size doesn't bother me either, it's like a very flat USB key.
I also have a nitrokey that's a bit shorter and bulkier and it comes with a cap which might be better to protect the connector, but on the other hand I'm sure I'd lose it sooner or later. A retractable port or something similar would probably be a better idea. Also the nitrokey is significantly slower which is the main reason I only have it as a backup for my yubikey currently.
Lost my YubiKey around the start of the year and couldn't understand how it could have disappeared so I deregistered it everywhere and went back to Google Authenticator. Found it today [July] embedded in my gravel driveway where it must have been since January and been stepped on/run over since then. Popped it into the computer mostly for fun, and it works like a charm. :P Hardy stuff! :)
But hopefully U2F will actually work in non-Chrome browsers in the near future.
Works fine for me.
I would guess you're referring to being able to log in to gmail (or anything in G Suite) with U2F from Firefox.
U2F is already available in the most recent version. See "security.webauth.*" keys in about:config. It just won't work with Google, at least not yet. Google's implementation predates webauth by a pretty fair margin, and from what I have learned, is different in small but important ways from the standard.
So we have a situation that drips irony: we have a U2F standard, usable via a standard authentication mechanism - and incompatible with the very web property that drove the concerted push for the technology's adoption.
It seems like a chicken and egg problem. There's very little incentive to improve it because practically no one uses it. And no one uses it because it's a bad user experience.
But I would prefer it over using a Yubikey because, IMO, the private key should be associated with a machine, rather than a person. That is, if one of my devices is stolen or compromised, I can use another one of my devices to revoke the stolen/compromised device's access.
> FIDO2 is built on the same security and privacy features of FIDO U2F: strong public key cryptography, no drivers or client software and one key for unlimited account access with no shared secrets.
They should've kept all the Microsoft stuff out of the post, other than just mentioning that they've been working on the spec together. The Azure stuff seems to have confused everyone about how this actually works.
There are also other app-based ways to login to websites with public key crypto, such as https://www.grc.com/sqrl/sqrl.htm, or https://www.civic.com/. But of course they are less secure than the hardware/Yubikey version, for the same reason Yubikey U2F tokens are more secure than Google Authenticator for 2FA (well, unless companies act stupid and enable "SMS backup" alongside Yubikey support, in which case it's even less secure than Google Auth-only as an option).
[1]: https://github.com/w3c/webauthn/graphs/contributors
[2]: https://www.w3.org/blog/webauthn/2018/01/11/meeting-minutes-...
EDIT: add forgotten link
Even if you contrast it against something like e.g. LastPass or Keepass, you're still missing a ton of infrastructure.
If anyone is considering adopting Yubikeys in their organization using a language that is not supported by one of their client libraries my email is in my profile and I would glad to help out to the best of my ability.
When using it even for login, people connect it to their laptops - that's what most people work with after all - and they must make sure they don't forget it there. As well they need to worry nobody steals it, whether it's on your laptop or you become a theft victim on the street. In the latter case the thieves might know what a Yubikey is and ask you for the pin.
Not sure what problem this solves. But I have the impression we're converting a virtual problem into a physical problem. To be honest I prefer to save keys on laptop drives, that's more difficult to steal, especially when using an encrypted disk.
P.S. Obviously, no. Neither Nitrokey [0] supports it, nor it's a sturdy one!
[0]: https://www.yubico.com/product/yubikey-4-series/#yubikey-4c
I work primarily in a Windows shop, and I got the other co-workers in Linux because PAM supports seamless multi-factor auth. I would have went Windows, but its too obfuscated or hard to do that.
LinOTP works very well. And LinOTP works with a wide variety of tokens. Don't be locked to a single vendor.
FWIW, that's not strictly true. See: https://msdn.microsoft.com/en-us/library/windows/desktop/mt1...
I don't have enough experience to comment one way or the other about its difficulty.
In the environment I work in, I'm not able to use services outside a very limited list, or I have to roll my own using established technologies (FedRAMP). So Azure is right out. So was using Amazon Directory Services.
I know my colleagues are much more familiar with Windows, whereas I.. (look at username, relevant!). My solution, after assessing that Windows couldn't do 2 (or 3) factor, and it was stuck at login/password and some firewall blocking IP's, I knew what I had to do. And that meant Linux for the bastions, and LinOTP and appropriate config options to make it work.
I was kind, and didn't inflict a AAA stack of "kerb, ldap, radius, and shib" on the Windows admins :) Well, that and I didn't want to be the sole maintainer of that system.
Well, because in the Windows world, switching in/out authentication subsystems is a arduous task surmountable by primarily Microsoft.
And what would that be good for? Well, simply put would be a nice addition to a Windows Terminal Server. Turn a Windows TS into a proper bastion that requires 2fa. Us Linux admins have that with PAM. Sure would be nice to do the same for Windows. But right now, Windows is grossly deficient.
I like Linux better too.
[0] https://en.wikipedia.org/wiki/Graphical_identification_and_a...
And I hope that this might trigger more widespread support for U2F and similar mechanisms in browsers and websites.
https://aprilmacdonald.com/two-factor-ssh-authentication-wit...
I actually use a Yubikey for SSH in a different way: with gpg-agent. E.g. https://blog.habets.se/2013/02/GPG-and-SSH-with-Yubikey-NEO....
And if you are on OpenBSD, there's login_yubikey [0] (although it uses OTP instead of U2F).
Having something like this combined with the something you know (passphrase) would be real closer security. Now anyone with your token can access everything that key gets access to, without you needing to be there, or sharing a passphrase. That's less secure imho.
Microsoft could have team up with Logitech like Sony with Erricson, and come up with a standard and put (mildly cheap) finger print reader on each sold keyboard and popularize open source standard for software implementation.
I guess this is slightly easier than typing your email address? But it's not a security feature.
The FIDO/U2F design is a cryptographic key enshrined as a physical key, so rather than "I'm joering2" it says: "I can prove I'm this particular key talking to your site again using mathematics".
Which key? No way to know, but it's the same one as before. Google can't use the credentials it presents to them to get into Facebook and vice versa, the proof from yesterday is worthless today and so on.
Also, you can't revoke fingerprints when they're compromised more than 10 times (20 if you're willing to use your toes too).
Though I'd like to add that FIDO2 does support fingerprints and other biometrics as an additional authentication factor - it all goes under the same abstract "user verification" umbrella as PIN does. The important distinction is that the PIN or fingerprint is never shared with the server - it's only used to unlock the private key - so it's much more difficult to steal.
- CTAP2 supports "user verification", such as PIN or biometric authentication locally on the hardware key. This enables using the key as both 1st and 2nd factor without need for a server-side password.
- CTAP2 supports storing the private key along with some metadata on the device, whereas U2F instead encrypts the private key and stores the ciphertext on the server. While the encryption approach allows for simpler hardware and an unlimited number of registrations, the local storage approach allows login without even having to type (or even have) a username. CTAP2 supports both.
- CTAP2 has an extensions framework in which an authentication vendor and server can cooperate to implement custom features without the browser having to understand them.
- CTAP2 - or at least the companion web API, Web Authentication - is compatible with more existing TPMs and such hardware. For example, it's theoretically possible that some Android phones could receive software upgrades that turn their fingerprint sensors into WebAuthn authenticators.