What's the risk from fake Yubikeys?(shkspr.mobi)
shkspr.mobi
What's the risk from fake Yubikeys?
https://shkspr.mobi/blog/2022/03/whats-the-risk-from-fake-yubikeys/
15 comments
The attack you're describing doesn't require wifi. If the victim visits the attacker's page, the attacker page is free to request signatures (also non-presence-attesting signatures) from the key. This can be used to send data to the key (in the nonce) and from the key (the signature is nondeterministic). I don't know if this can be done without user's awareness in the new web api for security keys, though.
How can it protect from cloned hardware? Ie. they get keys, clone them, sell at discount - and sell shipment address + software/hardware backdoor on the side.
Whoever cloned the hardware would need to know the private key Yubico embed in it, and those aren't east to extract, although presumably feasible for cutting edge chip reverse engineering labs.
Here's an example from 2018 of someone trying to extract secrets from a Yubikey. https://duo.com/labs/research/microcontroller-firmware-recov.... Seems they don't get very far. Or it's at least very laborious. But as you say, who knows what a cutting edge lab can do. Skimming the web, it seems like people have had more success with things like Google Titan keys.
If you are interested in this topic, the physical security chapter of Ross Anderson's Security Engineering has a nice intro. The second edition is free online https://www.cl.cam.ac.uk/~rja14/book.html
That's not a yubikey but a standard pic microcontroller not designed for security applications.
And as far as I understand he's now describing his methods there rather than particular attempts?
And as far as I understand he's now describing his methods there rather than particular attempts?
There's a bit about Yubikey at the very end of the article.
To do FIDO the Yubikey has a symmetric (typically called "secret" but here it isn't really functioning as a secret since nobody else knows what it is) key but not a private key baked inside it.
Hiding such symmetric keys (typically AES) from adversaries with fairly large budgets who have physical access to your device is already a thing. Would I bet my life on it if I was Edward Snowden? Maybe not. Am I comfortable with this for securing a bank account with my life savings in it? Yes.
Hiding such symmetric keys (typically AES) from adversaries with fairly large budgets who have physical access to your device is already a thing. Would I bet my life on it if I was Edward Snowden? Maybe not. Am I comfortable with this for securing a bank account with my life savings in it? Yes.
Out of curiosity, why are keys not generated upon first run? Why is there something to extract out of a brand new YubiKey to begin with?
For FIDO, which was the main topic of the original post, the Yubikey has a symmetric key inside it.
Choosing a random new key invalidates all your existing credentials enrolled with that Yubikey, since your Yubikey will no longer be able to decrypt the identifier provided and sign proof that it knows the associated private key (in practice what it decrypted was your private key for that account, and now it can't do that)
This "reset" operation is supported on Yubikeys, and you perhaps should do it when you get the key (Don't do it now! It invalidates your credentials as I described!), although most users probably don't. However, even if you do this if your key is fake why would the initialisation actually work? The same adversary could modify it to just ignore this reset attempt and use a symmetric key they know. So there is no benefit from hypothetically requiring you to perform this initialisation step, nor from having the device do it when first used.
Choosing a random new key invalidates all your existing credentials enrolled with that Yubikey, since your Yubikey will no longer be able to decrypt the identifier provided and sign proof that it knows the associated private key (in practice what it decrypted was your private key for that account, and now it can't do that)
This "reset" operation is supported on Yubikeys, and you perhaps should do it when you get the key (Don't do it now! It invalidates your credentials as I described!), although most users probably don't. However, even if you do this if your key is fake why would the initialisation actually work? The same adversary could modify it to just ignore this reset attempt and use a symmetric key they know. So there is no benefit from hypothetically requiring you to perform this initialisation step, nor from having the device do it when first used.
[deleted]
Or whoever manufactured the Yubico chip in the first place.
I wonder if you could mitigate that by manufacturing them without a private key and then have Yubico themselves program the keys (in one-time programmable memory) before shipping to the customer.
That's infineon for the latest generation:
http://www.hexview.com/~scl/neo5/
http://www.hexview.com/~scl/neo5/
Well, considering that Yubikeys can generate crypto keys (for SSH, PGP, etc.) on device, I assume it would be possible for a fake one to use a backdoored/weak random number generator so that encryption/authentication based on these keys could be broken...
Another potential attack (for those who use them to store keys created on another device), would be to have a way, for an attacker that would steal your (fake) Yubikey, to get back the secret key (which is normally impossible/hard on a genuine Yubikey).
Another potential attack (for those who use them to store keys created on another device), would be to have a way, for an attacker that would steal your (fake) Yubikey, to get back the secret key (which is normally impossible/hard on a genuine Yubikey).
Tangential but IMO it's almost always better to generate the private key off-device and store it somewhere securely. It doesn't matter when the Yubikey gets lost because you'll be revoking the GPG key, but when you accidentally destroy your Yubikey, it's convenient to be able to set up a new Yubikey without generating a new GPG key and changing it everywhere.
Doesn't taking the key off the device sort of defeat the purpose?
This is bad advice, for precisely the reason you've described. It should not be possible to sign things with a key that has been ostensibly destroyed.
If you need to be able to recover from a destroyed key, you should either (a) repeat your initial trust process, or (b) prematurely attest to a second key using your first one.
If you need to be able to recover from a destroyed key, you should either (a) repeat your initial trust process, or (b) prematurely attest to a second key using your first one.
> ... generate the private key off-device and store it somewhere securely.
Doesn't even have to stored securely if it is protected with a strong passphrase. You can keep it anywhere. ... and with contemporary versions of GPG that might only have to be 4 diceware words.
For PGP stuff, the advantage of something like a Yubikey is that the unencrypted private key is never exposed to a possibly insecure end device. The actual cryptography is done on the Yubikey. This is a somewhat different situation than with other uses where the Yubikey only protects the secret information.
Doesn't even have to stored securely if it is protected with a strong passphrase. You can keep it anywhere. ... and with contemporary versions of GPG that might only have to be 4 diceware words.
For PGP stuff, the advantage of something like a Yubikey is that the unencrypted private key is never exposed to a possibly insecure end device. The actual cryptography is done on the Yubikey. This is a somewhat different situation than with other uses where the Yubikey only protects the secret information.
Strong disagree on that.
That means the key has existed in RAM, which largely defeats the point of it being HW based.
The point of HW based is that no matter what, if a key is not connected then it is not used to auth. If it requires touch then all the hackers in china cannot auth using it, without getting on a plane and breaking in.
You should have a backup hardware device, and for GPG subkeys or something.
That means the key has existed in RAM, which largely defeats the point of it being HW based.
The point of HW based is that no matter what, if a key is not connected then it is not used to auth. If it requires touch then all the hackers in china cannot auth using it, without getting on a plane and breaking in.
You should have a backup hardware device, and for GPG subkeys or something.
That's why the standard recommendation is to generate keys on an airgapped computer without persistent storage, and run keytocard from there.
I have a set of dead Yubikey 4s that are blacklisted from GitHub because the onboard key generation code generated insecure keys (nevermind that I didn't use that feature, but wygd).
I have a set of dead Yubikey 4s that are blacklisted from GitHub because the onboard key generation code generated insecure keys (nevermind that I didn't use that feature, but wygd).
The overarching best practice is to reduce the number of points of compromise/failure to a bare minimum: if your trusted hardware can generate its own keys, then you shouldn't establish a separate trust relationship with a different machine to generate keys that get imported into your trusted hardware.
It’s a little odd to me that the author hopes FIDO keys as a single factor is rare. This is explicitly supported by FIDO and Yubico, and available in the Microsoft ecosystem (https://support.microsoft.com/en-us/windows/sign-in-to-your-...)!
As tomxor said elsewhere here, though, batch attestation allows you or relying parties to check that the key is a “real” Yubico key.
As tomxor said elsewhere here, though, batch attestation allows you or relying parties to check that the key is a “real” Yubico key.
It's available, but in practice it is almost never used without very robust backup factors because the support overhead from people losing their keys would be immeasurable. Much easier to bind people to phone numbers, despite them being really bad identifiers.
(Author here) I hoped it was rare because it seems like an obviously bad idea. I can see how it would be convenient - but that's often the opposite of secure.
I wonder where it would make sense though?
I wonder where it would make sense though?
Passwordless login doesn't necessarily mean a physical separate dumb key, it can have many implementations that make sense:
1. WebAuthn (current spec) is also implemented by Android, iOS macOS and Windows 10/11 (natively); that makes your device a possible "passwordless factor holder". You then essentially tie your authentication with your device passcode and/or biometric ID, similar to what a password manager would do, except there's no password to steal.
2. YubiKey BIO supports biometric authentication (I presume with on-board fingerprint verification) to use the device's keys. So it's essentially a biometric-protected private key.
3. IIRC some hardware crypto wallets can act as WebAuthn devices and display the website domain when asking you to touch it. Maybe they support passcode protection?
4. Even if you were to use a "raw" WebAuthn key stored on your computer (on TPM, Secure Enclave, or even filesystem) -- if you protect it with a password, you essentially have pubkey authentication with a second factor of password.
1. WebAuthn (current spec) is also implemented by Android, iOS macOS and Windows 10/11 (natively); that makes your device a possible "passwordless factor holder". You then essentially tie your authentication with your device passcode and/or biometric ID, similar to what a password manager would do, except there's no password to steal.
2. YubiKey BIO supports biometric authentication (I presume with on-board fingerprint verification) to use the device's keys. So it's essentially a biometric-protected private key.
3. IIRC some hardware crypto wallets can act as WebAuthn devices and display the website domain when asking you to touch it. Maybe they support passcode protection?
4. Even if you were to use a "raw" WebAuthn key stored on your computer (on TPM, Secure Enclave, or even filesystem) -- if you protect it with a password, you essentially have pubkey authentication with a second factor of password.
Almost anywhere? It's much more convenient than the "type in your username" step.
To be clear: Things you can do with FIDO2 include:
* Just a "second factor". The authenticator has no memory of who it is, RPs (Relying Parties, e.g. web sites) basically provide prompts, which they derive from looking up a username you entered. The RP says if this is tialaramex, you'll recognise this arbitrary ID you gave me when enrolling and sign this freshness proof. The authenticator checks if it recognises the ID and if so retrieves the private key and signs the message, voila.
* "Passwordless". The authenticator is behaving the same, but now the RP is only taking a username first, there may be no second factor. This is more secure than most passwords today, but is only a single factor.
* "Usernameless". The authenticator now needs to remember every RP it has enrolled with, because the RP won't prompt it. Given the name of an RP (e.g. "news.ycombinator.com" the authenticator needs to replay the ID it gave when enrolling, and sign a freshness proof "I'm still, uh, tialaramex apparently".
In a corporate environment, or perhaps banking, you can insist (via a thing called "Attestation") that the authenticator provides proof it is a real authenticator made by, e.g. Yubico and based on that claim trust it to do multi-factor authentication itself.
Yubico's cheaper products do PIN auth, so you touch the sensor and type in say, "MyFuckingSecret" as PIN, the PIN is not sent to the Relying Party, they just get a message saying "Here's proof I'm that Yubico Yubikey which enrolled, and I say this is still the same human who enrolled me, I checked using a method my vendor says is suitable".
Yubico's most expensive product, and the Google Pixel series, and some iPhones, use a fingerprint as their additional factor. Again though, the authenticator just says "I promise I checked, this is who made me, trust or don't" it doesn't send fingerprints anywhere.
To be clear: Things you can do with FIDO2 include:
* Just a "second factor". The authenticator has no memory of who it is, RPs (Relying Parties, e.g. web sites) basically provide prompts, which they derive from looking up a username you entered. The RP says if this is tialaramex, you'll recognise this arbitrary ID you gave me when enrolling and sign this freshness proof. The authenticator checks if it recognises the ID and if so retrieves the private key and signs the message, voila.
* "Passwordless". The authenticator is behaving the same, but now the RP is only taking a username first, there may be no second factor. This is more secure than most passwords today, but is only a single factor.
* "Usernameless". The authenticator now needs to remember every RP it has enrolled with, because the RP won't prompt it. Given the name of an RP (e.g. "news.ycombinator.com" the authenticator needs to replay the ID it gave when enrolling, and sign a freshness proof "I'm still, uh, tialaramex apparently".
In a corporate environment, or perhaps banking, you can insist (via a thing called "Attestation") that the authenticator provides proof it is a real authenticator made by, e.g. Yubico and based on that claim trust it to do multi-factor authentication itself.
Yubico's cheaper products do PIN auth, so you touch the sensor and type in say, "MyFuckingSecret" as PIN, the PIN is not sent to the Relying Party, they just get a message saying "Here's proof I'm that Yubico Yubikey which enrolled, and I say this is still the same human who enrolled me, I checked using a method my vendor says is suitable".
Yubico's most expensive product, and the Google Pixel series, and some iPhones, use a fingerprint as their additional factor. Again though, the authenticator just says "I promise I checked, this is who made me, trust or don't" it doesn't send fingerprints anywhere.
Why is it an obviously bad idea? It reduces login to a single factor of a physical object you possess, but for many people that's probably good enough. I mean, most people's physical houses are only protected by a physical key with single factor authentication and nobody seems to mind that.
I guess for physical keys, it means you losing it instantly triggers anyone with it access to your M$ account, so eg. TSA could take it from checked luggage, plug it in, and go snooping through your email. Webauthn on Windows via regular TPM is good in that it's not really tied to the computer's cryptographic key, it requires some wrapped data stored by Windows as well (when I reinstalled Windows 11->Windows 11 from scratch none of my Webauthn logins worked, it was like I had a new key entirely).
The physical keys I have require a PIN to be entered before they function. I haven't looked into the specifics but it's possible the token denies attempts after a certain number and possibly deletes itself after a certain number of attempts fail in a row.
How would this differ from using an SSH key? Don't we do this all the time? Given prior authorization to add the factor, it is afterwards used on its own to authenticate.
> Other than the risks inherent in any USB device, what's the worst that could happen? A cloned device might let an attacker have a duplicate key. But that's useless unless they also have your username and password.
So if this isn't a risk ("it's useless") then doesn't that automatically imply that there are no benefits of using a Yubikey?
edit: To add, this comment is in reply to the final question of the article "What's the worst thing that can be done with a compromised Yubikey?".
My answer being, the risk would be that you think you are using 2FA but you "aren't".
So if this isn't a risk ("it's useless") then doesn't that automatically imply that there are no benefits of using a Yubikey?
edit: To add, this comment is in reply to the final question of the article "What's the worst thing that can be done with a compromised Yubikey?".
My answer being, the risk would be that you think you are using 2FA but you "aren't".
You are using 2FA. If just one of your two factors is compromised, that doesn't mean you "aren't" using 2FA - just that there exists an attacker who is one step closer to breaking into your account.
Any attack on 2FA requires the same attacker to compromise your password and your physical device. If one adversary phishes your password and someone else finds the YubiKey you dropped on the train, you're almost certainly still OK. You need to ask whether there's a reasonable threat model where the same guy gets your password and also gets you to use his own fake key.
Any attack on 2FA requires the same attacker to compromise your password and your physical device. If one adversary phishes your password and someone else finds the YubiKey you dropped on the train, you're almost certainly still OK. You need to ask whether there's a reasonable threat model where the same guy gets your password and also gets you to use his own fake key.
> the same guy gets your password and also gets you to use his own fake key.
The article started from an event happening at a conference. I haven't been at many, but I assume: 1) at some you have a badge identifying you; 2) even if you don't, depending on who you are, it could be easy to identify you from other sources. At that point, if your identity is revealed and you're using the fake token, you're no longer using 2FA. This is not the same as "some guy finding your lost token on a train", unless, of course, that person saw you losing it and knows who you are, but even then - if you lose your token, you wouldn't/shouldn't keep using your spare...
I mean, if you get a notification from HIBP that some password has been compromised on some account, I assume you'd change it, you wouldn't just go "meh, I have 2FA, why bother". Why would you ever keep on using a (potentially) fake Yubikey?
The article started from an event happening at a conference. I haven't been at many, but I assume: 1) at some you have a badge identifying you; 2) even if you don't, depending on who you are, it could be easy to identify you from other sources. At that point, if your identity is revealed and you're using the fake token, you're no longer using 2FA. This is not the same as "some guy finding your lost token on a train", unless, of course, that person saw you losing it and knows who you are, but even then - if you lose your token, you wouldn't/shouldn't keep using your spare...
I mean, if you get a notification from HIBP that some password has been compromised on some account, I assume you'd change it, you wouldn't just go "meh, I have 2FA, why bother". Why would you ever keep on using a (potentially) fake Yubikey?
But the author argues, and sets up the following scenario:
>A cloned device might let an attacker have a duplicate key. But that's useless unless they also have your username and password.
That even in case there is a cloned device, it's not an issue because you still have your password.
>A cloned device might let an attacker have a duplicate key. But that's useless unless they also have your username and password.
That even in case there is a cloned device, it's not an issue because you still have your password.
Or the USB device could turn into literally anything else, from an ethernet interface to a keyboard. This is a classic case of overthinking your threat model and missing the more obvious attack vectors.
And for enterprises that want to make sure people enroll with genuine keys (as they sometimes also use these keys as physical access tokens), they can already use the factory-set OTP slot (the one with the cc instead of vv code) to check if a token is actually from Yubico.
And for enterprises that want to make sure people enroll with genuine keys (as they sometimes also use these keys as physical access tokens), they can already use the factory-set OTP slot (the one with the cc instead of vv code) to check if a token is actually from Yubico.
So much confusion around this topic out there. Not helped by the fact that there's distinction between Security Keys by Yubico and Yubikeys. Security Keys can't do much other than FIDO2.
Yubikeys on the other hand are split into old ones that did have smartcard functionality unlocked so you could upload your applets into and newer ones which are locked. Locked ones are only marginally easier to tamper with than proper smartcards, nearly impossible to be worth it for anyone than state actors.
If you have any proof of it happening anywhere, then show me a source. Closest I have is this https://ninjalab.io/wp-content/uploads/2021/01/a_side_journe..., which is about Google Titan aka reskinned FEITIAN ePass NFC with some functionality turned off
Yubikeys on the other hand are split into old ones that did have smartcard functionality unlocked so you could upload your applets into and newer ones which are locked. Locked ones are only marginally easier to tamper with than proper smartcards, nearly impossible to be worth it for anyone than state actors.
If you have any proof of it happening anywhere, then show me a source. Closest I have is this https://ninjalab.io/wp-content/uploads/2021/01/a_side_journe..., which is about Google Titan aka reskinned FEITIAN ePass NFC with some functionality turned off
> A Yubikey can be hacked to send arbitrary keystrokes - but that's of limited usefulness. I guess an attacker could force open a browser window to download malicious software, but that would be fairly obvious to a user.
If it can send arbitrary keystrokes, it's not just a "way in" (trying to download malicious software): it's also a way to exfiltrate the data (for example keylogged inputs) it collected.
As for being fairly obvious to the user: what about waiting for command+t (or whatever the command is) plus something looking a website to be typed, then wait for 4 minutes of user inactivity (no keyboard input, no mouse input) before sneakily opening a tab and quickly closing it? Sure, some user may notice it but many won't for after 4 minutes of inactivity they won't be looking at their screen (and the screensaver won't have kicked in already).
If it can send arbitrary keystrokes, it's not just a "way in" (trying to download malicious software): it's also a way to exfiltrate the data (for example keylogged inputs) it collected.
As for being fairly obvious to the user: what about waiting for command+t (or whatever the command is) plus something looking a website to be typed, then wait for 4 minutes of user inactivity (no keyboard input, no mouse input) before sneakily opening a tab and quickly closing it? Sure, some user may notice it but many won't for after 4 minutes of inactivity they won't be looking at their screen (and the screensaver won't have kicked in already).
Not to say such attack scenario does not exist, but:
A USB HID device cannot listen on what other keyboards typed, except for NumLock/CapsLock/ScreenLock indicator.
A USB HID device cannot listen on what other keyboards typed, except for NumLock/CapsLock/ScreenLock indicator.
USB isn't a party-line bus. An HID can't see anything from other branches of the USB subsystem. State changes have to be explicitly relayed by the host.
Agreed. The OP is overly optimistic in their assessment. A rogue USB device which can enter input, is pretty much game over. It can do anything on your computer that a physical user can. Phoning home and installing a boatload of malware before you can even blink would be a good start.
Windows users in particular have been conditioned to not react to evil things like autoplay when inserting USB devices. "Don't mind me, I'm just installing drivers". I've seen USB headphones (!) launch programs on first insert. By the time you click "cancel", any number of things could have happened.
Windows users in particular have been conditioned to not react to evil things like autoplay when inserting USB devices. "Don't mind me, I'm just installing drivers". I've seen USB headphones (!) launch programs on first insert. By the time you click "cancel", any number of things could have happened.
If a duplicate code generating tool isn’t a risk factor then the second factor isn’t that important at all.
It’s obviously a risk factor and one that should be considered - especially if you consider a targeted attack against a particular person.
It’s obviously a risk factor and one that should be considered - especially if you consider a targeted attack against a particular person.
Why should I buy a Yubikey with its closed-source firmware, when OnlyKey and Nitrokey offer open-source firmware (that get updates) for a similar price?
While I'm not a fan of closed-source firmware, there's something nice about the firmware being indelible.
Eh. In the case of OnlyKey, they can ship a version without all the encryption to get past customs or whatever in places that ban it, and you easily flash your own over it. If the firmware is immutable you can't do this--or fix bugs, or add new features--which could turn them into e-waste sooner.
It is impossible to load compromised firmware on a Yubikey after it has been manufactured. You can't say that for OnlyKey.
One laptop contains more e-waste than dozens (hundreds?) of Yubikeys, so there's much lower hanging fruit on that tree.
One laptop contains more e-waste than dozens (hundreds?) of Yubikeys, so there's much lower hanging fruit on that tree.
Who is to say the NSA or other agency didn't load a compromised firmware from the factory. With OnlyKey, I can build and load the firmware myself so I wouldn't need to trust it.
Because I want a small form factor USB-c key that I can leave in all the time.
I'd break the OnlyKey within a few weeks.
I'd break the OnlyKey within a few weeks.
Having an OnlyKey go through the wash and riding through the rain on my motorbike and sloshed in my pockets for years, I don't think it's going to “break”. Also they do offer a slim USB-C version (https://onlykey.io/collections/all/products/onlykey-duo-dual...) so I’m not really sure what you’re going on about.
My yubikeys were sent in an envelope identifying its content, I thought it wasn't a smart move at the time :/.
If you're at risk...
Yubikeys are exceptionally bad targets to intercept and modify if someone wants to send you an implant. It's more likely they'll get you with the next mass storage device or data cable you buy on Amazon.
Yubikeys are exceptionally bad targets to intercept and modify if someone wants to send you an implant. It's more likely they'll get you with the next mass storage device or data cable you buy on Amazon.
You'd have to be an NSA-level target for them to take a Yubikey out of the mail stream and modify it. And at that point you're going to have all sorts of worse things to worry about.
Totally agree, anything with a (big) firmware or mass storage looks like a better device to compromise.
[deleted]
Do these keys work well under FreeBSD?
I don't run FreeBSD, so perhaps a FreeBSD user with a Yubikey will chime in, but as I understand it FreeBSD has Firefox and OpenSSH, and both these programs can use the FIDO feature (which is the focus of the article) on a USB Yubikey to authenticate you successfully to a remote system so it ought to work out of the box on up-to-date software.
The other features like using it to store PGP keys are a bit more fiddly to set going and you may need to read instructions specific to FreeBSD for those.
The other features like using it to store PGP keys are a bit more fiddly to set going and you may need to read instructions specific to FreeBSD for those.
Yes I use mine on FreeBSD in OpenPGP mode. Fido mode I didn't test because Firefox doesn't do password less Fido (still....) And I never use Chrome
They are just a "keyboard" as far as the hardware is concerned. If your OS can support a generic USB keyboard they will work fine.
Only the weird Yubico-specific OTP thing is a keyboard. The FIDO features are HID (Human Interface Device, the USB protocol for keyboards, mice, etc.) but they are not keyboards, when asked what sort of thing they are in HID they say they are 0xF1D0 ie FIDO devices, which means software looking for them can find them in order to speak the FIDO sub-protocol. I presume the PGP key stuff similarly uses its own standard protocol.
It shows up as a CCID reader with a card attached for PGP stuff.
It’s worth mentioning that, although hardware keys are increasingly supported, if they are not available, there are usually fallbacks to less secure factors, such as email or phone numbers.
What’s the point of a hardware key then, if email also works?
What’s the point of a hardware key then, if email also works?
It is sometimes possible to register at least two hardware keys with a particular online service, and then specify that you want the other fallbacks to be disabled.
So legit though... How are any of these solutions that much better than a tiny book of passwords if your place of living is secure? SSH pass phrases, writing down randomly generated passwords, etc.
How secure is your place of living? If the police break down your door at dawn and arrest you in your pajamas, do you have a chance to snatch up your book of passwords and swallow it before they put the zip ties on?
Sure. But I also append a few chars to everything written down so they wouldn't be able to do anything with the passwords if they had them.
It also helps I don't do anything that would be on their radar crime-wise, at least compared to the general populus.
But also don't put steel bars on my windows, sleep with a gun under my pillow, or put ring security cameras around my house.
It's all about threat modeling.
It also helps I don't do anything that would be on their radar crime-wise, at least compared to the general populus.
But also don't put steel bars on my windows, sleep with a gun under my pillow, or put ring security cameras around my house.
It's all about threat modeling.
What stops someone from stealing my Yubikey and using it the same as a book of passwords?
The key proves you have it physically in your possession. It cannot be phished, nor stolen without you being aware.
There are a number of hardware security keys: OnlyKey, SoloKey, NitroKey, Google Titan and Yubikey?
Can someone compare these?
Can someone compare these?
Pardon the domain.
https://www.buybitcoinworldwide.com/dongle-auth/dongles/
Personally:
- NFC Yubico with my car keys. I can't remember ever using NFC to authenticate directly on mobile, but I like having a hardware backup for time-based one-time password (TOTP) codes. (Google Authenticator / Android)
- Tiny Solos (Somu[1]) live in my keyboard, laptop ports for "touch to login" (universal 2nd factor, U2F). - Open hardware a plus. Pre-order fundraising is 100% legit. Hotplug works well in Debian. - Original Solo was a bit loose in a USB-A port. It was tricky to press the button without pins losing contact.
- Pixelbook power button can act as U2F, which is neat.
[1] https://solokeys.com/products/somu-tiny-security-key-two-fac...
https://www.buybitcoinworldwide.com/dongle-auth/dongles/
Personally:
- NFC Yubico with my car keys. I can't remember ever using NFC to authenticate directly on mobile, but I like having a hardware backup for time-based one-time password (TOTP) codes. (Google Authenticator / Android)
- Tiny Solos (Somu[1]) live in my keyboard, laptop ports for "touch to login" (universal 2nd factor, U2F). - Open hardware a plus. Pre-order fundraising is 100% legit. Hotplug works well in Debian. - Original Solo was a bit loose in a USB-A port. It was tricky to press the button without pins losing contact.
- Pixelbook power button can act as U2F, which is neat.
[1] https://solokeys.com/products/somu-tiny-security-key-two-fac...
What's the risk from replacing YubiKeys with software that relies on the internal security chips in modern computers?
My most cited paper was used by the original BitCoin paper, so I can attempt to listen to a security argument. I have yet to hear anyone justify external USB key security when computers have security chips. I also follow the progress in provably correct programming; saying we're too stupid to allow the computer to handle it isn't a compelling argument. Write some provably correct secure code for this!
I would so love to see Duo and YubiKey go out of business. However, if they had been more respectful of my time, I wouldn't have this thought.
My college and university both require multifactor authentication for logins required by my daily work. They have chosen Duo Two Factor Authentication, preferring that I find my phone and launch Duo's app for each login. YubiKeys are supported as an alternative. I have a YubiKey in each of five machines; I'm no more willing to move around a single YubiKey than I am willing to find my phone.
Duo's implementation requires numerous extraneous mouse clicks. They don't autodetect if a registered YubiKey is already present. Rather, they present a global default choice of YubiKey, and force a click for the dialog that supports then tapping a YubiKey. If one doesn't change the selection, one gets an error message that the YubiKey isn't registered, when it is; it's there on the original menu. Duo doesn't accept direct user feedback, further ingratiating me with my IT department when I file reports about this.
I'm starting to feel that this is all deliberate obfuscation, to draw attention away from having to tap the YubiKey, which is security theater a company like Apple cold put out of business in a heartbeat. I'd go to prison for life for kidnapping, but when a corporation dilutes this same harm, stealing five seconds each daily from many users, it gets excused as incompetence. The kind of incompetence Steve Jobs would never tolerate if he were alive.
Most people are extraordinarily clumsy with computers, expecting random mouse work. I embrace agility tasks while cooking, but I take extreme umbrage at this clumsy interface being forced on me every day. My first memory of school was a student teacher leaving the classroom in tears after I taught half the class to play Simon Says backwards. I didn't take the time to customize QMK firmware for my keyboards, only to have some CEO I've never met force me to play Simon Says.
If one wanted to automate tapping a YubiKey, it just needs a connection to ground while it flashes, which would be a cute Arduino-class project.
My most cited paper was used by the original BitCoin paper, so I can attempt to listen to a security argument. I have yet to hear anyone justify external USB key security when computers have security chips. I also follow the progress in provably correct programming; saying we're too stupid to allow the computer to handle it isn't a compelling argument. Write some provably correct secure code for this!
I would so love to see Duo and YubiKey go out of business. However, if they had been more respectful of my time, I wouldn't have this thought.
My college and university both require multifactor authentication for logins required by my daily work. They have chosen Duo Two Factor Authentication, preferring that I find my phone and launch Duo's app for each login. YubiKeys are supported as an alternative. I have a YubiKey in each of five machines; I'm no more willing to move around a single YubiKey than I am willing to find my phone.
Duo's implementation requires numerous extraneous mouse clicks. They don't autodetect if a registered YubiKey is already present. Rather, they present a global default choice of YubiKey, and force a click for the dialog that supports then tapping a YubiKey. If one doesn't change the selection, one gets an error message that the YubiKey isn't registered, when it is; it's there on the original menu. Duo doesn't accept direct user feedback, further ingratiating me with my IT department when I file reports about this.
I'm starting to feel that this is all deliberate obfuscation, to draw attention away from having to tap the YubiKey, which is security theater a company like Apple cold put out of business in a heartbeat. I'd go to prison for life for kidnapping, but when a corporation dilutes this same harm, stealing five seconds each daily from many users, it gets excused as incompetence. The kind of incompetence Steve Jobs would never tolerate if he were alive.
Most people are extraordinarily clumsy with computers, expecting random mouse work. I embrace agility tasks while cooking, but I take extreme umbrage at this clumsy interface being forced on me every day. My first memory of school was a student teacher leaving the classroom in tears after I taught half the class to play Simon Says backwards. I didn't take the time to customize QMK firmware for my keyboards, only to have some CEO I've never met force me to play Simon Says.
If one wanted to automate tapping a YubiKey, it just needs a connection to ground while it flashes, which would be a cute Arduino-class project.
How does recovering from a broken/lost/stolen device work in this scenario? I'm assuming it's the same as other MFA methods, namely using a recovery code that was given at the time of enrollment, or am I wrong in that line of thinking?
Recovery code or another key. You can enroll multiple keys. As long as you have one of them, you can use your access to disenroll the broken/lost/whatever key and enroll a replacement. I have one key that I keep with me, and another that I keep in my safe. If I lose both, I'll use a recovery code that I keep in an encrypted vault online (as well as in my safe in paper form, but assuming that whatever destroyed the key in the safe also destroyed the list of codes in the safe...)
In theory this is enough to prove it's genuine because they are supposed to be tamper-proof, i.e even if you buy indirectly or it's intercepted in transit.
The only thing I can see this failing to detect is an intermediate layer that intercepts USB and has access to the physical button... e.g If an attacker embedded a genuine small form-factor key into a larger package that mimics a larger form factor. This would be useful to an attacker which could get a target to trust the key, believe it's genuine and start associating it with services, and then be able to remotely activate it once they have gained the users trust... still a tough challenge to pack all of that with wifi etc into a small enough package with a micro yubikey or something inside.
I don't think this is a very realistic possibility currently, but if you are concerned, you could simply buy the smallest possible yubikey form factor.