- I'd otherwise like to use it as a GPG card, but it's unclear if NFC-only GPG cards work with desktop gnupg. Maybe they do and I'm just missing the documentation for it.
then it would work just fine, you just need a proper contactless PC/SC reader. I don't have this ring, but I did use a smartcard with the applet to login to a server via the phone with
How does gnupg interact with contactless cards? I know for a contact smartcard if I try to perform an operation with the card not present, I get a prompt to insert the card, and then I get a prompt to enter the PIN when inserting the card and continuing. A contactless card in a ring form-factor is unlikely to be on the reader for long, though... is gnupg aware of contactless readers and will it e.g. ask for your PIN without the card being present and then prompt you to tap the card?
I'm aware that's what Android apps like OpenKeychain do, but I haven't been able to find much information on how gnupg/pinentry/etc behave with contactless cards.
If you have experience with contact cards, then it's all the same as far as end applications are concerned, it's abstracted away.
> is gnupg aware of contactless readers and will it e.g. ask for your PIN without the card being present and then prompt you to tap the card?
No, it will behave as if there's no card/ring if you don't have it around the reader. Software polish is a weak point, e.g things like `ssh-add -s /usr/lib/opensc-pkcs11.so` can be used to 'cache' the PIN for a session as far as `ssh -A` connection is concerned, but that's not exactly the height of usability.
Ahh, interesting. I suppose then testing when it’s possible to insert/remove a contact card without disruption would give me a good idea of what to expect from a contactless card.
Thanks for the info!
EDIT: It seems like requesting a decryption, removing/inserting a Yubikey while the pinentry screen is up, then entering the PIN does not work. I suppose I've broken the session then. So I'm guessing to use a ring form-factor card, I'd have to keep the ring above the reader during the whole operation, which means I'd have to remove it to place on the reader and can't just keep it on/tap when needed.
Hm. That's a bit unfortunate.
(Also possible the Yubikey behaves differently as it's both reader and card in one... I don't have a dedicated reader set up to test with at the moment.)
EDIT 2: For anyone who comes across this later: no, a dedicated reader behaves the same way; once the pinentry prompt is open, you can't remove the card and reinsert without invalidating that request.
but paused for thought after reading the terms and conditions (it's a PrePay Visa account) and finding this gem:
"Your McLEAR Product(s) will be valid for 24 months from date of registration, after which your Product(s) will no longer be able to make contactless payments or have any funds available into your Account."
and less severe but annoying opt-out not opt-in:
"You can tell us if you don’t want to receive any marketing materials from us in accordance with the GDPR 2018, by emailing dpo@mclear.com."
I just assumed, but I think you're right that it doesn't. (Though I wouldn't be surprised if it followed, Yubikey's first FIDO key was also just that, but now they all do it.)
My main point though was that it's not a device-specific authentication, or even an external reader for unlocking a secret provisioned onto one or many devices, it is the sole thing needed, so you can walk up to a new device and use it without provisioning it with secrets.
An OpenPGP one would be cool though - replace passphrase with fingerprint.
If they're releasing a fingerprint-scanning version, I'd be surprised if it wasn't available with all the capabilities of the YubiKey 5 (which has OpenPGP support) for people willing to pay.
this is a "roaming authenticator", meaning it is meant to be used across devices. After enrolling it, it may be stored away safely, e.g. in a safe, or used on other devices to log in (or perform crypto operations) with the same credentials.
Does it worth repeating that "fingerprints are usernames, not passwords"?
It is straightforward to copy someone's fingerprint. If technology does not include some additional biometric property (blood vessel arrangement, unique capacitance?!, unique heat signature that will not change over time?! ...) that is hard to obtain, it is pretty much useless, especially if someone is really keen to hack you ...
I’ve always found it helpful to think of two computers.
One of them is beige and from the 1990s. It has a keyboard and screen into which you type in your regular username and password. It is the computer that you actually use to get things done.
That computer is behind another fancier one though. The fancy one has a fingerprint reader and a robot arm. It reads your fingerprint (possibly incorrectly) and turns it into a password (also, potentially with inaccuracies.) The password might literally be “thumb with two loops that are 2034 pixels apart”.
The robot arm on the fancy computer then types the generated password into the 1990s computer. If anyone sees the password being typed, you’re out of luck. You can’t change your fingerprint to something different. There are no other inputs to the fancy machine. You’ll just have to use another finger.
You certainly wouldn’t be able to generate a meaningful username with the fancy computer. (Which is a finer point than simply fingerprints = usernames.)
What’s different with the Yubikey is that it’s trusted portable and tamper proof. It’s considerably harder for an attacker to intercept my fingerprint on the fancy computer with the fingerprint and robot arm if it’s either stuck in a USB port or in my pocket on my key chain.
Just getting the fingerprint of someone else does not allow you to log in as them. The fingerprint is only used as a presence check by the security key, which digitally signs a challenge using its own internal non-exportable key material. So you would have to both steal someone else's security key (note you cannot "clone" it, at least not trivially), and also get their fingerprint, if you wanted to "hack" them.
So, device is password generator, and fingerprint is the username.
What happens when you lose or brake your security key, is your PC locked forever, or it will stay that way until they send you replacement?
But if they can send you replacement, that means that "the company" (read government services) have sort off master key for your PC (they have fingerprint database) and they can get access to inside hardware depending on deal they have with technology maker (I am thinking China)...
I had a chat with a spokesman from a bank they had similar technology for a credit card, basically what he said is that key factor is time.
That is, if someone steal your card in bar and takes fingerprint from a glass you were drinking, only things that will protect you is time you will notice that your card is missing and reporting it to the bank. As person hacking will need a bit of time to replicate fingerprint. Which is about between 15 - 30 min with proper tools...
> What happens when you lose or brake your security key, is your PC locked forever, or it will stay that way until they send you replacement?
You register two security keys (which both have a separate private key) and keep one of them somewhere safe. Then if your main one breaks you switch to key 2 to login and register key 3 as your new backup key.
This is done for e.g. Google's advanced protection program [1]
> I had a chat with a spokesman from a bank they had similar technology for a credit card, basically what he said is that key factor is time
Yeah, that sounds about right for a bank which will have a much different threat model than a login for a website or my computer.
> But if they can send you replacement, that means that "the company" (read government services) have sort off master key for your PC (they have fingerprint database)
They very likely can't. These devices essentially generate a private key that is never able to leave the security key without major hardware attacks. The fingerprint is also just stored on the device to be able to unlock this secret key. It is never transmitted to the computer or anywhere else and it also isn't used to create the private key.
Essentially this key implements WebAuthn [2] (and similar technologies) and only allows access to the secret key after the fingerprint has been verified.
There could of course be backdoors in the key generation algorithm (think dual ec drbg). Once your threat model includes actors capable of backdooring modern encryption hardware and algorithms they probably have much easier ways of getting to your data though.
> What happens when you lose or brake your security key, is your PC locked forever
Not sure about macOS, but on Windows it would most likely use Windows Hello, even though they didn't mention it once in that blogpost. It doesn't allow you to have biometrics as the only method of logging in. You would have to setup a PIN too and the usual password will always be available. On Linux anything goes, depends on how you set it up.
All that FIDO2 stuff is for browsers mainly, unless MS would meet them in the middle and allow FIDO2 without AD for system logins in upcoming updates.
> If technology does not include some additional biometric property (blood vessel arrangement, unique capacitance?!, unique heat signature that will not change over time?! ...)
The fingerprint technology which is used appears to be from http://fingerprints.com/ . It means the tech is based on an "image" from capacitance, not optics. It also has what is called "liveness" detection - it will be able to differentiate between a dead object and a finger which is alive. So it would not even be enough to cut the finger off.
> Does it worth repeating that "fingerprints are usernames, not passwords"?
No, because that is nonsense. Fingerprints are something different to both usernames and passwords. They aren't the same as either of them. For example you can change both passwords and usernames but you can't change a fingerprint. Also fingerprints are more difficult to discover than usernames.
> No, because that is nonsense. Fingerprints are something different to both usernames and passwords.
In The Netherlands you can be forced to give your fingerprint to unlock your smartphone. You cannot be forced to unlock your smartphone via PIN, or share your password.
> For example you can change both passwords and usernames but you can't change a fingerprint.
Yes, you can. Your fingerprint can be unreadable under circumstances. With sandpaper you can remove it. Certain (physical) labour can damage it. Both of these are temporary. You also, supposedly, have 10 fingers, so in that regard you can switch (e.g. use a less common one, or one which isn't temporarily damaged). Other day I accidentally used a razor to damage my index finger, used an adhesive bandage, and had to add a different finger to my smartphone. I wonder if you can use your toe.
> Also fingerprints are more difficult to discover than usernames.
Inaccurate, and untrue. They're all over the place. This is Bob's phone. I wonder where Bob's fingerprint might be. Might it be... on the phone? "Oh, what a surprise, I didn't expect that!", the forensic analyst exclaimed.
I would argue the following: a PIN or fingerprint should not be used to protect serious data. One could, for example, perfectly fine use a PIN on their smartphone, for authorization of unimportant data. OSes are not yet able to make this distinction though. Moreover, any time you use a password in a public place which isn't one time, a camera can copy the data.
Slight tangent: other day I heard about a creep who stood on the bottom of a stairs, to make pictures below skirts of women. These pictures were then distributed between other creeps. I immediately imagined that being my daughter, and that thought scares the shit out of me. Given the advancements of things like cameras we need to think different with regards to security and privacy.
> In The Netherlands you can be forced to give your fingerprint to unlock your smartphone. You cannot be forced to unlock your smartphone via PIN, or share your password.
Ok that's why I said fingerprints are different to passwords?
> Your fingerprint can be unreadable under circumstances. With sandpaper you can remove it.
Please don't nitpick. You don't really think I didn't know that.
> Inaccurate, and untrue. They're all over the place.
Your username is `Fnoord`. How can I get your fingerprint just as easily? I did not say it is very difficult to get someone's fingerprint if you want, just that it is harder than getting a username. You can just ask people for their usernames, people will usually give them out to strangers. Try that with fingerprints.
In fact, if it is just as easy to get a username as a fingerprint, here's my username: IshKebab. Now can you find my fingerprint?
At least for the USB-A versions, the flexing is almost by design. Since it doesn't have the full housing around the USB-A connector, it tends to have a bit of motion in the port. Its not even that the device is flexing, its pushing on the pins on the USB port more or less as it moves. I can't speak for the USB-C version, as I don't have one and I don't suppose it has that same thing going on.
With Yubico I always get a feeling that if they could breakaway from all this legacy smartcard stuff and lock everyone in, they would. But they can't yet, so they distanced themselves from it and were keeping it on the down-low ever since.
I would really like if they made a wearable without any ports like a NFC ring, but that would mean either keeping it tied to phones only with an app or selling their own NFC/contactless reader, most likely with some proprietary bent.
I really like Yubico and fingerpring scanner is an awesome idea, would be really happy to bring my fingerprint instead of relying on laptops. On the other hand, a wearable would be a whole new level, like thinking 2 steps ahead
I could see Yubikey going to a NFC ring at some point. For PCs all they would have to offer is a USB NFC transceiver.
There are probably still some engineering challenges getting all the cryptographic functions and NFC power transfer into the form factor, but it seems like those will get easier over time.
If you have a macbook with touchId you can use that as webauthn/u2f already with softu2f, I've been doing this for some time and it's really smooth, much prefer it to OTP.
In terms of system login stuff (at least on Windows and macOS) I think it would work exactly the same as any other supported 3rd party fingerprint sensor.
I'm wondering if people know that Android phones already provide the FIDO2 / WebAuthn authentication. There is no need for additional hardware for mobile use.
What happens if I lose the key, I don't have it on me, or if I'm using a mobile UI? It seems like you need an identifier (email/username/etc) besides the hardware key for this to be practical.
FIDO2 supports password-less and username-less authentication, both as a single factor, i.e. no passwords.
Password-less is like 2FA but without the first factor. You type in your username, next you use the security key.
Username-less is done via resident keys, that can also store the username at registration. The whole experience is just authenticating with the security key.
If you use FIDO without a password (not as 2FA, but as single factor), you want to enable client-side protection like a PIN or biometric. These keys are introducing the biometric option so you can just tap, without entering a PIN.
Edit: oh, this works already today, you can test it on Microsoft accounts, e.g. outlook.com
If you have two, say, Microsoft accounts, can you use the same FIDO2-capable authenticator for both, and can Microsoft correlate the accounts by authenticator? I know keys are unique per-site, but are they per-account?
edit: The spec[1] is vague on this, but it looked like a Relying Party can't correlate accounts directly via some kind of identifier for the authenticator. It looks like individual key pairs are generated on the authenticator for each account and linked to the unique userEntity.ID given by the Relying Party. However, Mozilla warns you [2] when sites ask for additional information about your authenticator. I tested this with Yubico's demo [3]. Unfortunately, it looks like the field attestationObject.attStmt.x5c identifies the authenticator. Firefox prompts you when sites ask for the extended information and removes this field if you check a box. That's nice, I guess, but it still seems not so great. If you were to forget and use a user agent that didn't prompt you to anonymize this, the Relying Party would get the attStmt in the response and theoretically could store and correlate accounts. Interested to hear more about the reasoning behind this.
edit 2: It looks like this field is necessary as a second factor when using passwordless login? On Yubico's playground [4], checking "Enable passwordless login with this key" and then checking Firefox's "Anonymize anyway" box results in no request made to the key. Without enabling passwordless login, the request still works after anonymizing.
To be honest, it seems like sites should allow passwordless login without the x5c field. I don't see how an attacker couldn't come up with the x5c field if they could crack the key pair. Is my reasoning right here?
You have to distinguish between resident keys and non-resident keys (that I'll just call "normal keys").
Resident keys are stored on the device, so today you can only have a limited number of RKs. This said it's a temp limitation. As usage will increase, devices will allow for more RKs. For example, if I'm not wrong, yubikeys support 25 RKs, solokeys 50. (But the only sites where you can use RKs are basically Microsoft or demos.)
For each account on a given site, you'll have an independent RK. (I don't believe you can have 2 RKs for the same account on the same device, but that's an implementation detail.)
Normal keys, instead, are generated on the fly. They are not stored, so a single device can support unlimited sites and accounts. When you enroll a device in, say, your primary Google account, trying to enroll the same device again produces the same cryptographic key. So, in fact, for each account you can only have one key per device. But you can have unlimited accounts times unlimited sites on a single device.
If you have 2 accounts on the same site on the same device, you're correct in saying that the site can't link the 2 accounts to the same device. In addition, on the device there's nothing stored, so even someone with access to the device (say, border control) can't see what sites you used the device with. Important: this is only for non-resident keys.
I can't predict the future, but my expectation is that we'll see adoption of RKs for username-less login, and non-RKs for 2FA. I personally don't particularly like RKs for privacy reasons, but the specs seem to prefer them (and the UX seems much better). See also this: https://twitter.com/0x0ece/status/1160627435668480000
> When you enroll a device in, say, your primary Google account, trying to enroll the same device again produces the same cryptographic key.
That's not correct. The keys are random so of course there would be statistically no chance to get the same one.
However, if you actually try to do this it simply doesn't work, it says you already enrolled this authenticator, which is true. How does it know? During enrollment the site presents a list of identifiers it already knows for your account, and your browser shows this list to all your authenticators, they won't re-enroll if they recognise an identifier as their own.
This delivers a nice UX. If you have several authenticators you don't need to unplug ones that were already enrolled to enroll more. Likewise you don't need to unplug the ones that don't know, say, Facebook credentials, to log into Facebook, the browser will see OK, this authenticator can't help me, let's try the others.
If you own the backend (I have a test system for this) you can just not provide that list of existing identifiers and if you do that the authenticator will cheerfully generate a fresh key pair (different from the first one) and complete enrolment again for the new key pair. A real site should never do that.
side topic:
could you elaborate how FIDO1 (not FIDO2) yubikeys do 'ykman fido reset' ?
my question is (in domain of U2F/FIDO1 and non resident keys), what exactly is resetted, and if RP (websites) will provide the same initial data on enrollment, will the second enrollment end in the same keys EVEN after reset? If not, what exactly is storred and resetted on yubikey (again, OLD ones with only U2F)
I have never used 'ykman fido reset' and didn't implement it. However the obvious way to implement this, which I'd guess is what Yubico did, is very simple:
Randomize the secret key that makes your authenticator unique.
Doing this has a similar effect (cryptographically at least, it's not going to magically remove initials painted on with nail polish or something) to replacing the authenticator with a different one from the same batch.
The thing that makes the simplest possible FIDO authenticator work is a single secret symmetric key known to nobody and used only one that one specific authenticator, 256-bit AES would do, we'll call the key K.
The exact details will be proprietary, obviously there are opportunities to add features/ cost reduce the product, but basically:
When it is asked to enroll somewhere the authenticator generates a completely random elliptic curve key pair, then it signs a blob with the private key from that pair, encrypts the private key using K in AEAD mode and hands over the signed blob, the public key and the encrypted private key which it says is just a neutral opaque identifier, looks random, could be anything.
A relying party (remote web site) stores the public key, the opaque identifier (remember that's actually the private key encrypted) and some way to relate these to its existing user database.
When you use U2F or WebAuthn's second factor mode to sign in, the relying party hands back that opaque identifier. Your authenticator takes the opaque identifier and tries to decrypt it with K. AEAD mode means it'll be able to verify it minted this identifier with K and if so, get back that private key. So now it can sign a blob with the private key and prove you are still in possession of the authenticator which was enrolled.
If possible can you point out resident keys in the spec? This is confusing.
> For each account on a given site, you'll have an independent RK.
Is this only for usernameless sites? Sites with usernames can just use normal keys, right?
> (But the only sites where you can use RKs are basically Microsoft or demos.)
How do sites request to use RK’s? Why would Microsoft request RK’s when they can use the associated email address as a unique username?
Also, I can’t find anything about hardware security keys on my Microsoft account page, much less usernameless authentication.
If there’s multiple usernameless accounts per site how does the user select which RK to use? This seems impossible. If it is in fact impossible, then only one RK per authenticator would be necessary and only one usernameless account per site per authenticator could be used.
The WebAuthn specification calls this a "Client-side-resident Public Key Credential Source" or "Resident Credential" for short.
> Is this only for usernameless sites?
It facilitates the "usernameless" flow yes, since the Resident Credential includes everything needed for the authenticator to claim you are some particular user and prove it. But it will still work for other flows.
> How do sites request to use RK’s?
Set the residentKey parameter to "required" during enrollment. Enrolling an authenticator that can't do Resident Credentials should fail in this case.
Sites which want a second factor only should pick "discouraged" which allows the authenticator to remember all the credentials if it wants to (e.g. an iPhone has gigabytes of secure Flash storage so why not) but discourages doing so.
> If there’s multiple usernameless accounts per site how does the user select which RK to use?
Potentially the authenticator has its own UI. But the CTAP2 protocol allows the host to build a UI by asking for all the valid credentials for some particular relying party (ie web site). It goes something like this:
* Host PC-> Security Key "Do you know credentials for ycombinator.com ? We're doing the usernameless thing, so I have no hints just asking"
* Security Key "Yes, here is proof I'm user 48B4C9CDA2 aka hpfr, also, I can prove 6 identities on ycombinator.com including that one"
* Host PC "OK, what's the next identity?"
* Security Key "Here is proof I'm user A29EE0F103 aka tialaramex"
(and so on, iterating through the identities quickly)
Yes, all normal sites should allow you to use WebAuthn without attestation and should default to switching it off. Apple's guidelines recommend enabling it, but that's bad advice.
Attestation only makes sense if you'd actually reject authenticators you don't trust, which might make sense if you're the Foo Corp. Corporate System and you only trust genuine Important Security Inc. authenticators because you issued one to every employee and so that's another safeguard against attack (it prevents employees sidestepping security like those webcams showing an OTP key output). But for a public site and especially if you actually offer other less secure alternatives (like SMS or TOTP) it makes no sense to even ask what type of authenticator I'm using. I always tell Firefox to refuse to answer.
However, the attestation certificate in that x5c field isn't a unique identifier. So basically Microsoft learns that these two users have bought the same brand and maybe (if that brand sells enough volume to make it worth changing out the EPROM or whatever in batches) the same batch, but it's supposed to be at least 10 000 different authenticators sharing "your" attestation.
If you're using it as a resident key (username+password) then what happens if you lose that key? How can I recover my account? I don't even know my username or my password. That seems like an oversight in the spec.
I currently use a yubikey for as much as I can, so here is what I have:
1) My yubikey has NFC and works fine with my phone. Even that webauthn website demo works in a mobile browser via NFC.
2) For TOTP secrets, I enroll them in both my yubikey and in the Aegis android app. I mainly use these with the Yubico Authenticator software for windows or linux, but I can pull out my phone if I need to.
3) For any account that is using U2F, I have a second backup key (the blue security key) that I also enroll for that account.
U2F is freaking awesome. It's rare to have something which is both high security and not a pain to use.
I just wish the banking and financial industry would get onboard. For customer accounts, they are mostly using SMS, but some of them are still using personal info question (e.g. what was your first pets name) as a second factor which is horrible.
While this is true, the spirit of the GP is correct. To login you will need both a username/password and the second factor. So losing the key is still relevant.
In practice that means people really need to buy (at least) two yubikeys to register with services that allow it. Have one on something that’s always with you (such as keys) and the extra(s) as a backup somewhere secure. Unfortunately this works with most accounts except the big one I want it to... AWS.
Some sites allow you to also register a standard MFA device as a fallback, and further still Google (as an example) allows you to use another device that’s already authenticated to get a one time use code (depending on your account security setup).
To sidestep this, create a new AWS account to be your master SSO administration account (separate from whatever account you're already using), and enable "AWS Organizations" in it. Join the existing AWS accounts to the new "AWS Organization".
Once you enable AWS SSO for the "organization", you can then set up SAML SSO to your existing identity provider (e.g. G Suite, which allows multiple hardware 2FA tokens per user). You do this in the new master organization account.
You can create the corresponding users in AWS SSO, and grant them the appropriate permissions in the appropriate organization accounts.
Then you do the 2FA auth to your IdP (G Suite, or selfhosted, or whatever) and then AWS just trusts the auth from the IdP, and you get to sidestep the terrible morass that is AWS MFA configuration.
A true biometric key would allow authentication from any key and not just a registered key, otherwise it just degrades into a possession authentication factor. A true biometric key would allow you to walk around with absolutely nothing, and doing 2FA using only what you know (password) and what you are (your finger).
Is that possible with this? Could I e.g. pass 2FA on my accounts on a friend's computer using their key with my finger?
The problem is that your fingerprint is really just a set of information attached your body, similar to a long static password. Not very secure and you can't change it if it was compromised.
The fingerprint on the yubikey is really just a possession check for the yubikey in case it was stolen. The main protection comes from the asymmetric cryptography inside the yubikey.
> The fingerprint on the yubikey is really just a possession check for the yubikey in case it was stolen.
And one that only depends on the tamper-resistance of the hardware.
It's possible to use error correcting codes to extract deterministic secrets from fuzzy data like fingerprints, but no one (virtually no one?) implements that.
Instead, the fingerprinte reader has some cleartext fingerprint fingerprints that it compares the fingerprint to and just makes an accept/reject decision. Extract that data and you can make an acceptable input, or glitch the processing and you can just bypass it.
Presumably it's better than the button that literally any touch activates, but I think a conservative security analysis would pretty much just treat it like a button.
It is interesting to compare the security of a yubikey+pin vs yubikey+fingerprint. Both provide similar and really good security compared to popular authentication mechanisms like static password, sms, and even authenticator apps.
But a sophisticated attack could still use your credentials if the yubikey was stolen, and the attacker had your fingerprint (plausible with the OPM personal info leak) or had captured your pin (maybe from a keylogger installed on a compromised device you had used).
It seems like the most secure method (albeit impractical) would be to have a "what you know" challenge built into the yubikey, like a pin pad or dial. At that point though, one would probably have to worry about other attacks, like physical intrusion and kidnapping as well.
> It seems like the most secure method (albeit impractical) would be to have a "what you know" challenge built into the yubikey, like a pin pad or dial. At that point though, one would probably have to worry about other attacks, like physical intrusion and kidnapping as well.
This isn't uncommon for Bitcoin hardware wallets, fwiw.
But the problem is that the short what you know challenge isn't very secure if the edge device is compromised and can't impose rate limiting or maximum-try limits.
I think for auth I'd rather have yubi/fingerprint + password. Yes, the host could still the password, but even if the yubi is completely backdoored you still have a credible amount of security.
It would be better still if the fingerprint mechanism were cryptographic. But it's probably pretty hard to fit a lot of fancy code in such a small device, -- and security is something of a lemon market (see also zoom's "end to end").
I think people should be extremely wary of efforts to turn U2f devices into single factor authentication. If intelligence agencies haven't compromised yubico or at least developed a good program to substitute devices in the mail-- then they ought to be fired.
Personally I prefer just using multiple Yubikeys, one left permanently in each device, never carry one a loose key around, and if one is stolen, just deactivate that key from all services.
Having to carry a loose key around is a liability.
Scary - you would have to trust EVERY fingerprint reader not to capture your fingerprint AND you have to trust that you don't leave it anywhere for pickup. It's very hard to change your fingerprint as well, so having images of it out there is not good in general.
You'd have to trust their key in that case. Otherwise they could be collecting your biometrics for reuse later on. Between trusted friends - probably ok. Secure facility - probably also ok (we already share the fingerprint readers). For public use... I wouldn't touch that.
The primary purpose of a Yubikey is the physical possession of said device is a mandatory factor of authentication, I don't think adding biometric auth is a good excuse for reducing that factor considerably.
What does excite me? Smart rings like https://store.nfcring.com/products/omni