Using FIDO keys | Hacker News Reader

Using FIDO keys

777.tf

85 pointsjaefi63 comments

Open articleView on HN

My colleague and I recently gave a workshop about security keys where we tried to answer questions like:

* Why should I use a security key?

* What is it used for?

* How can I choose one ?

* What features should I look for?

We did cover FIDO2/Passkeys but also multiple other use cases.

Here are the slides if you're interested: https://tome.one/slides/amiet-pelissier-security-keys-worksh...

Oh that's interesting, thanks for linking it!

Very useful! Thanks!

This space is confusing. FIDO2, U2F, UAF, CTAP, WebAuth, Passkey, 2FA, … The names frequently change.

Aren’t all of them just public key authentication (with the private key in a mini-HSM, and public key either calculated in real-time, or stored, in the HSM, and synced externally)?

They are all just public key authentication with a protocol on top to enable various use cases. For FIDO2/WebAuthn/passkeys, the device, on registration, gives the website the public key to use for subsequent authentications.

There are a bunch of related but distinct technologies with names here. For example:

CTAP is a protocol for say a PC, or a Phone to talk to an authenticator, maybe over USB or maybe Bluetooth.

WebAuthn is a W3C standard for how a web site can negotiate (via Javascript) exactly what we're going to authenticate and then perform the authentication.

Imagine you connect an external CD drive to your laptop. The CD can turn Red Book CD audio into PCM data, maybe the drive plugs in with a USB-C cable, and the drive uses a SCSI-based Mass Storage variant USB protocol to talk to the laptop, which has an XHCI USB controller, so your operating system needn't know the fine details of this precise PCI USB controller chip. Again, distinct technologies with their own names.

There are two names that the end user should see today (WebAuthn for older apps, Passkey for modern stuff). U2F is a pretty old name that may still pop up, but I'm not sure if any user facing software ever used that name to begin with. Most likely, the names facing the user are "security key" or "passkey".

FIDO2 is a standard set up by a couple of authentication companies and stakeholders. U2F was basically an earlier attempt at that. FIDO UAF is a protocol for authenticating, CTAP is a protocol for communicating with hardware. 2FA is just a generic term for "multiple factors", like combining a PIN with your fingerprint. WebAuthn is the web API for authenticating with security keys.

Most of them do indeed come down to public key cryptography. The challenge is providing a public key API that works across hardware vendors, supports attestation, and allows for things like "use your phone to verify your login if your computer's TPM isn't sufficient". They all solve a different problem in the chain, and the names have changed a bit over the decades.

If you're building software now, use the word "passkeys". Apple and Google have stuck with those names, and they're named a lot friendlier than "WebAuthn".

Passkeys are the opposite of "private key in a mini-HSM" in that they're synced to a cloud provider.

The goals of this whole thing have shifted, and it's hard to keep track of what was aiming at what goal. It started out as "actually secure 2FA" and now we're at "cloud-synced unphishable password replacements for non-technical users".

I’m not an expert in these protocols, but it’s the public key that is synced. There is no need for the private key leaving the device, in “asymmetric authentication”.

Syncing the private key is like “symmetric authentication”, where the hashed password is sent to the website. That’s the old way of authentication.

"Passkeys" are backed up into Google/Apple/1Password cloud. You can grab a fresh laptop and download your synced passkeys into it, and log in from there.

That being possible means the private key material has to be backed up, as opposed to being permanently locked into an HSM like Yubikey.

No, only public key has to be synced, for that to be possible :)

Think of ssh keys. Only your public key has to be transferred to the server for you to login.

Take laptop A. With it, use a passkey to log into a website. Sync passkey with the FAANG of your choice. Destroy laptop A.

Take laptop B. Log in to your FAANG of choice, syncing passkeys locally. Use laptop B to log into the same website.

Your FAANG of choice saw much more than a public key, for that to be possible. That might have been encrypted by something like your password to the FAANG, but still, it's the opposite of a tamperproof HSM.

It depends if you use a hardware token or a password manager that supports Passkeys.

If it's the hardware token, then the "certificate" (which can either contain your username or not aka discoverable vs non-discoverable credentials) that private key required for authentication will be stored and cannot be extracted in the secure element (until an exploit is found).

I have a couple v1 Solokey Somus lying about. Good little devices. Unfortunately the main selling point of upgradeable firmware is moot if they no longer support the old devices and you have to upgrade. At that point it's they're like everyone else. Except they require some setup on some machines, whereas other keys "just work"

I've since replaced them with yubikeys. Yubikeys have a better feature set (at least compared to by v1's) and at this point are fairly mature/stable. V2 is still pitched as alpha quality, and probably will be deprecated with a v3. As much as I want Solokeys to succeed, I just can't recommend them either.

Given how the project is going, not even sure if there will be a V3 at some point.

That's actually what gives me confidence. All the hardware manufacturing problems almost ensure a v3 will be designed.

I meant more the lack up updates and communication doesn't really paints a bright future for Solokeys.

Are you sure?

    apt-get install solo-python

One can update the firmware.

My key won't get upgraded (it just pretends to install the upgrade, says done, and the key stays on the same version).

The "hacker" variant can be flashed with whatever, but if you lock it down to signed firmware, you're at the mercy of SoloKeys to provide updates. That's kinda one of the tenets of hardware keys, that they can't be modified/corrupted/dumped by rogue firmware.

Am i the only one concerned about the tendency of putting your identity on hardware you possibly do not own?

What a wet dream for the internet controlling fascists when the adoption of "just wield your smart phone" auth would be in place and mandated every where.

Nothing compares to the secrecy of passwords.

My identity is already on hardware I don't own, my government ID card. What do you foresee the risks being, and why are these risks only possible with secure authentication?

Your government id card is not widely adopted as method of authentification, i guess. This is where this new pass key approach comes in. My concern is, that this new method might completely replace old fashioned passwords. And once every one is used to have a hardware token, the next step of only accepting or selling government approved devices is a small one. This could could ultimately make anonymity impossible. Because you dont control the hardware or the spec.

Imagine being required to have and use your govID for simply everything, because there is no alternative.

This is not a risk of secure authentification, which passwords can also provide.

$Corps loved to harvest phone numbers as a second factor despite a second fall back email address would be at least as secure as SS7 communication. But phone numbers are tied more strongly to your identity so more valuable for the data brokers.

This is the same thing actually. Tieing identity to something you have and not something you alone know. Something external.

Having a single external dependency for all your identities sounds like a good idea to you? For facists and data brokers it certainly does.

To me, this is an attack on anonymity and i know that i sound paranoid. Lets wait for the enshitening.

You DON’T have to trust any company or government for passwordless authentication. Don’t want to use your phone? Use a hardware key instead. Don’t want to use a hardware key? Use an open source solution like Bitwarden (and it’s not the only one).

At this point, you’re just making shit up about something you don’t understand.

You havent understood my point.

> Nothing compares to the secrecy of password.

Because they are soley internal to you.

Yes, you can generate passkeys at will ... and then you give them away to a usb dongle or HSM, from which some day you might not be able to export them, because vendors love their locked in customers.

I am talking about control and yes, my concerns are speculation but reasonable to me, when you look at pretty much all the recent development. From not-WEI over DRM, to right to repair and on and on.

> Don’t want to use your phone? Use a hardware key instead. Don’t want to use a hardware key? Use an open source solution like Bitwarden (and it’s not the only one).

You're ignoring the fact that WebAuthn can require attestation, which will remove device choice from the equation.

What? Security keys are only "identity" in that they deliver opaque, secure numbers. The actual important bits are somewhere else anyway.

FIDO is a standard algorithm and doesn't need a phone.

I use an old Google Titan key, not the bluetooth model but the regular one, as my backup (it was my primary) and a Yubikey 5 for my primary. I like the peace of mind that they give me that no one can steal my password and login to my important accounts, but I found that certain providers only allow a single 2FA to be used, with no backup, so I don't feel good using them there (AWS, what the F?) and also I find that not a lot of services support 2FA in the form of keys, they all want to use TOTP or SMS generally, so I only can really use these for my Fastmail and Bitwarden and a few other accounts, but for my bank or my health insurance, they do not support FIDO keys. I also can't use them on any government sites! I know passkeys are going to rule the world soon, but I don't like the idea that my phone and a 3rd party have access to this 2nd factor; I prefer a separate key for this purpose.

AWS IAM supports multiple keys now! I think this was a blocker for using hardware keys on AWS for a bunch of organizations.

https://aws.amazon.com/about-aws/whats-new/2022/11/aws-ident...

Cool! Thanks for letting me know!

You don't mention which country and thus which government. Some US government sites do accept WebAuthn, and for at least some UK sites it's possible via a third party.

Banks though, yeah they aren't good at this stuff. My safe† bank decided one day to completely up-end how logins work and almost locked me out. My good bank provide a very stupid, proprietary solution but at least it's an actual secure solution.

† Safe in that they're owned by the government, so, if they go bankrupt I have worse problems because now I live in a failed state. Big piles money of money sit in this bank because it's safe, but it's run by clowns who don't understand customer service.

As much as I want a hardware key, I still struggle with the practicality of having a backup key. I create new accounts on websites quite often, and the idea of having to go fetch my backup key out of a safe to register it (and hope the site allows multiple keys) just feels impractical (“I’ll do it tomorrow”). Not to mention—what if I’m at work, or out and about setting it up on my phone? Am I really going to remember to add my backup key when I get home every time?

Wish there were a way around this :/

I very much wonder if this obvious oversight was intentionally left unaddressed in order to create a requirement on proprietary sync/backup solutions and make true security more difficult (since the key material is now being synced around and could technically leak or be subject to "lawful intercept" or bruteforce of the sync service's authentication).

> the idea of having to go fetch my backup key out of a safe to register it (and hope the site allows multiple keys) just feels impractical

An alternative some people use is to register a TOTP code and print out the QR code. Then you can remove it from the app. It's not a full solution but it might be part of one that works for you.

> Wish there were a way around this :/

What do you imagine a solution here might look like? I don’t know enough about the problem space to truly know, but I feel like I’ve seen versions of this: I can authorize any arbitrary public key for use over SSH, for example; and (based on my memory of YubiOTP) it’s seemed like at least some of these hardware auth protocols work based on using an open serial number or public key to identify the authorized authenticator.

Intuitively it seems like it should be possible for me to store on my main auth device some form of the backup device’s identity or public key material, and at enrollment time, ask the authenticating service to trust either the current device or also this other device to authenticate me.

I wonder what risks I’m overlooking-surely there must be good reasons the protocol excludes that kind of approach.

Perhaps if you could register your hardware key using its public key, which could be saved on your device? So you don’t need the hardware keys to be physically present when registering; just when signing in later.

In FIDO a separate public+private key pair is minted for each (key,site) pairing. This has lots of important benefits, but one is that it preserves existing anonymity.

If I use a Security Key to sign into Facebook as "Melissa Smith" and use the same Security Key to sign into my GitHub account "acab420", even if Facebook and Microsoft work very hard they can't correlate the information they have to prove those are being authenticated with the same authenticator. The keys are different, as they would be if these were different authenticators.

You might think it's impossible for FIDO1 or in scenarios where it's "just" a second factor and isn't storing anything for the site on your key, but there's a really clever trick. The Relying Party (e.g. web site) is required to remember a large random-looking "ID" for your key. Those aren't really random - they're effectively your private key for that site, but encrypted using a symmetric key only your authenticator knows. It encrypted its own private key and just sent that, in plain text, knowing it's impossible to decrypt (typically AES-128 or similar) and when the ID is sent back, the authenticator just decrypts it. AEAD is used, so an authenticator can tell if this ID isn't one it made because the AEAD fails.

Thanks, that's a really helpful explanation.

I wonder if the actual desire is to be able to buy a set of cloned keys. I.e. instead of having each key be unique, be able to buy a set of N keys with identical private key. Or the ability to create such a set yourself with a special initialization sequence. This would give you your high-availability backup, but means you cannot revoke the first key if lost. So it seems like you'd really have to trust the other hardware protections and PIN/lock features if misuse of a lost/stolen key is a concern.

Periodically, I try to think if there is some other expected UX you might want that is somehow neither cloned nor independent keys. Like some hybrid of secret-sharing and group key schemes. Have a set of N keys which know about each other and can act individually to authenticate for the same identities, including for new identities enrolled by any key in the group, as in the case of a cloned key. But, include some capability for k out of N keys to "vote out" a member from the group in order to revoke the lost key and prevent it from authenticating any of the identities in the future.

I am not a cryptologist, but I can't really imagine any crypto mechanism to actually produce this combination of effects. A fully distributed group registration and authentication effect during normal use, so enrollment via one key can be followed by authentication using another. But at the same time, allowing ejection a member from the group to prevent future misuse. I can only imagine this as a protocol, where every authentication for the group would have to consult some centralized ledger or revocation list for the group membership. It could be decentralized/federated in a sense, but would require some kind of online check with the "latest" ledger state for a given key group.

My "solution" to this problem is: hardware keys with backups for the really important services—Bitwarden, Google, domain registrar, etc. And then for stuff that isn't absolutely critical, I just use an OTP stored in Bitwarden. As for having both the password and OTP stored in the same place, the way I see it, the OTP is mainly protecting against keyloggers, data breaches, etc. And then I figure, if someone gets into my Bitwarden account, I'm already fucked anyway, so it's whatever.

I currently have four Yubikeys: one on my keychain, one in my apartment, one to take with me while traveling, and one at my parents' house. I figure this should be adequate to ensure I never get locked out of Bitwarden or Google, which would be an utter disaster.

That sounds like a pretty reasonable solution, just doing it for the ‘crown jewels’.

The OTP in the password manager one is another thing I’ve struggled to wrap my head around. There’s an interesting conversation about it with folks at 1Password for those interested: https://1password.community/discussion/101714/why-is-it-a-go...

Now that Bitwarden supports passkeys, I hope the "copy 2fa code to clipboard" approach to 2fa integration will soon come to an end.

You can use a software passkey and still get 99% of the benefit. For the other 1%, you can't have it both ways, where a hardware key is both required and not required to sign in.

Maybe there can be better UX around signing up, ie "give me your public keys so I can set them up in your account", but then you lose a lot of the privacy, because the public keys aren't different per site any more (and operators can then tell the same person has an account on multiple sites).

I do use multiple keys and I like them a lot, but there is a big Issue I don't see mentioned a lot: you can't solo it on most services:

- Google forces you to also keep their stupid "verify on another device", where you can't even untrust specific devices without fully logging out - proton apps don't support fido auth - microsoft account only allows it on edge and afaik not at all on linux - and so on..

I think the only service where I can fully disable other 2FA channels is github.

Edit: a word

My Yubikeys are great and have been since I started using them (2011), adopting newer products if necessary as they are released.

Passkeys are a confusing mess for most users, and the limited storage on Yubikeys doesn't help. However, 1Password's passkey support manages to reasonably successfully hide the confusions that always exist when explaining passkeys to anyone.

For now, I'm happy with my Yubikeys+1Password for all the platforms I use.

After looking at various keys and their features I chose basic FIDO2 with NFC with no storage or other fancy feature.

Keys with lots of feature have a larger code base and this means more bugs in the long term.

I use my FIDO2 keys for proxmox, ssh ed25519-sk, vaultwarden, nextcloud, GAFAM accounts.

Unfortunately I know of no bank that has adopted FIDO2/webauthn.

Note: Paypal only allows one FIDO2 key AFAIK, so not an option there.

Looking at bank security is probably the saddest landscape around. Most will ask you for a PIN at maximum and then tell you it's not possible to have stronger authentication because of "safety".

I wish there was stronger laws forcing banks to adopt stuff like that.

I wish there were laws making it the bank's problem if your account gets hacked. The security they choose to use is secondary, but you bet they'd be the most secure websites around if they were liable for the losses.

You won't probably get what you wish for: this is how it works in South Korea but the solution that the banks went is worse than SMS-OTP, where your bank is expected to monitor your computer (https://palant.info/2023/01/02/south-koreas-online-security-...).

I wrote a small article about security keys. I hope y'all will like it.

Cool article!

Sorry your SoloKey V2 experience isn't going so well. I have a V1 and it's been surprisingly robust over the past 3 years. For NFC, I can only get it working with my Pixel 7 phone of I remove the thick OtterBox case. Perhaps your issue is also related to your case thickness? Having to remove the case is a hassle, so I am sticking with multipurpose USB-A to USB-C adapters for now.

I've been using YubiKeys for like 10 years, but the 5C model I recently got suddenly stopped working out of nowhere. It only lasted me from October to November of this year. I've been wondering if the brand has had a quality drop-off.

Of the security keys in my possession, the Thetis U2F key has lasted the longest (~5 years) and has had no problems whatsoever. They've since released updated FIDO keys, and so I purchased 2.

Good luck on your hardware MFA journey!

Hey! For the NFC thing, I tried with and without a case and seems the issue remains the same (maybe just a hardware failure). I must say I had more chances with NFC on my USB-C key thought it's still a bit jittery. On the other hand, the Yubikey's NFC works perfectly, even with the case.

Also I didn't knew about Thetis, I'm gonna look into those.

There is something to be said about having a physical key for an online account. Beyond the security implications it's kind of like a key to your home. Locking the door keeps most out, but there are still ways in.

What do you think about the german Nitrokeys? Especially the features and compatibility of the Nitrokey 3?

Anyone has one of those?

https://www.nitrokey.com/products/nitrokeys

One thing to keep in mind before buying their NFC keys is that it can only store up to 10 resident keys

Yubikey 5 can only store 20, which isn't a whole lot better. Are there yet any readily available FIDO devices that can store 100s of resident keys (I have almost 400 logins in bitwarden)?

The new Google Titan keys can store hundreds; sadly not even sure if I can get one here.

Depending on your level of trust in Bitwarden and your security model, you could consider unlocking the Bitwarden vault with a security key, and then using Bitwarden's passkey support to authenticate to websites. It's not really 2FA, but it works around the resident key limitation.

There's also a nifty app that implements CTAP2 on Android Wear, and basically act like an NFC/Bluetooth security key. If you have an Android Wear and don't think your watch will be hacked and rooted, this could be a useful alternative, especially in places where Google doesn't sell their Titan keys.

Ideally self hosted bitwarden (or a local only password manager such as keepassxc with passkey support) using a master password and a security key for the 2nd factor with all the accounts in your vault using passkey makes it so you need to know 1. the master password password, 2. have the security key, and also have 3. access to the vault.

The website being breached and the passkey public key being dumped is meaningless. They are more likely to compromise a site’s admin access that can get into user accounts than ever crack public key cryptography or simultaneously acquire all three factors necessary to gain access to my vault. And no matter what I do on my end (except only use sites that take security seriously) can stop that.

I don't think resident keys are that worthwhile. Relaying party anyway has to remember the user somehow, even if it's just the public key. And it still has to associate the key with the user data.

I think resident keys just complicate things for users and developers.

Resident keys are great, I don't have to remember usernames. I don't care what the RP does, I care that I can sign in with one click.

But you still have to remember what the key unlocks. A username could be just a label for it.

i use security key by yubikey (blue one, USB A) as one of the mfa. mostly for github and aws. and i personally like the "cool factor" when I have to "look" for the key when the sites ask for it. "bro, what are ya doing ya dingus?" "i literally can't login without the key, bro. like a real renter in a saas world!"

Reply on news.ycombinator.com