Yubikeys, for me, are convenient second computers for burying private key material that is only accessible via the physical presence check.
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.)
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.
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.
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.
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.
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.
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.
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.
> 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.
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..
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.
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.
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.
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.
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.
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.
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!
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.
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...)
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.
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.
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.
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.
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'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.
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.
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?
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.
> 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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
Because if I can automatically log in through authorized_keys (used by my scripts), then it doesn't make sense to also have an authentication method that requires a key.
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.
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.
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.
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.
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.)