(EDIT: Besides Reddit, I've also put this up on Github Gist)
So while looking for information on security keys before getting one myself, I got very confused reading about all the different modes and advertised features of Yubikeys and other similar dongles. The official documentation tends to be surprisingly convoluted at times, weirdly organized and oddly shy about a few of the limitations of these keys (which I'm making a point of putting front and center). Now that I have one, I decided to write down everything I figured out in order to help myself (and hopefully some other people reading this) make sense of all this.
Since I'm partly writing these notes for myself, there might be some back and forth between "explain like I'm five" and "I'll asume you have a minor in computer science". While I could have made some of those explanations simpler, I really wanted to lay down some of the inner workings of the key enough to make what it can and can't do clear, which can be hard to boil down into making it simple (let alone short, I'll be the first to say I really went overboard with how long this turned out to be).
I'm also writing most of these sections with the "fully-fledged" Yubikey 5 models in mind, given the other available models support subsets of that. The limitations are usually the same across all Yubikey models, but I'll try to point out the differences where I've managed to find any.
So, then, what's a Yubikey?
(you know you're going to lose points for brevity when you need a table of contents for your Reddit post)
- Part 0: It's a stupidly small USB drive
- Part 1: It's a WebAuthn authenticator
- Part 1a: Resident keys (FIDO2)
- Part 1b: Attestations (FIDO1)
- Part 1c: PINs and user verification (FIDO2)
- Part 2: It's an OATH One-Time Password generator
- Part 3: It's a CCID smart card in USB/NFC form
- Part 3a: PIV smart card
- Part 3b: OpenPGP smart card
- Part 4: It's a virtual keyboard that can type up to two (2) passwords
- Part 4a: Yubico OTP
- Part 4b: Static password
- Part 4c: Challange-response
- Part 4²: NFC tag
- Part 100: It's all write-only, you can't just "make a backup later"
- FAQ
- What's different about the FIPS models?
- Can I update the firmware on my Yubikey after I get it?
- Is it less secure to have NFC enabled on my Yubikey?
- How am I supposed to keep my backup Yubikey in a safe place if I need it to register new websites on it?
- Isn't it a bit too easy to permanently delete the credentials stored on the key?
- Are NFC and USB completely equivalent when using the Yubikey?
- Should I be worried about breaking my Yubikey?
- Is the plural of "YubiKey" actually "YubiKeys"?
Let's get the limitations part out of the way first. The Yubikey 5 is pretty much just one single chip: an Infineon SLE 78 microcontroller. That thing houses a whopping 512 kiB of flash memory. That's comparable to some of the larger NES cartridges, so that number should start to put some of the limitations in context when we come back to those.
[limit: unlimited]
The Yubikey brand has been around for a while, but the reason they're starting to become "hip" as of late is because of two specifications making such devices suddenly very conveinient to use on the web: U2F (2014, supported by the Yubikey 4 and up) and WebAuthn (2017, fully-supported by the Yubikey 5 but backwards-compatible with U2F devices). Yubikeys support a bunch of older, currently more well-establlished ways of digitally confirming your identity, and I'll go through those as well, but this next part is most likely what you'd be buying one for. This is actually big enough that they even released the Security Key series: variants of the Yubikey 5 that ditch every other feature except for this one.
To keep the wording from getting confusing I'm using "authenticator" or "security key" to refer to the Yubikey in this section. I'm also using "FIDO1" even though the correct name should be "FIDO U2F" and "WebAuthn" to refer to platforms that may not actually support FIDO2 (like Android) and even the platforms that aren't web-based at all (like PAM login on Mac and Linux).
When you use WebAuthn to register a second factor on a website, what your security key does is it generates a public/private key pair (the website can ask for a number of different formats) and then sends both of them over to the website.
Sidenote:
If you've never heard of assymetric cryptography before, it's like having a padlock with a key. It's completely safe to send someone an empty box with a padlock, and anyone who has that padlock (public key) is able to lock it into place. Once that's done, however, it can only be unlocked with the matching key (private key). The padlock metaphor only works when the keys are used for encryption, so the metaphor doesn't help that much in our case, but the idea is that there are no "shared secrets", here.
Assymetric cryptography means you can just hand out a public key like it's a buisness card instead of nervously whispering it like you would with a password. That public key can then be used by anyone who has it to either encode messages so that only someone with the corresponding private key can read them (encryption) or validate that a message is actually coming from you (signing).
Now, sending your private key anywhere is a terrible idea, since it's generally assumed that anyone who has it has to be the owner, so anyone who lays their hands on it can then just pretend to be you when talking to services you registered that private key with. The trick, here, is that the private key is actually sent in a locked box (encrypted) and the website is expected to store it without knowing what is inside of it. When you later try to connect, the Yubikey will get that box back, attempt to unlock it (you have to try to unlock it to know if you have the right yubikey), and it will then be able to use the private key inside to sign things without either the server or your own computer having any idea of what the private key looks like.
The above means a bunch of things:
- An authenticator cannot know what websites it's actually been registered on, since it keeps no memory of that (unless it does, see "Resident keys" below).
- This may sound bad, but it's also a plus if your Yubikey ever gets lost or stolen, since the person who finds it can't know what accounts it unlocks as a second factor.
- It's also what allows Yubikeys to work with an unlimited amounts of accounts.
- Likewise, it's impossible to know what authenticator a key belongs to (unless the server wants to know, see "Device attestations" below)
- If you have a bunch of them plugged in, the only option is for the computer to try each one until one of them manages to unlock the private key.
- This is meant to address privacy concerns, to avoid security keys being recognized and their owners to be tracked across websites.
- Resetting the WebAuthn feature on the Yubikey basically works by deleting ("shedding") the decryption key used to decrypt private keys and overwriting it with a new one.
[limit: 25]
The idea that the security key shouldn't store anything is an interesting way to ensure the accounts registered with it as a second factor can't be tracked if the key is ever lost and found. Among the millions of keys the server might know, it at least needs a username to narrow down the selection to a managable "keyring", and then it needs to try each and every key on that keyring on every Yubikey you have plugged in (hopefully just one) until one matches.
That's nice if you want to make it impractical for someone who's not supposed to have your Yubikey to figure out what your account is (which is generally a good thing), but it's a problem if you were hoping to use the key to get rid of passwords entirely. The FIDO 2.0 spec (the WebAuthn one, Yubikey 5, etc.) spares everyone the trouble by allowing you to have a number of these credentials reside directly on the key (hence "resident keys"). A website can then ask "Does any authenticator plugged in holds credentials for me?", which allows it to authentcate you directly (possibly even with multiple accounts for one site) without the need to even enter your username on websites that support it.
If you're familiar with using "SSH keys" to login on, say, GitHub, it's pretty much the same: it's no less secure as long as the key is protected by a PIN, and using these and lets you skip using usernames and passwords entirely. The private key on its own is unguessable and is unique and secure enough by itself to act as a "It's me, let me in!" without even the need for a username.
That's not a way to authenticate you, but I figured I would mention it. Any website using WebAuthn can ask that the authenticator itself provide an attestation of the origin for the credentials being sent. This only means that the key will also return a certificate proving its authenticity and a signature to prove that it did generate the credentials.
The certificate contains these things:
- The Yubico metadata
deviceIdfor your specific Yubikey model (extension1.3.6.1.4.1.41482.2) - Whether or not your authenticator can connect via USB, Bluetooth, NFC or is built into your computer/phone (extension
1.3.6.1.4.1.45724.2.1.1/id-fido-u2f-ce-transports) - An AAGUID that matches your Yubikey's model and firmware version (extension
1.3.6.1.4.1.45724.1.1.4/id-fido-gen-ce-aaguid) - A signature from Yubico themselves using their root certificate to prove that everything else on the certificate is legit according to them (
Issuer: Yubico U2F Root CA Serial 457200631)
You can see what this information basically amounts to using Yubico's own test page.
All in all, you can think of an attestation as a sticker that says: "This password was generated on a real Yubikey 5 NFC! (firmware 5.2)"
Websites may want to use this information to verify that the key's manufacurer is trustworthy and that the device itself is genuine, or for more mundane things like automatically adding icons on their list of registered security keys.
As per the FIDO privacy principles, this shouldn't be enough to uniquely identify your device, but it could technically be used to assist in fingerprinting your browser. Because of this, some browsers (like Firefox) may issue a warning and offer to anonymize the attestation instead, which simply leaves out the certificate and signature, regardless of whether the website asked for those or not. The Firefox warning makes it sound scarier than it is; what I listed above is the full extent of what you're sharing when you allow the attestation to be sent.
While it's not a fingerprint reader (yet), the golden contact on the Yubikey fulfills an important role by requiring you to press it: It tells the Yubikey that someone next to it (hopefully you) approved the authentication request in a way that the computer has no control over. That means any program that tries to access WebAuthn features can't avoid requiring you to press that button. This is called a user presence check.
Another thing FIDO2 adds, which kind of complements resident credentials and passwordless login is user verification checks, which are meant to prove that the user who made the authentication request is not only physically there, but also the owner of the key. On keys that don't have biometric scanners, user verification will boil down to a simple PIN. It's up to the websites to require it or not, given how the feature is not available on the older FIDO1 devices and how not all systems may actually be able to ask for it. This has interesting consequences, which I'll talk about later.
Devices that support that feature must allow the user to set a PIN containing any sequence of UTF-8 characters (you can go wild with accents and emojis if you like) between 4 and 63 bytes long. According to the FIDO2 specification, the authenticator must also not allow more than 8 consecutive incorrect PIN attempts. In the case of the Yubikey, this means entering the wrong PIN 8 times in a row will cause it to permanently refuse user validation (PIN) requests until the entire FIDO module is reset using the Yubikey manager.
You definitely won't get it wrong that many times in a row without noticing, though. Windows 10 and Chrome's built-in WebAuthn module (which shows up on Linux and Windows version without security key support) will start asking you to remove and reinsert your key on each attempt as you keep getting it wrong, so you'll at least know what's coming. Also on Windows 10, if you only have a single PIN attempt left, you will be asked to enter "1AB2C3" first as an acknowledgement that this is the last chance you have of entering the correct PIN until the key gets locked.
So what happens once the key is locked? That's where the "optional support" part makes things interesting.
Because of the way neither devices and browsers can be assumed to actually support user verification, WebAuthn doesn't actually care if that step was performed or not. While the security key won't work if the website says the pin is required and the browser can't handle it (like Android or iOS), it will happilly process authentication requests that leave out the PIN so long as it's not explicitly written that it can't. It's up to websites to ensure that the the authenticator actually performed the user verification check in the assertion it returns.
So why do neither Chrome and Windows accept the security key anymore? Because they're being extra careful and checking for the PIN (and failing, because the PIN is locked) even when it's not needed. Rightfully so, given letting people login without the PIN is rarely the intended goal.
That means you can technically keep using a locked FIDO2 key like it's a FIDO1 key for as long as you would like!
Also, unlike with the Yubikey 4 FIPS, resetting the FIDO2 module on your Yubikey 5 doesn't wipe the attestation certificate, so the factory reset won't have any lasting impact besides losing your credentials.
[limit: 32, either TOTP or HOTP]
While WebAuthn and U2F are starting to become established on various websites and services, they're still both rather new. The more common second authentication factor you'll see used on the web right now is Open Authentication (OATH) with their timed one-time passwords (TOTP). These are what you'll see used by Discord, Humble Bundle, EA Origin, Reddit and any other service that offers that you use Google Authenticator or Authy to scan a QR code which registers the service. Internally, this is also what is being used by Steam Guard and BattleNet Authenticator (to name a few), but these don't actually allow you to register the TOTP secrets elsewhere, so you have to stick with using their own applications.
The way these work is by generating a new password every 30 seconds that you need to enter as your second factor before it expires, usually a few seconds after the next one is generated. The Yubikey can store all the elements needed to generate these, but it can't input those passwords automatically (because you need to know the exact time for that, and the Yubikey doesn't have a clock or a battery). In order to see these one time passwords, you need to install the Yubico Authenticator on any phone or computer you want to be able to access these codes from. The application itself doesn't store anything, and merely sends the Yubikey the current time and date so it can in turn generate the current one-time password.
Most services that use OATH TOTP for their second auth factor give you QR codes containing otpauth:// URLs that you can then scan with your phone or input manually in the app (or take a screenshot of when using the desktop authenticator). Those URLs and/or QR codes are usually not shown to you again after you've completed the registration process (unless you deactivate it later), so make sure to register all your backup keys/devices and maybe even store a printed backup sheet of those somewhere safe before you move on with the registration process.
So having a USB key fob that you can use to identify with computer systems is cool and all, but a far older and much better established system for doing exactly this, especially in corporate or governmental settings, is to simply have chipped ID cards. Among all the things the "fully-fledged" Yubikey models pretend to be is a PC/SC card reader containing a Yubico-brand smart card.
That virtual smart card supports two protocols: Yubico PIV and OpenPGP (three if you count ykOATH, which is how the Yubico Authenticator manages One-time passwords on the key, but that's more of a technicality than a feature).
[limit: 24 slots (4 active, 20 retired), either RSA 2048 or ECC secp256r1]
I know literally nothing about what that is or how it works, so I'll refrain from going into details. If you're interested in that feature, you probably already know how it works.
[limit: 4 slots (Authentication, Decipher, Signature & Attestation), up to 4096 bits each]
[...except on the Yubikey 4 FIPS, where it's just 2048 bit according to section 2.4.6 of the technical manual]
[...and the Yubikey 5 FIPS which doesn't support OpenPGP at all]
This one might be more familiar to people. OpenPGP is commonly used to sign emails and code and software releases to ensure that the person who claims to be the originator of something is actually who they claim to be.
I'll also not be going into a whole lot of details, here, since this is again a feature that, if it interests you, you probably know how to set it up better than I do.
A note about firmware versions, though:
- Firmwares before 5.2.3 (including all models before Yubikey 5) are apparently considered version 2.0 OpenPGP smartcards.
- Firmware 5.2.3 and up (starting around november 2019) instead go up to version 3.4 of the protocol.
- This lets them support a bunch of extra encryption algorithms.
[limit: 2 slots (short touch & long touch)]
A lot of people end up puzzled when they get their first Yubikey and press the contact unprompted, causing it to rapidly type a bunch of garbage and then enter. Something like...
cccccctuitkrduvitercbehcfurvbgjlubbbnkcirnhn
cccccctuitkrgfdgvbriudunbhfrckvtulijkrbuchbd
cccccctuitkrrtbniftgdehgfcdcrdkhfbcekjkchcef
...and so on, the exact value differs every time.
Don't worry, you can disable that.
These are called Yubico OTP and apparently go back to some of the very first yubikeys (which look surprisingly similar to the recent ones, in a wierd and kind of cool way) in 2008-2010.
They are part of the "virtual keyboard" type of passwords, which, in my opinion, make for the least interesting part of what recent Yubikeys have to offer, mainly due to how you're limited to only having two of them and how the long slot (holding the contact between 3 and 5 seconds) is a bit cumbersome to use.
The main problem wih these is that keyboards don't have every key in the same place across countries, and it's doubly awkward in that the way keypresses get translated into symbols is not up to the keyboard itself but the computer configuration. This means any password the Yubikey types out like this is also not actually guaranteed to work regardless of what computer you plug it in.
In order to mitigate the keyboard layout problem, one of the solutions Yubico came up with is to limit the "automatically generated" passwords to a set of 16 letters that don't move around too much across keyboard layouts. This reduced alphabet, called "Modhex", works on a fair amount of keyboard layouts across various countries.
After crunching some data and making some tests, it seems to be compatible with:
- Almost any kind of QWERTY (used across a variety of countries and languages with latin alphabets)
- NOT Turkish QWERTY (because the "i" key is always dotless)
- German QWERTZ
- French AZERTY
- Breton C'HWERTY (TIL that's a thing)
- Korean, Japanese and Chineese QWERTY-based layouts
Notably, it doesn't work on the "ergonomic" layouts (Dvorak, Coleman, BÉPO, etc.) and keyboards meant to input non-latin languages (Greek, Arabic, Russian, Hebrew, Hindi, Bulgarian, Armenian, Lao, Tamil, etc). Yubico has a few methods to try and remedy this if this is your case.
[limit: 32767 "sessions" with up to 255 OTPs generated per session]
The Yubico OTP shares an advantage with OATH one-time password codes that shouldn't be overlooked: They don't need the client to be anything special. With U2F and FIDO2, the browser has to support interfacing with USB devices, some fairly recent Javascript interfaces and then the web page needs to go through a somewhat involved procedure to do all the negociation and log you in. This is new to a lot of web developpers, and it's possible to get it wrong.
With something like the Yubico OTP, on the other hand, the complicated bits are all on the server. The server can then just take the OTP and validate it with either the Yubicloud service or a custom equivalent. This makes it so any old login form can be upgraded to support this kind of 2FA with a simple "Type in your password, then touch your Yubikey instead of pressing Enter" instruction message. It's kind of a form of vendor lock-in, though, so that never really caught on with most websites, but it has its uses.
The specific one-time password your Yubikey comes with starts with cc, which makes it special in that it is factory-configured on the short slot by Yubico and pre-registered on their YubiCloud service and you can never create an OTP with the same prefix (yours will instead always start with vv).
This makes it the only part of the key that can never truly be reset to factory default.
Yubico OTPs are generated both by measuring the time since the key was plugged in as well as by counting the number of OTPs generated since the timer started. The Yubikey also keeps a counter of how many times it has been powered on ("sessions"), which is also accounted for to verify that an OTP is more recent than the last one, to prevent someone from reusing old OTPs (in what's called a "replay attack"). That last point is important because the counter saturates at 32767 sessions and, as mentionned by the documentation, this will cause Yubico OTPs on either slot to no longer be valid until the OTP application is globally re-configured. As they themselves point out, though, at 5 "sessions" per day, 365 days a year, it would still take about 18 years to get to that point.
[limit: 64 modhex characters or 38 keypresses]
You can also just configure the Yubikey to generate and enter the same password for you every time, a "password minus the one-time", which makes it into... kind of a lame alternative to what Firefox and Chrome are even doing for you nowadays.
It does have the benefit of being compatible with everything, I guess, but... At least use a password manager or something instead! There's Keepass, 1password, LastPass, BitWarden- and those are just the ones I could remember on top of my head while typing this line!
[limit: 63 bytes long challange]
That one does not actually type anything, but it still takes up one of these two slots, so I'm putting it in the same section.
Whenever you need to login using that method, your computer opens a file with a code it already knows how the key would reply to and sends it to the key. If the key responds with the expected message, the computer can then generate a new code at random and ask the Yubikey what it woud respond to that code, so that both can be saved for next time. It's a bit of a "one-time shared secret" in that regard.
The two-way communication and lack of actual text being typed make these unfit for anything that needs to communicate with a server. That's why you'll mainly see it used on Linux login guides (even though U2F works perfectly fine and doesn't take up one of those precious two slots) or used as a master password on some password managers.
Oh, right, I almost forgot about that.
The short-touch/long-touch thing doesn't really work with NFC, so one of the two slots has to be selected to be the one that NFC readers will pick-up when not actively attempting to use FIDO or OATH. By default, it's a URL that looks like https://my.yubico.com/yk/#[OTP HERE].
That's one point that should probably be stressed: Nothing that is stored on the key can ever be extracted back.
One of the reasons why you're often told to buy these in pairs is that the only way to create a spare Yubikey is to go through the exact same registration steps with the second Yubikey as you did with the first one.
Once you've saved, say, an OATH TOTP on your first Yubikey; if you don't immediately get rid of the QR code or URL you used to add that account, it means anyone who finds it can just completely bypass the Yubikey with it. It can be a good idea to print these QR codes and keep them in a safe or somewhere secure as an ultimate backup, but if you don't have that, then you have no way to register that TOTP on your second Yubikey afterwards. The same goes for everything else on the key: Webauthn decryption keys, Webauthn resident credentials, GPG private keys, etc.
You would think those are just rebrands of older models, but they do charge extra for these, don't they?
If you do not have a security auditor, and/or the auditor does not have a compliance requirement, you probably do not need FIPS. The standard line of YubiKeys offers the same security, algorithms and functionality. The standard line also evolves at a much more rapid pace because it does not need to go through an exhaustive validation process, which commonly takes a year or more. Yubico can release standard firmware with new features, enhancements, etc. at any time, whereas FIPS-certified products must go through the FIPS validation process every time there is a change.
Certification aside, they do have a few differences with the regular keys they:re based on:
- Both the Yubikey 4 FIPS and the Yubikey 5 FIPS can be put into FIPS-approved mode, which basically makes it so the credentials on the key can only be managed anr/or frozen using an Admin PIN.
- Yubikey 4 FIPS has a worse support for OpenPGP
- Yubikey 5 FIPS has no support for OpenPGP
- Yubikey 4 FIPS can have its U2F mode reset (which can't be done on the normal Yubikey 4)
- This, along with overwriting the key used for U2F, deletes the pre-loaded attestation certificate (see section 2.5.5 of the manual), which permanently makes the key un-FIPS-able.
No, not since the release of the Yubikey 4. The Yubikey NEO was a JavaCard-compatible security key that let you update and install the applets loaded on it, but it came with the caveat that a bad firmware update would be an additional way to compromise the device. On the newer, "sealed" models, if an exploit is found on the firmware, Yubico will usually send updated replacement keys.
Not really, but technically, yes.
When using your yubikey for 2FA, an hypothetical attacker knowing your username and password and being next to you could scan the second factor right out of your pocket, though the chances of a scenatio like this are slim unless you're the sort of person who tells his passwords out loud at press conferences.
When using it for passwordless authentication, though, you might want to be mindful of websites that don't require PINs to login, since the NFC tap on its own is considered equivalent to pressing the button in USB mode. If the website does not require a PIN to ensure that you're the person who initiated the operation, that could be used to login as you without your knowledge.
Mind you, it still requires that the attacker be close enough to you to scan the Yubikey and for them to know in advance what websites are registered for passwordless login on it (since you actually do need the PIN to enumerate these).
If it can put your mind at ease, the NFC-enabled yubikeys still allow you to disable the NFC interface for each individually supported protocol.
How am I supposed to keep my backup Yubikey in a safe place if I need it to register new websites on it?
There's not really an easy way. How you manage your backup is ultimately up to you (disclaimer: I haven't bought a backup yet), but it's kind of assumed that every new account you care about enough to have 2FA/passwordless on will be worth retrieving your backup key to register it on this one as well.
With that said, there is a proposed WebAuthn extension (it's a long way off, don't hold your breath) that aims to allow defining one key as the backup of another, so that you can more or less register both the backup and the primary without needing to actually have the backup on you. It wouldn't solve the "making a backup later" part, but it would avoid needing to take the backup out of its hiding place every time you need to register to a new website.
A few people will hear about the "8 incorrect PIN attempts before all your FIDO2 and U2F credentials get reset" limit and get really stressed out about it. Or a malicous program could technically run the authenticatorReset command instead of authenticatorGetAssertion, causing the gold contact to wipe the key instead of logging you in (but only if this is the first action taken after plugging it in). You never know, after all!
And... yeah. It just works that way. I guess it just highlights that you really should keep backups of these if you intend to use them seriously.
With that said, the two "virtual keyboard" slots let you set a configuration protection access code, but those are the only ones that do. You'll also end up with the opposite problem if you ever end up forgetting that password.
No, and you're likely to encounter applications that don't check for NFC on PC. With USB and Bluetooth, there's the common HID protocol that allows for things like computer mice and game controllers to work exactly the same way regardless of whether they're used wired or wirelessly (so long as the developpers remember that the protocol exists which, as anyone who has tried to use a wireless PS4 controller on PC can tell you, is a pretty common thing to forget). This is what applications normally use to communicate with FIDO authenticators, so it's easy to support both USB and bluetooth at the same time.
NFC wasn't really designed to do any of the things that bluetooth does (there are a lot of reasons why NFC mice are not a thing), it was always meant to be more of a complement. Since NFC doesn't support HID, that means browsers and other FIDO applications need to have dedicated logic to support it, and on PC it's enough work that neither Chrome nor Firefox supports it.
Likewise, you can't have a virtual keyboard over NFC (keyboards are also HID), so the Yubikey pretends to be an NFC tag that sends a new URL or text snippet each time it's read.
Yubikeys are pretty sturdy for what they are, but they're definitely not unbreakable. With the "not-nano" models in particular, when connected with the button facing up or down, the USB connector can receive a huge amount of mechanical stress if the key is attached to a keychain that is the least bit heavy or has something pulling it down. If you browse /r/yubikey, you'll see reports of someone who's had the connector snap because of something like that on a pretty regular basis.
If you were hoping to use NFC as a backup in case this happens, take another look at the circuit board on the Yubikey 5 NFC. The NFC coils on the back run along the underside of the USB connector, so if that part breaks off, you'll lose both.
Regarding the rest of the key, Yubico seem pretty confident in how much misuse they can withstand. I've only just got mine, though, so I can't speak personally for how ultimately durable it is.
Shallow scratches on the gold-plated USB contacts are apparently expected and perfectly fine.
I wasn't sure myself, given it's a brand and everything, but the company's CEO and founder uses it all the time, so... I guess?
- The Yubico doc
- The CTAP2 and WebAuthn doc
- https://www.imperialviolet.org/2018/03/27/webauthn.html
- https://paulstamatiou.com/getting-started-with-security-keys/
- https://medium.com/webauthnworks/verifying-fido2-responses-4691288c8770
- https://blog.mozilla.org/blog/2020/08/20/password-security-part-iv-webauthn/
Awesome. Thank you!