Unpopular opinion:

I *love* Fido keys. I love everything about this as 2FA. I love plugging them in/hovering them.

I love that they're revocable.

I love that they're physical.

I love that I don't need an app or device like OTPs.

Heck, in some cases I'd even be totally fine with Fido 1FA

· · Web · 5 · 8 · 23

@emacsen And you might also love the dicekeys approach, which means you can securely store a seed for your fido keys in the physical world - making identical replacement of the fido key hardware trivial ...

Of course this doesn't provide value for all use-cases, but for the majority of end-users this is pretty cool (and better than RSA's "lets keep all our customers' seed values in our central DB; oops its been stolen" ...)


> h, which means you can securely store a seed for your fido keys in the physical world - making identical replacement of the fido key hardware trivial ...

I don't think these are designed to be worked on in this way...

But why would I when I can revoke and add new keys?

@emacsen Yep, the dicekeys system combined with a solokey with non-default firmware, is explicitly designed for this.

When you've lost your existing physical token, you have to engage in an non-standard procedure to login without Fido, and then authenticate sufficiently to revoke the existing token. This should be difficult.

With dicekeys+solokey, you just create a clone of the original, and the downstream systems don't even know that you have done so; you continue to use them as normal.


I see this as an anti-pattern because we want people to get used to creating multiple keys and then revoking them.

If you have two physical devices with the same keypair, you can't revoke one of them without the other.

@emacsen /shrug, it isn't the right pattern for a central authority to follow, one where you have out-of-band communication with the administrators. But it covers the end-user or a large impersonal service pattern pretty well.

(If you have two physical devices with the same keys on them, you get some usability benefits at the cost of some security claims, that's true)

@emacsen @yojimbo The solution for the possibility of losing a token is to have more than one token.

@freakazoid @emacsen No, that's "a solution", not automatically "the solution".

I'm not saying that the dicekeys/solokey approach is "right for all use-cases", I'm just pointing out that it's technically possible, not horribly insecure, and can be very useful for some people.

@yojimbo @emacsen When I say "the solution" what I mean is that it's the solution if you care about the property of tokens that I consider to be the most important, which is that it allows the user to manage keys as if they were physical objects. Once the key has a presence off the device that ceases to be the case.

@yojimbo @emacsen Incidentally, people's breaking the security model that way is a major reason that the standard also allows for a vendor key: to make sure people aren't using modified firmware that lets them keep keys off the device.

@freakazoid @emacsen OK, so the default SoloKeys firmware is what you'd expect - it generates the key material on-device (although I'm not sure how they are collecting entropy effictively), and it's certified as a fido2 L1.

It looks like the way that the DiceKeys solokey firmware allows the uploading of the key material is a direct contradiction of the certification standards, which probably do allow key material to come from something that isn't the hardware key itself (looking at the definition of Allowed Restricted Operating Environments) but that's certainly not what the DiceKeys variant does :-)

So the right way to get that constraint you want would be to restrict a service to only using certified devices, which I assume is what you mean by saying "vendor key".

@yojimbo @emacsen I think most companies restrict it to the specific manufacturers they buy keys from, so a little more strict than just "certified devices". Is there even a certification authority that signs certificates?

@freakazoid @emacsen Good question, I haven't seen evidence of one, which means I guess an open device like the solokey could be programmed to pretend to be any other device if it wanted.

@yojimbo @emacsen For web sites like Github it's fine. In my experience the only place the vendor key has been an issue is for internal corporate stuff. Though I can imagine banks that use FIDO/FIDO2 might only allow devices they issue. I have no direct knowledge of such a bank, though.

@freakazoid @emacsen Right, which is where we circle around to emacsen's original comments about the dicekeys variant - I think it's a positive feature for an end-user to have the ability to make identical replacement devices on demand, rather than have to own and register multiple different tokens on an account.

I mean, DiceKeys itself is about having a personal seed used to generate all sorts of key/password material so you can re-create them in extremis, so you can leave the original physical seed in a secure environment for years if needed; as an alternative to having to engage with the actual administrators of every individual service asking them to help you change the authentication details.

@yojimbo @emacsen Given that I use U2F on a bunch of different sites, I can see why DiceKeys is attractive. It means you don't have to register multiple keys/tokens on each site.


@yojimbo @emacsen I think the intent with U2F is that you only use it on one or a few sites, and then you OAuth2, SAML, or OpenID Connect to use your U2F (or FIDO2) protected identity with other sites. I'm not a huge fan of this because each site has to pick a set of identity providers, which means for practical purposes it's Google, Facebook, and maybe Github for more technical sites. I have personally avoided SSO for this reason even though it's probably slightly more secure.

@yojimbo @emacsen On the other hand, it's not like many sites even support U2F, and I have yet to see one that supports FIDO2 passwordless authentication. So for the moment I use KeePassXC and Firefox's internal password manager, along with a Yubikey NEO for both U2F and OATH-TOTP to minimize the damage if my password file is compromised. I keep backup codes in my fireproof safe, but I'm sure it'd be a nightmare if I ever lost my Yubikey.

@yojimbo @freakazoid

> I think it's a positive feature for an end-user to have the ability to make identical replacement devices on demand, rather than have to own and register multiple different tokens on an account.

This is where two reasonable people can come up with entirely different views.

If key seeding became something most people did, it would (in my opinion) violate some of the principles of why FIDO keys are secure, which is per-device keypairs.

@yojimbo @freakazoid

Being able to make copies of the private key means I can't do any more device auditing, and this is a huge concern- so much so that if I had to secure a system, I wouldn't allow Solokeys for just this reason- it's too big a risk.

Key management isn't that hard. You get 2-3 hardware tokens. Problem solved.

@yojimbo @freakazoid

More than that, I think this violates the spirit of per device keypairs which where I think we need to go.

@yojimbo @freakazoid

Let me tell you a quick story on why I think this is so bad...

When I worked at NASA, an account was compromised because the user had left their computer on the Internet with an insecure system and a passwordless SSH key. The attacker logged into their desktop, SSHed into us, compiled some kind of network intrusion software and then began running it.

Without being able to audit/revoke the per device keypairs, FIDO keys are almost as bad...

@emacsen @freakazoid In my example of one user having multiple tokens with the same key; if you revoked the key centrally, all my devices would be rendered useless; so that isn't a misfeature of the multi-token approach.

On the other hand, if the attacker had physical access to one of the duplicate tokens, the original owner might not be aware of this; so that is a misfeature of this approach, especially noting that the higher certification levels from fido value tamper-evident tokens.

At least we're still requiring a physical token. If the attacker had stolen the dicekeys seed value, then this would also be breached, as they could make their own token anywhere (virtual or physical)

Show newer

@emacsen @freakazoid I think we're looking at the situation from two different directions - you seem to be describing the organisations' point of view, and I'm looking at it from the end-users'.

Security is an inconvenience, and getting the balance between the conflicting desires of users and organisations isn't always easy 🙂

So yes, I think we can reasonably have different views.


Perhaps unpopular in that I don't think I know more than two or three people IRL who use FIDO hardware tokens despite how cheap they are and easy they are to use!

@emacsen @mr64bit My entire workplace is using u2f keys (with some custom applets on the hardware on top of that). Then again, my workplace is a particular kind of bubble :]

@emacsen The only thing I don’t like is that even in FIDO2 there seems to be no way to use them to derive a secret such as an encryption key. So they can’t be used for decentralized identity or whatever.

@emacsen I think the concept is super cool and I want them to succeed but my experience using the U2F Zero was that it was so janky I eventually removed it from all my accounts and I'm not sure if it was the device's fault or just inconsistent software support or user error

@proto I can't speak to your experience, but mine is that when asked to authenticate, I'm asked to plug the USB device into the computer and press the button.

Once I do, it completes the final authentication.

It works under Linux (Ubuntu) and Windows, and with both Firefox and Chromium. I haven't tried with Vivaldi yet.

@emacsen Vivaldi's my main browser on win10 and linux mint, lol. Should work the same as chromium though

I have a yubikey around here somewhere that I never summoned the motivation to set up. I really should try it

Like I said, I love the concept

@emacsen only thing I dislike is that in many instances they require your phone number as a 'second factor' before you're allowed to register u2f/fido keys :/ this has very little to do with u2f/fido keys, though.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!