YubiKey Bio Series(yubico.com)
yubico.com
YubiKey Bio Series
https://www.yubico.com/blog/put-your-finger-on-the-pulse-of-whats-new-with-the-yubikey-bio-series/
139 comments
Your question implies that the yubikey is an HSM. It isn't. It has a secure element.
If you want to implement your own novel test of user presence, you could get an F-Secure USB armory device (https://www.f-secure.com/en/consulting/foundry/usb-armory) and tap into the GPIO.
If you want to implement your own novel test of user presence, you could get an F-Secure USB armory device (https://www.f-secure.com/en/consulting/foundry/usb-armory) and tap into the GPIO.
Yubico does, however, make an actual HSM.
https://www.yubico.com/products/hardware-security-module/
by name only. it is also not an HSM by commonly understood definition. epoxied chip isn't enough to declare HSM-ness
I was on a team that evaled it for FIPS compliance. It's a full, FIPS compliant, HSM. It's $650 but that's still on the low side for an HSM.
Trezor - I've been using one for years and it's great. Also you can backup/restore the seed (so you don't need to register multiple devices).
I just ran across this comment, and realized it also works with gpg. I really wish yubikeys supported this backup mechanism as well (given their size), but I'm very tempted to make the jump.
I haven’t used yubikeys in a while, and they never supported backups, but they did support key import for GPG when I used them — so you can make a key some other way, and then put it on as many yuvikeys as you care to.
Isn’t that enough for your use case?
Isn’t that enough for your use case?
That's actually the process I use right now. The problem is that it relies upon an old laptop and several usb keys for backup. It's much easier to backup 24 words on a sheet of paper than a full gpg key.
Plus, those 24 words can also recover your u2f keys, crypto wallets, etc. The 24 word backup is something crypto has gotten right that I wish private key setups would replicate.
Plus, those 24 words can also recover your u2f keys, crypto wallets, etc. The 24 word backup is something crypto has gotten right that I wish private key setups would replicate.
> Trezor - I've been using one for years and it's great. Also you can backup/restore the seed (so you don't need to register multiple devices).
Trezor does not make use of a secure element https://blog.trezor.io/is-banking-grade-security-good-enough...
Trezor does not make use of a secure element https://blog.trezor.io/is-banking-grade-security-good-enough...
I don't know the details but it doesn't sound great if you can exfiltrate secret material – the seed? – from a device.
A good smartcard should generate its own keys, on device, and only divulge them when persuaded to do so by an electron microscope.
A good smartcard should generate its own keys, on device, and only divulge them when persuaded to do so by an electron microscope.
You can't exfiltrate it - you can generate a seed externally and load it in, and back it up if you choose.
You can extract the seed, clone it into a new device, and get the exact same device with the same private key material?
Yes, but you can extract it only once; the device will refuse to provide it if it's already been provided.
Its pretty well known that fingerprints _by themselves_ are a pretty poor replacement for passwords. (a) They're public, in that it's pretty easy to get someone's fingerprint... just find something they touched recently. (b) If they're compromised its impossible to change them.
I don't think this gets around either of those points, but I am curious if this somehow makes it much more difficult to either compromise the fingerprint hash (fingerprint fingerprint?) or makes the resultant hash less useful once compromised.
I don't think this gets around either of those points, but I am curious if this somehow makes it much more difficult to either compromise the fingerprint hash (fingerprint fingerprint?) or makes the resultant hash less useful once compromised.
In essence, you require both the Yubikey in question, and the information supplied by the fingerprint reader to the Yubikey, in order to abuse this system.
From the perspective of a U2F token, which uses a regular button, this is an increase in security for most users -- if their token is lost or stolen, or left in their device, someone cannot use their token by tapping the button.
This doesn't address the inherent problem of irrevocability/unchangeability of biometrics, but it presents an interesting usability trade-off that could help non-technical users to keep their systems more secure.
If you capture the wire signal between the fingerprint reader sensor and the module, it is likely that you could replay a valid authentication. If not, you could delve deeper into the sensor until eventually you are able to inject capacitive data from the sensing surface itself, and do this.
In this case, by combining the use of a biometric with strong cryptographic authentication through the token, you require both to compromise the user -- no biometrics are shared with a server, it's all local. However if you lose either the token, or the ability to use that fingerprint (i.e. scratch or damage), you will lose access to the key the Yubikey has protected, absent some kind of backup password. For many users, that backup password will be the weak link, but a Yubikey should at least be able to rate limit attempts and erase its internal state if there are too many attempts.
From the perspective of a U2F token, which uses a regular button, this is an increase in security for most users -- if their token is lost or stolen, or left in their device, someone cannot use their token by tapping the button.
This doesn't address the inherent problem of irrevocability/unchangeability of biometrics, but it presents an interesting usability trade-off that could help non-technical users to keep their systems more secure.
If you capture the wire signal between the fingerprint reader sensor and the module, it is likely that you could replay a valid authentication. If not, you could delve deeper into the sensor until eventually you are able to inject capacitive data from the sensing surface itself, and do this.
In this case, by combining the use of a biometric with strong cryptographic authentication through the token, you require both to compromise the user -- no biometrics are shared with a server, it's all local. However if you lose either the token, or the ability to use that fingerprint (i.e. scratch or damage), you will lose access to the key the Yubikey has protected, absent some kind of backup password. For many users, that backup password will be the weak link, but a Yubikey should at least be able to rate limit attempts and erase its internal state if there are too many attempts.
For the WebAuthn scenario there is no inherent backup, there's deliberately no way to export the keys. For a random web site, they're likely going to offer some way back in - albeit Google is content to make that quite hard if you choose their "Advanced Protection" scheme (and I think one of the free Git offerings just says too bad, you gave us no money, you're locked out but you lost nothing of value), but an employer might very reasonably issue employees a Security Key and say something like, look, if you lose it that sucks but go to Front Desk with your Line Manager, and they can issue you a new one, there is no bypass.
As a user, it also makes sense (particularly if you know you're a real target, e.g. a political journalist, politician, activist) to just own more than one.
> Yubikey should at least be able to rate limit attempts and erase its internal state if there are too many attempts.
On the previous generation with a PIN as second factor, if you guess the PIN wrong repeatedly it locks you out.
As a user, it also makes sense (particularly if you know you're a real target, e.g. a political journalist, politician, activist) to just own more than one.
> Yubikey should at least be able to rate limit attempts and erase its internal state if there are too many attempts.
On the previous generation with a PIN as second factor, if you guess the PIN wrong repeatedly it locks you out.
Ideally, I'd have 2 webauthn tokens, one that I keep on myself, and one that I have at a secure, off site location (like a safe deposit box, if you consider that secure). The problem is you need to physically posses the backup key to register it to any new services you might sign up for.
Yubikey has proposed a webauthn extension to support this usecase[0]. Unfortunately it requires both changes to both hardware and server side webauthn libraries, so it will likely be years before this would actually be a viable solution.
[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
Yubikey has proposed a webauthn extension to support this usecase[0]. Unfortunately it requires both changes to both hardware and server side webauthn libraries, so it will likely be years before this would actually be a viable solution.
[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
Indeed - the lack of backups in WebAuthn is a design feature (although I can see credible usability issues in online services where users should really enrol several, but struggle to keep them in different locations and ensure they register their off-site backup key to each service etc.)
I presume (but haven't reviewed in detail) that these bio keys will have a backup PIN in the same way previous models had the PIN available for management and WebAuthn modes of operation - there are some real-world failure modes where wet hands or a bandaged finger may be an issue, but the user still wants to keep using it. I do agree the best solution is to get several tokens, enrol them all for each service, and just keep them as safe as you realistically can.
I presume (but haven't reviewed in detail) that these bio keys will have a backup PIN in the same way previous models had the PIN available for management and WebAuthn modes of operation - there are some real-world failure modes where wet hands or a bandaged finger may be an issue, but the user still wants to keep using it. I do agree the best solution is to get several tokens, enrol them all for each service, and just keep them as safe as you realistically can.
The backup would be another hardware token, ideally. Just one that isn't biometric. You would guard physical access to that token more closely.
Google's Advanced Protection Program enforces two keys, since they also make recovery much stricter.
Google's Advanced Protection Program enforces two keys, since they also make recovery much stricter.
Without this model the attacker needs to steal the Yubikey. With this model the attacker needs to steal the Yubikey and pull a fingerprint.
It remains to be seen if that's a meaningful difference, but it seems reasonable that in some situations it could make the attack much more costly.
I could see myself using this when traveling.
It remains to be seen if that's a meaningful difference, but it seems reasonable that in some situations it could make the attack much more costly.
I could see myself using this when traveling.
> Its pretty well known that fingerprints _by themselves_ are a pretty poor replacement for passwords. (a) They're public, in that it's pretty easy to get someone's fingerprint... just find something they touched recently. (b) If they're compromised its impossible to change them.
I'm a bit more worried about Russian ransomware operators getting my passwords than my fingerprint.
I'm a bit more worried about Russian ransomware operators getting my passwords than my fingerprint.
Hope you never have a picture posted online with your fingers in view, then.
Biometrics are terrible security tokens.
Biometrics are terrible security tokens.
Similarly you could say iPhones with Touch ID are terrible because phones are full of fingerprints. Yet it turns out people who want to crack them attack the pincodes or the general security of the device, not the fingerprints.
they might, but likely not with a resolution good enough to allow then to actually extract an useful fingerprint.. specially not after social media resize and convert the image a thousand times.
also, fingerprint is not the only security, you still need physical access to the yubikey to use it, something a russian hacker also will have a hard time having..
also, fingerprint is not the only security, you still need physical access to the yubikey to use it, something a russian hacker also will have a hard time having..
how does a Russian hacker having a picture of my fingerprint allow them to use my Yubikey to unlock my account?
If the police/border protection/etc ever took your fingerprints, don't worry, they'll get to them too. Maybe with even less effort than would be required for your password, depending on how diligently you protect your passwords.
even if they chop off your hand?
If Russian ransomware operators want to even attempt to chop off my hand I would need to start making much more interesting life choices that I have been.
Time to add an embedded EKG as another factor :)
It's not only a fingerprint. The fingerprint tells the yubikey that it's you who is activating it.
A fingerprint is not a password, it's a username.
I haven't used any of the other modes on my Yubikey 4 than the OpenPGP Smartcard. I would hope that other modes also support PINs/passwords, so the fingerprint is just an additional factor. If that's the case, it's not necessarily about replacing passwords with fingerprints.
> fingerprints _by themselves_ are a pretty poor replacement for passwords
eh, that is not well known nor is it true. It is very much use case dependent.
For example, a fingerprint is a great replacement for a password to unlock your phone, for most uses of such.
eh, that is not well known nor is it true. It is very much use case dependent.
For example, a fingerprint is a great replacement for a password to unlock your phone, for most uses of such.
Their strategy is to never launch a fully-featured key so you keep upgrading. For example, this $85 thing does not have NFC. I am not playing their game anymore. I'm pretty fine with my old YubiKeys.
I don’t buy into the “passwordless” designs. A fingerprint scanner might be better then a touch sensor but in the end it’s still a single factor.
I meet a lot of people who bought yubikey nanos and leave them plugged in all the time. Defeats the purpose. There should be a kiosk where you can exchange people’s unattended yubikeys for a cookie or some other treat. That would take care of that problem.
I meet a lot of people who bought yubikey nanos and leave them plugged in all the time. Defeats the purpose. There should be a kiosk where you can exchange people’s unattended yubikeys for a cookie or some other treat. That would take care of that problem.
it absolutely does not defeat the purpose: if you somehow manage to get my password/ssh key _remotely_, there is still one more obstacle you cannot get as it's _local only_. that is why it's a second factor.
something you know with something you have.
I'd say this covers the 99% of how credentials are being misappropriated.
something you know with something you have.
I'd say this covers the 99% of how credentials are being misappropriated.
The yubikeys are designed to be non-clonable, so it is two factors: something you have and something you are. Not all factors are created equal, and in the past there have been issues with biometrics not really being a reliable indicator of something you are.
What do you do if the hardware fails, or gets melted in a fire?
You keep a spare somewhere. Everything that does U2F IME allows you to register at least 2 tokens.
Except AWS, no?
Yep, super annoying, AWS doesn't allow you to register more than one MFA device.
Correct, but for AWS, you can use SSO and delegate the MFA to your SSO provider.
In AWS you must delegate your MFA to the SSO provider. Having an SSO provider but AWS managed MFA isn’t even possible because SSO users map to roles instead of IAM users.
It actually is. AWS SSO itself (so not on the IAM users level) supports user management too without an external SSO provider and actually _does_ allow multiple MFA devices unlike IAM. It's a giant hack but works!
It's actually the opposite. Most U2F services allow at most 1 registration.
> Most U2F services allow at most 1 registration.
We debunk this often several times per week on HN
Yes, AWS doesn't allow you to enroll more than one FIDO authenticator. No, AWS isn't "most" services, in the same way that Jeff Bezos isn't "most" people. When you mean "AWS" just say "AWS" not "Most services".
I have multiple Security Keys enrolled with, among others, Dropbox, Facebook, Google, and GitHub.
We debunk this often several times per week on HN
Yes, AWS doesn't allow you to enroll more than one FIDO authenticator. No, AWS isn't "most" services, in the same way that Jeff Bezos isn't "most" people. When you mean "AWS" just say "AWS" not "Most services".
I have multiple Security Keys enrolled with, among others, Dropbox, Facebook, Google, and GitHub.
Bank of America doesn't.
Doesn't Yubikey design them to be left plugged in all the time? I don't see how it compromises the security at all
Depends on which Yubikey. The nano series (aka the "gnubby") are designed to be permanently plugged in. The 5 and 5C are designed to live on your keyring.
It doesn't defeat the purpose (if you take it, they've lost a Factor and you still don't have enough of them) but it will certainly teach them to have more than one.
(Aside: I have a story for another time about how I soft-bricked my first while finally getting around to setting up a second; that I've not yet quite recovered enough to properly tell...)
(Aside: I have a story for another time about how I soft-bricked my first while finally getting around to setting up a second; that I've not yet quite recovered enough to properly tell...)
Importantly though it's a good single factor. Passwords aren't good.
1. They get repeated.
2. They get phished.
Even just as a single factor, even without a fingerprint reader, a yubikey is far superior to a password. Adding a biometric on top of that is wayyyy better than a password.
Most of what MFA has done for us is actually just provide slightly better "A's". It's not the quantity that counts, it's the quality.
Previously to reach a good quality we'd need multiple factors. We've reached a point now where we have standards for authentication that are strong, often "strong enough", even with a single factor. A password then becomes a bit of a bonus.
1. They get repeated.
2. They get phished.
Even just as a single factor, even without a fingerprint reader, a yubikey is far superior to a password. Adding a biometric on top of that is wayyyy better than a password.
Most of what MFA has done for us is actually just provide slightly better "A's". It's not the quantity that counts, it's the quality.
Previously to reach a good quality we'd need multiple factors. We've reached a point now where we have standards for authentication that are strong, often "strong enough", even with a single factor. A password then becomes a bit of a bonus.
[deleted]
When Webauthn requests user verification on a non-bio yubikey user needs to provide a (6 digit) pin.
Off topic, but it’s so frustrating how yubikey (or any non SMS/email 2FA as a matter of fact) is not supported for any bank. I think I would sign up right away to a bank that supports yubikey or authenticator apps.
When they finally support it, I guess they will add the convenient option to say you don't have your yubikey with you at the moment and then an SMS will be sent instead.
I recently was looking to add my yubikey to one of my banks (BofA) and I could not for the love of god figure out how to add one. I know BofA supports it because there are many articles about adding it, but I couldn't find a way of doing it from their website. The best I could do from there was SMS 2FA.
I finally found a link from just googling around that took me directly to a page where you could add a security key. But the catch was that I had to have an active session if I wanted to add a key. If you weren't already logged in in another tab, it will redirect you to the BofA dashboard after you log in. From all the time I spent, there is no way to get to that page from the BofA web dashboard. Very frustrating and annoying experience. But atleast it is out of the way now.
FYI you can only have a max of 2 yubikeys.
I finally found a link from just googling around that took me directly to a page where you could add a security key. But the catch was that I had to have an active session if I wanted to add a key. If you weren't already logged in in another tab, it will redirect you to the BofA dashboard after you log in. From all the time I spent, there is no way to get to that page from the BofA web dashboard. Very frustrating and annoying experience. But atleast it is out of the way now.
FYI you can only have a max of 2 yubikeys.
My bank recently started supporting it:
https://www.online-zahlen-mit-fido.de/
https://www.online-zahlen-mit-fido.de/
Wow, that's a bad website UX. "Pay online with FIDO", no links back to Sparkasse website. It screams "Phishing" miles away. And it isn't linked from here: https://www.sparkasse.de/service/sicherheit-im-internet/ihre...
At least it is mentioned here: https://www.foerde-sparkasse.de/de/home/service/fido-token-m...
However, this is a website I'd say my mother to not go to
At least it is mentioned here: https://www.foerde-sparkasse.de/de/home/service/fido-token-m...
However, this is a website I'd say my mother to not go to
Have you asked them to? I've sent support requests to every vendor that doesn't support U2F with the hope that if others do the same it may get bumped up.
Same. I don't know of a single US-based bank that supports it.
Charles Schwab supports it
Can you bypass it with SMS? Or can you permanently disable SMS 2FA?
I don't think you can bypass it with SMS so if you get locked out you need to call them. Not sure how easy it is to bypass by calling them. But Schwab doesn't support hardware keys.
Morgan Stanley is the only bank/financial company I know supports hardware keys.
Morgan Stanley is the only bank/financial company I know supports hardware keys.
Does anyone else find fingerprint readers mostly unusable?
I love them when they work, but my fingers are very often unreadable due to dirt, cuts, paint, oil, swimming or bath wrinkles, etcetera. I’ve had the problem with multiple devices (e.g. iPad, Nokia phone).
Because I have to use the secondary authentication so much of the time, I find little merit in using a fingerprint for security.
I love them when they work, but my fingers are very often unreadable due to dirt, cuts, paint, oil, swimming or bath wrinkles, etcetera. I’ve had the problem with multiple devices (e.g. iPad, Nokia phone).
Because I have to use the secondary authentication so much of the time, I find little merit in using a fingerprint for security.
I'm with you, I've fallen out of the habit of using fingerprint auth on any of my devices that support it (Macbook, Thinkpad, Motorola phone) because it's so unreliable. I have to re-enroll at least weekly if I want to keep it working well. I have eczema issues on my hands, which I think is the main issue, but also have found cuts and paint/glue to be common problems. I can enroll multiple fingers but that means I have to try four fingers before it unlocks... and usually I end up enrolling the same finger multiple times instead since the device has stopped recognizing it.
For what it's worth I used to have a job that involved frequent use of an optical fingerprint reader (the type that's a camera behind a glass platen) and did not have these types of problems with it. I think it's a weakness of the capacitative type of reader that all devices are using now, or possibly just less sophisticated matching software.
For what it's worth I used to have a job that involved frequent use of an optical fingerprint reader (the type that's a camera behind a glass platen) and did not have these types of problems with it. I think it's a weakness of the capacitative type of reader that all devices are using now, or possibly just less sophisticated matching software.
The one to unlock my Samsung Galaxy whatever-number-it-is works pretty consistently.
Don’t know if this works for others, but for Apple Touch ID you can solve the wet finger issue by adding another set of prints while the finger is wet.
Android supports registering multiple fingerprints to get around this. I wonder if that's also possible with this key.
No OpenPGP Smartcard support, I see. :(
What are the alternatives now? I never really liked the Yubico stuff, though I have to admit that their hardware is well made.
If you wanted OpenPGP to protect SSH, you should consider upgrading clients and servers to a modern OpenSSH which can just speak FIDO (which this and other recent Yubikeys support)
I haven't used FIDO. If you lose your FIDO key, do you have the option of buying another one and making it authenticate like the original without having to inform all the servers of the change?
I think the only advantage of FIDO over OpenPGP is that some web services support it. Are there other advantages?
I think the only advantage of FIDO over OpenPGP is that some web services support it. Are there other advantages?
Yes, you would need to inform all the servers of the change, a compliant FIDO authenticator shouldn't be clonable.
However, if you've got a whole bunch of servers you can do SSH certificates instead of raw keys, and then you only need to go through the process once (to get the certificate) since the servers just care that your certificate was signed by the authorised CA.
That definitely makes sense if you're at the "cattle not pets" level of servers where you don't care which server this is, and it can start to make sense even at the scale I grew up with where servers have themed names, so really by the time "All the servers" seems like a genuinely annoying problem, you ought to be rolling out certificates.
Once upon a time I'd have argued that some of the other tricks to do centralised key auth are good, but I think on balance you should just go with certificates.
FIDO is cheaper, although obviously if you already have OpenPGP you don't care about that.
However, if you've got a whole bunch of servers you can do SSH certificates instead of raw keys, and then you only need to go through the process once (to get the certificate) since the servers just care that your certificate was signed by the authorised CA.
That definitely makes sense if you're at the "cattle not pets" level of servers where you don't care which server this is, and it can start to make sense even at the scale I grew up with where servers have themed names, so really by the time "All the servers" seems like a genuinely annoying problem, you ought to be rolling out certificates.
Once upon a time I'd have argued that some of the other tricks to do centralised key auth are good, but I think on balance you should just go with certificates.
FIDO is cheaper, although obviously if you already have OpenPGP you don't care about that.
> Yes, you would need to inform all the servers of the change, a compliant FIDO authenticator shouldn't be clonable.
Depends on how you define clonable, but that shouldn't be a requirement to be able to avoid having to inform servers. OpenPGP smartcards can't be cloned in the sense of being able to read the key off them, but you can write the key to them. So a key-pair can be generated outside, written to the smartcard and backed up however one considers sufficiently secure. If the smartcard is lost, one can buy another one and write the key from the backup.
The old smartcard being lost is not much of a concern either, since if the password is entered incorrectly a few times, the smartcard becomes blocked.
> However, if you've got a whole bunch of servers you can do SSH certificates instead of raw keys, and then you only need to go through the process once (to get the certificate) since the servers just care that your certificate was signed by the authorised CA.
Not all circumstances are equal. Some servers are too old to support certificates :(, and upgrading just the ssh servers is unvalued and non-trivial (I don't know if OpenSSH still even supports the OS). Also, servers are not all under the same organization, so no unified CA.
Authenticating via OpenPGP requires no server considerations. It works everywhere and is a personal decision rather than an organizational one.
Depends on how you define clonable, but that shouldn't be a requirement to be able to avoid having to inform servers. OpenPGP smartcards can't be cloned in the sense of being able to read the key off them, but you can write the key to them. So a key-pair can be generated outside, written to the smartcard and backed up however one considers sufficiently secure. If the smartcard is lost, one can buy another one and write the key from the backup.
The old smartcard being lost is not much of a concern either, since if the password is entered incorrectly a few times, the smartcard becomes blocked.
> However, if you've got a whole bunch of servers you can do SSH certificates instead of raw keys, and then you only need to go through the process once (to get the certificate) since the servers just care that your certificate was signed by the authorised CA.
Not all circumstances are equal. Some servers are too old to support certificates :(, and upgrading just the ssh servers is unvalued and non-trivial (I don't know if OpenSSH still even supports the OS). Also, servers are not all under the same organization, so no unified CA.
Authenticating via OpenPGP requires no server considerations. It works everywhere and is a personal decision rather than an organizational one.
> So a key-pair can be generated outside, written to the smartcard and backed up however one considers sufficiently secure.
Presumably you're comfortable with this, but there's no reason the server operator should be. It's pretty obvious where the weakest link is.
Also this is pretty inherently contrary to the design of FIDO, because it privileges these private keys as special whereas in FIDO they're random and you can just mint more of them (in FIDO1 it's completely normal to make huge numbers of keys, since you aren't storing them anyway). In the original OpenPGP case where the keys are personal identity keys for signing email that feels reasonable, but already for SSH that's not really what you needed anyway.
It is true that OpenPGP is much better if you were obliged to do RSA for compatibility reasons, but I think we'd all like to move away from that world even if some of us can't yet.
Presumably you're comfortable with this, but there's no reason the server operator should be. It's pretty obvious where the weakest link is.
Also this is pretty inherently contrary to the design of FIDO, because it privileges these private keys as special whereas in FIDO they're random and you can just mint more of them (in FIDO1 it's completely normal to make huge numbers of keys, since you aren't storing them anyway). In the original OpenPGP case where the keys are personal identity keys for signing email that feels reasonable, but already for SSH that's not really what you needed anyway.
It is true that OpenPGP is much better if you were obliged to do RSA for compatibility reasons, but I think we'd all like to move away from that world even if some of us can't yet.
> It's pretty obvious where the weakest link is.
It isn't, considering how little information I've given you. The weakness of links depend on the threats we model and how we protect the links against such threats. You're lacking a lot of information to evaluate the weakness of links in these contexts.
> Also this is pretty inherently contrary to the design of FIDO, because it privileges these private keys as special whereas in FIDO they're random and you can just mint more of them (in FIDO1 it's completely normal to make huge numbers of keys, since you aren't storing them anyway).
I've read a bit on that, on how it makes a new key-pair per device-service-user combination. I honestly can't tell if that's an advantage or disadvantage. It at least seems like a disadvantage to have to hold both main key and backup key on new registrations to make sure you don't lose access when you lose a key. Besides being inconvenient, it seems to mean that the backup key has similar chances to being lost as the main key. In contrast, with OpenPGP, you can even store the backup key in a separate location like a safety deposit box and generally forget about it until you need it.
> It is true that OpenPGP is much better if you were obliged to do RSA for compatibility reasons, but I think we'd all like to move away from that world even if some of us can't yet.
Regarding RSA, I agree. OpenPGP isn't limited to RSA though and has more uses than just direct authentication.
It isn't, considering how little information I've given you. The weakness of links depend on the threats we model and how we protect the links against such threats. You're lacking a lot of information to evaluate the weakness of links in these contexts.
> Also this is pretty inherently contrary to the design of FIDO, because it privileges these private keys as special whereas in FIDO they're random and you can just mint more of them (in FIDO1 it's completely normal to make huge numbers of keys, since you aren't storing them anyway).
I've read a bit on that, on how it makes a new key-pair per device-service-user combination. I honestly can't tell if that's an advantage or disadvantage. It at least seems like a disadvantage to have to hold both main key and backup key on new registrations to make sure you don't lose access when you lose a key. Besides being inconvenient, it seems to mean that the backup key has similar chances to being lost as the main key. In contrast, with OpenPGP, you can even store the backup key in a separate location like a safety deposit box and generally forget about it until you need it.
> It is true that OpenPGP is much better if you were obliged to do RSA for compatibility reasons, but I think we'd all like to move away from that world even if some of us can't yet.
Regarding RSA, I agree. OpenPGP isn't limited to RSA though and has more uses than just direct authentication.
> It isn't, considering how little information I've given you
No, I'm still pretty sure it is obvious because it's that hard to get the authenticator to do anything without you. The trouble with the approach you prefer is that anything you can do "as a backup" crooks can do "as a crime" just as easily.
The FIDO people weren't interested in offering a convenient way for crooks to break into your systems, even under the name "backup", so, there isn't one.
No, I'm still pretty sure it is obvious because it's that hard to get the authenticator to do anything without you. The trouble with the approach you prefer is that anything you can do "as a backup" crooks can do "as a crime" just as easily.
The FIDO people weren't interested in offering a convenient way for crooks to break into your systems, even under the name "backup", so, there isn't one.
[deleted]
> I haven't used FIDO. If you lose your FIDO key, do you have the option of buying another one and making it authenticate like the original without having to inform all the servers of the change?
I think this is technically possible (some keys let you access the seed iirc, though the FIDO counter would not match) but not recommended. Instead you'd just register two keys so that if you lose one you have a backup.
I think this is technically possible (some keys let you access the seed iirc, though the FIDO counter would not match) but not recommended. Instead you'd just register two keys so that if you lose one you have a backup.
I don't know of a similar product that supports tap-prompts and blinking lights[1] like Yubikeys do. Yubikey 4/5 still seem to be the best, IMO.
[1] https://news.ycombinator.com/item?id=28765982
[1] https://news.ycombinator.com/item?id=28765982
I would probably buy it if it had OpenPGP support
Most of the YubiKeys support PIV (NIST SP 800-73) mode, which gets you X.509 support (and a PKCS#11 module), which has much broader support than PGP.
The Bio series does not support PIV/PKCS#11 at this time afaik
Me too. OpenPGP is super flexible and this would've been an upgrade to 3FA for everything I use it for.
The cookie preference on the website is impressive. By default only necessary cookies are enabled if you just click "Accept". You also have to explicitly enable the "functional cookies" to view the embedded video.
At $85 for the USB-C version it is surprisingly expensive (In my mind these Yubikeys have all been around $50).
And it only supports FIDO/Webauthn/U2F -- so you cannot use this with the Yubikey authenticator app to store TOTP tokens.
And it only supports FIDO/Webauthn/U2F -- so you cannot use this with the Yubikey authenticator app to store TOTP tokens.
I bought some Yubikey standards back in 2014 and they were $25 apiece. The Yubikey 5 NFCs I got 4 years later were $45 apiece, but had NFC and did more stuff. They released some U2F-only yubikey security keys that I thought were $20 but I am not sure (they were blue, and cheap).
Now these, which the site suggests can only do U2F/Webauthn with fingerprint, are $80. I think it's cool to have a portable fingerprint-secured webauthn token, but it's disappointing to see them so expensive. I wonder if this is the long-term price, or if they are more expensive temporarily due to supply chain issues or something like that. Or, maybe they are substantially cheaper in bulk.
Now these, which the site suggests can only do U2F/Webauthn with fingerprint, are $80. I think it's cool to have a portable fingerprint-secured webauthn token, but it's disappointing to see them so expensive. I wonder if this is the long-term price, or if they are more expensive temporarily due to supply chain issues or something like that. Or, maybe they are substantially cheaper in bulk.
Given that they're limiting the number of them that a given customer can buy I suspect that the price is in part the supply.
There are budget smartphones you can buy under hundred bucks (Cubot Note 7). Charging $85 for this is ridiculous.
Yes and no. For me the $85 feels expensive compared the other YubiKeys I own. On the other hand, if the $85 stops one "event" then the price is low.
It's just hard to swallow when the BOM is $10 and the hardware is simple. Nothing about it is magic.
What other alternatives are there?
[deleted]
Looks cool, but sad there is no NFC support.
This looks like it might be a bit of an early testing-the-waters, or even a one-off to satisfy a specific set of customers (note that they're FIPS compliant only).
If there's more traction I would expect future models to include more features.
If there's more traction I would expect future models to include more features.
To me, form factor is a bigger limitation than lack of NFC support. I'd mostly want this replacing the 5C Nano I leave in the laptop that actually travels with me. A clunky key like this would have to be left for desktop use.
Yeah, that's a tradeoff for sure. Until they find a way to fit a biometric reader into a 'nano' form factor at least.
I wonder if the limitation is power. Can a fingerprint scanner be powered by NFC?
OTOH in my specific use case, I only use the NFC with my phone, the USB-C version should take care of that
OTOH in my specific use case, I only use the NFC with my phone, the USB-C version should take care of that
Yes, see e.g https://www.zwipe.com/
But would of course depend on the sensor. Zwipe uses a sensor from the Swedish company FPC
But would of course depend on the sensor. Zwipe uses a sensor from the Swedish company FPC
Even in that case, NFC is just so much more convenient than USB-C (and you don't have to worry about wear & tear on the connector).
I was so excited to read this because I thought Yubico had finally launched implantable NFC yubikeys that we could carry under the skin.
Too bad it's just a fingerpirnt sensor.
Too bad it's just a fingerpirnt sensor.
Is it possible for a retail user (no domain, AD, etc.) to use a YubiKey as a Windows Hello second factor? Forgive me if this is obvious; I’ve spent a lot of time googling and I only come up with references to using in context of enterprise device/user management.
Because if YubiKeys could be used, this seems much better than the typical cheap USB fingerprint readers that are for sale.
Because if YubiKeys could be used, this seems much better than the typical cheap USB fingerprint readers that are for sale.
Yes, Windows can use a Yubikey for Windows Hello either to unlock the device (not login) or as a second factor for anything else supporting Hello.
No OpenPGP support means users won’t be able to use Pass password manager and GPG to lock down various stuff?
Then, I won’t downgrade!
It’s worth mentioning, it doesn’t seem to be FIPS validated. It therefore doesn’t meet US government requirements (see NSA guidelines). I don’t know how much this is important in practice.
Then, I won’t downgrade!
It’s worth mentioning, it doesn’t seem to be FIPS validated. It therefore doesn’t meet US government requirements (see NSA guidelines). I don’t know how much this is important in practice.
Can someone explain why this makes authentication more secure?
If I tap the device while a malicious process is attempting to access another machine in the background, what good does this device do?
If I tap the device while a malicious process is attempting to access another machine in the background, what good does this device do?
Not with the Bio series apparently, but at least on the Yubikey 4, when you're setup with OpenPGP, a tap works with a single request and it prompts you to tap with a blinking light. If it's blinking when you haven't done anything to prompt a tap, that would be something to worry about. If you do something that prompts a tap and a malicious process also requests something from the key at the same time, you'll get 2 requests. You'd tap it for the request you're expecting, see it blinking faster to confirm your tap, and then blink slowly again to request the 2nd tap. That second request would be your cue for worrying. IOW, the blinking is an alert against your scenario.
Ok, thanks! How do well does this key go together with workflows that use automation (e.g. daily rsyncs over the network that run in the background)?
Not sure how you want to combine automated daily rsyncs with hardware keys. You can use OpenPGP for ssh authentication, and set it up so it prompts you when rsync starts automatically. However, do you really want your automated jobs to depend on having a human to answer prompts or at least having a key inserted when it's scheduled to run? It sounds like there could be a better setup.
My issue is that once I start using authorized_keys for automated processes, then it defeats the purpose of the key.
Why? authorized_keys holds public keys. Why would it defeat the purpose of a hardware private key?
FIDO keys are really more about avoiding human errors/ human auth. If you need to authorize a server you may want to just use a client certificate.
[deleted]
I don't even understand the threat model for this, and why it's better than the fingerprint sensor built into the laptop. Seems like it's just writing the software elsewhere. What's up with the micro Yubikeys always left in a usb port operable by anyone made even less sense, so a step up.
Compared with a button based yubikey, someone else can't trivially tap this one if it's left behind, as you say.
From a threat model perspective, biometrics are far from perfect. This setup avoids disclosing the biometric to the host system though - the yubikey itself validates the biometric and signs (or doesn't sign) a response with an internal protected private key. If you had a sensor built into a laptop or workstation, you are trusting that sensor. Some old ones used to expose raw fingerprint data to the operating system, which is clearly bad.
If the user brings their own reader, you don't need to expose any biometric information beyond the yubikey itself (which is issued per user), so a host compromise or a rogue system won't be able to compromise someone's biometrics. Admittedly in this case a lot of the threat models that make sense would involve shared computers etc, and those have their own security issues.
From a threat model perspective, biometrics are far from perfect. This setup avoids disclosing the biometric to the host system though - the yubikey itself validates the biometric and signs (or doesn't sign) a response with an internal protected private key. If you had a sensor built into a laptop or workstation, you are trusting that sensor. Some old ones used to expose raw fingerprint data to the operating system, which is clearly bad.
If the user brings their own reader, you don't need to expose any biometric information beyond the yubikey itself (which is issued per user), so a host compromise or a rogue system won't be able to compromise someone's biometrics. Admittedly in this case a lot of the threat models that make sense would involve shared computers etc, and those have their own security issues.
The threat model is that people can't ssh to your machine in order to elevate their access (e.g. corporate VPN), because they can't physically touch the key. Example: whatever happened when major Twitter accounts were compromised.
Yes, but how is that different than if the software integrated with the sensor built into the hardware, like when 1Password uses the laptop's fingerprint reader?
There are some technicalities (I'm not sure what they are, but some orgs may want to have some boxes ticked for corporate approval of a tool). Then there is the fact that you can actually use the key in multiple machines, even those that don't have biometrics (e.g. desktops)
Personal use case: I have my 1password account locked with a YubiKey, which means that if somebody would steal my credentials they can't get in without one of my devices. However, I still can technically use it from a browser on a friend's computer if I really needed to.
Personal use case: I have my 1password account locked with a YubiKey, which means that if somebody would steal my credentials they can't get in without one of my devices. However, I still can technically use it from a browser on a friend's computer if I really needed to.
[deleted]
Something you are, protecting something you have, which is designed for protecting something you know. 3FA is too much. Lose any of the 3 and access is denied.
I know this analogy is not pedantic but it's fun to imagine the same argument with physical keys.
Lose your hands and you won't be able to use your house key.
Lose your house key and you'll have nothing to use.
Lose your mind and you won't know how to use a key.
Lose your hands and you won't be able to use your house key.
Lose your house key and you'll have nothing to use.
Lose your mind and you won't know how to use a key.
The house analogy does not work well. Finger cuts, hand casts, over-use of sanitizer, dirty, wet, or wrinkled hands, etc. will not only deny you access to your stuff, it will do so for an extended length of time. You will need to either fall back to 2FA or wait until your body returns to a previous state.
Yes, and forgetting a password is more likely than forgetting how to use a key. That's why I said it's not a good analogy. But it sounded so funny I had to get it out of my system.
You can setup alternate valid credentials. For example, in the case of the "have", you can have multiple valid keys. In the case of the "know", multiple valid passwords. In the case of the "are", perhaps on this model or a future one, multiple valid fingerprints. You can also setup e.g. alternate 1FA with a really strong password.
Interesting spin on the usual method of:
- Something you know (password)
- Something you have (hardware token)
Now with the Bio it's also:
- Something you Are
- Something you know (password)
- Something you have (hardware token)
Now with the Bio it's also:
- Something you Are
Do Yubikeys work with USB A to C adapters?
using a publicly known login that you can't change (fingerprints) as a password is probably not the greatest idea...
I feel I am 10,000x more likely to be attacked from inside my computer by a digital intruder than from any other vector. I lock my Yubikeys with a PIN but I’m not convinced it really protects me against anything that might actually happen to me. Jason Bourne, I am not.
If you, on the other hand, face targeted physical threats on the daily then you have my sympathies. Stay safe.
(Ps: any recommendations for an HSM with a more exciting presence check? I’d like to shoot a hoop / shoot a tin can / shoot a shot of wheatgrass every time I log in, rather than just press an ambiguously hello/green blinky light.)