FIDO2 security key company releases hardware that's open source and uses Rust • Hacker News Board

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#21

Post by g_p » Sat, Feb 13, 2021, 12:19 AM UTC

roblabla wrote: post #17

l0b0 wrote: post #11

As someone who is comfortable with TOTP but hasn't tried FIDO-/Yubikey-style devices, I have a few questions: - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members. - Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it, adding an entry or…

I use a yubikey, but I suppose the Solo will be similar. > - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members. On windows10, yes. I haven't tried it on Ubuntu 20.10 yet, but I think FIDO/WebAuthN will Just Work. (PIV will likely need custom software, but if you're using PIV, you probably know what you're doi…

> I don't think you even can do this. I'm not entirely sure how FIDO works, but I think the key is basically derived from some kind of "master" key combined with the domain you're connecting to. So the key doesn't actually have any memory of which servers it ever connected to.

Indeed, this is one of the most elegant features of U2F - it preserves security and privacy even in relatively adversarial edge cases.

Your token has a hardware-backed long term key in it (well, one for encryption and one for authentication). When you enrol on a website, the token generates a new asymmetric keypair internally, then encrypts and authenticates it with the long lived keys. The registration bundle sent to the server is called a "key handle", but is typically just the a hardware wrapped key.

When you visit a site and log in, on the 2fa prompt, the site sends the encrypted wrapped key back to the browser, and it tries verifies it's a valid key, then decrypts it, and does a challenge-response authentication that's tied to the HTTP origin (domain and port) of the request.

What's quite nice is that (outside of a few corner cases like looking at counter values and trying to correlate), you can safely use one u2f key with multiple accounts on multiple services, and none can be linked by the u2f key. (Of course they can be linked through other means, but the token won't be that link)

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#22

Post by g_p » Sat, Feb 13, 2021, 12:29 AM UTC

xur17 wrote: post #20

Groxx wrote: post #19

Earlier quoted context omitted.

> - The ideal backup for this is to have a separate key, both authorized. This in particular is important. Security is only as strong as your weakest link, so any backup methods (e.g. "forgot password" flows) might as well be your primary method, if you actually care to strongly secure things. Adding another (or more) key gets you same-security redundancy if one fails or is lost. Nothing else will achieve this. Degra…

This is one thing I hate about these keys though - some services only support one key, and for ones that support multiple, I struggle to figure out a storage system for my backup key. I don't want to keep it with me (because then I am at risk of losing both), but if I keep it separate, I need to remember to add it to new accounts - there's no way to see a list of accounts a key has been associated with. I'm curious h…

This is the biggest weakness of U2F unfortunately.

My approach is to keep a list (a simple text file) of what services are used for U2F, and which keys are enrolled with it.

Most services ask or require you to name the token you enrol (if they support multiple tokens) - I gave the tokens names so they're consistent.

Now I have 2 ways to check - logging into a site, you can see what keys are enrolled. And as fallback, I can use my underlying text file and see which keys I enrolled.

You just need to make a point to check the file once every so often (at least first time you are near your backup key after having edited the text file).

I've seen some interesting approaches (on modifiable tokens where keys can be exported) where they configure a backup key as a mirror of the main key, but with the counter advanced forward such that using the backup will invalidate the regular (thus alerting you to the use of the backup by an adversary, as long as the service properly validates the counter).

I can't think of an easy solution to this (it is effectively the key distribution problem) without adding complexity (like manager software for tokens, and a Shamir's secret sharing style way to export a token's root key through SSS such that it can be recovered by a quorum of keys in an emergency). That breaks various aspects of the threat model though.

Perhaps there's a less complex way to do it though? Like having up to N persistent public key slots on the token, where public keys of your other tokens can reside. When registering, the generated key is also encrypted "to" those tokens, and sent as supplementary key handles. You'd need to add a pairing relationship to validate authenticity of the key handles, but I suppose it could work.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#23

Post by user3939382 » Sat, Feb 13, 2021, 12:30 AM UTC

xur17 wrote: post #20

Groxx wrote: post #19

Earlier quoted context omitted.

> - The ideal backup for this is to have a separate key, both authorized. This in particular is important. Security is only as strong as your weakest link, so any backup methods (e.g. "forgot password" flows) might as well be your primary method, if you actually care to strongly secure things. Adding another (or more) key gets you same-security redundancy if one fails or is lost. Nothing else will achieve this. Degra…

This is one thing I hate about these keys though - some services only support one key, and for ones that support multiple, I struggle to figure out a storage system for my backup key. I don't want to keep it with me (because then I am at risk of losing both), but if I keep it separate, I need to remember to add it to new accounts - there's no way to see a list of accounts a key has been associated with. I'm curious h…

My threat model is focused on remote attacks, I consider physical access to my workstation game over. So one stays on my keys, one on my wife’s keys, and one stays plugged into my workstation.

If I’m enrolling the keys with a given service I make sure to add or remove all three at the same time so I don’t have to track which is associated with different accounts.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#24

Post by taeric » Sat, Feb 13, 2021, 12:35 AM UTC

Groxx wrote: post #19

lvh wrote: post #12

Earlier quoted context omitted.

Can't speak for this thing specifically, but FIDO2 keys in general: - Yes, you have everything you need on every major OS/browser - These devices are zeroconf; resetting it actually kills a security feature (key use increments) aiming at cloned devices - The ideal backup for this is to have a separate key, both authorized. They don't need to have the same material, in fact, cloning it would be considered a weakness (…

> - The ideal backup for this is to have a separate key, both authorized. This in particular is important. Security is only as strong as your weakest link, so any backup methods (e.g. "forgot password" flows) might as well be your primary method, if you actually care to strongly secure things. Adding another (or more) key gets you same-security redundancy if one fails or is lost. Nothing else will achieve this. Degra…

Having multiple keys without auditing when the backups are used, though, feels wrong. And that is my main gripe with these right now. Very hard to get any system to help build the habit of using the things. Most places default to remember your login. Basically forever.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#25

Post by asnelt » Sat, Feb 13, 2021, 12:35 AM UTC

g_p wrote: post #13

l0b0 wrote: post #11

As someone who is comfortable with TOTP but hasn't tried FIDO-/Yubikey-style devices, I have a few questions: - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members. - Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it, adding an entry or…

1. I'm not aware of any drivers being needed on any common platform. Support in Android apps is sometimes not perfect, but that's an app issue rather than a driver issue. 2. No software is required - far easier to use than you describe. You insert it, tap the button when prompted, and that's it. The token will decrypt an wrapped key (held by the remote service) using a hardware backed key, and sign an attestation usi…

Regarding support on Android, if you are using a custom rom like LineageOS without Google Play Services then it won't work currently. Unfortunately, Google implemented FIDO2 in the play services, not in AOSP: https://bugs.chromium.org/p/chromium/issues/detail?id=997538

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#26

Post by g_p » Sat, Feb 13, 2021, 12:39 AM UTC

asnelt wrote: post #25

g_p wrote: post #13

Earlier quoted context omitted.

1. I'm not aware of any drivers being needed on any common platform. Support in Android apps is sometimes not perfect, but that's an app issue rather than a driver issue. 2. No software is required - far easier to use than you describe. You insert it, tap the button when prompted, and that's it. The token will decrypt an wrapped key (held by the remote service) using a hardware backed key, and sign an attestation usi…

Regarding support on Android, if you are using a custom rom like LineageOS without Google Play Services then it won't work currently. Unfortunately, Google implemented FIDO2 in the play services, not in AOSP: https://bugs.chromium.org/p/chromium/issues/detail?id=997538

Interesting and disappointingly. In this case I was testing it with play services, using the nextcloud app. I believe they are using something slightly custom from an open SDK, and suspect the outdoor was at their end.

It seems strange Google put fido2 into play services, but that's certainly what they seem to "need" to do to get things shipped, given the lack of prompt Android release updates (don't even start me on longevity...)

Still unfortunate every time this happens, as AOSP just loses more and more functionality.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#27

Post by EvangelicalPig » Sat, Feb 13, 2021, 12:43 AM UTC

l0b0 wrote: post #11

As someone who is comfortable with TOTP but hasn't tried FIDO-/Yubikey-style devices, I have a few questions: - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members. - Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it, adding an entry or…

Some Linux distributions require adding udev rules for applications to have USB device access but other then that, it's pretty much plug and play.

A bit more convenient than having to use the YubiKey apps for TOTP and such.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#28

Post by amluto » Sat, Feb 13, 2021, 12:47 AM UTC

EvangelicalPig wrote: post #27

l0b0 wrote: post #11

As someone who is comfortable with TOTP but hasn't tried FIDO-/Yubikey-style devices, I have a few questions: - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members. - Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it, adding an entry or…

Some Linux distributions require adding udev rules for applications to have USB device access but other then that, it's pretty much plug and play. A bit more convenient than having to use the YubiKey apps for TOTP and such.

My now-defunct u2f-hidraw-policy package did this in a generic manner. The code was subsequently ported into the upstream udev code, so any up to date distro should automatically detect and handle U2F devices. If they don’t, file an issue with upstream systemd and it’ll get fixed. Feel free to file an issue on u2f-hidraw-policy too if you want my attention.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#29

Post by conorpp » Sat, Feb 13, 2021, 12:55 AM UTC

l0b0 wrote: post #11

As someone who is comfortable with TOTP but hasn't tried FIDO-/Yubikey-style devices, I have a few questions: - Are drivers for this already installed as part of desktop Ubuntu 20.10/Windows 10? Any driver installation will absolutely make this a no-go for family members. - Is additional software required for anything non-techies might reasonably want to do with this device, including resetting it, adding an entry or…

Just wanted to add since I didn't see this covered in other comments yet --

TOTP and any sort of one time code authentication are just as phishable as passwords. Perhaps the biggest benefit for most people using U2F or FIDO2, is the large resistance to phishing.

This is because of how the whole ecosystem has adopted FIDO2. When a FIDO2 key signs an assertion for a website, it includes the domain in the signature base, e.g. "example.com". The browser enforces that the request to the FIDO2 key always uses the correct name of the domain you're on.

If you accidentally go to a fake website, "exaample.com", then the key will make a signature for "exaample.com", which is invalid for "example.com". Nothing can be phished to get around that, unlike OTP codes.

Even if you have other 2FA options linked to your account, as long as you're using your FIDO2 key, you gain this benefit. Very strong benefit for both individuals and enterprises.

Re: FIDO2 security key company releases hardware that's open source and uses Rust

#30

Post by g_p » Sat, Feb 13, 2021, 12:57 AM UTC

taeric wrote: post #24

Groxx wrote: post #19

Earlier quoted context omitted.

> - The ideal backup for this is to have a separate key, both authorized. This in particular is important. Security is only as strong as your weakest link, so any backup methods (e.g. "forgot password" flows) might as well be your primary method, if you actually care to strongly secure things. Adding another (or more) key gets you same-security redundancy if one fails or is lost. Nothing else will achieve this. Degra…

Having multiple keys without auditing when the backups are used, though, feels wrong. And that is my main gripe with these right now. Very hard to get any system to help build the habit of using the things. Most places default to remember your login. Basically forever.

While not cryptographic level auditing, this is arguably a UX feature for sites to implement -- on their inevitable loading spinner after login, they could show you the U2F tokens enrolled, and their most recent use on a small timeline. If your cold backup suddenly goes from ancient to now, that ought to be looked into!

Regards habits, I find U2F is so easy to use that there's no real issue there. The bigger issue is that (relatively) few services support it. I'd much prefer to use it over TOTP phone generated codes, but far more sites seem to support phone app generated codes (while pretending you need their proprietary app to use them, even when it's just plain TOTP) or, even worse, SMS!