I keep hearing this is simpler and more secure, but I really doubt explaining this to my aging parents is going to be a fun afternoon.
Can we just leave well enough alone? Was never a fan of centralizing my identity in the first place.
BUT, I absolutely think we should continue to demand the right to interact with services on our own terms: Even accepting the compromise of "less security" (debatable if you know what you're doing).
I think the only way forward is a Free/Libre implementation of FIDO2 that is NOT linked to any specific device and can be modified - along with direct access to the keys. Those are the users property and should not be held hostage by hostile designs. Users should have the right to move their keys, without justification, and use whatever manager they want. Even a fully-software one.
Is this not possible with current designs?
However the main issue I have is that the user cannot import their own secret into the yubikey, so you cannot choose to use your own secret vs the factory generated one, or choose to have multiple yubikeys using the same secret, which would be useful as you wouldnt need to enrol multiple secrets with each service.
Where would you get this secret from in a secure way? How would you prevent a nefarious actor from exporting it and importing it into their own yubikey or similar?
That's what I meant. How exactly would one safely store this secret? How would you prevent an adversary from extracting the secret from the storage?
I'm not trying to be pedantic here, I'm just failing to see how this can be realistically implemented without significantly lowing the overall security. But this is also not my domain, so I'd like to learn.
If you're asking about the structure of the bits you'd need to move into the device in a verifiable way, there are standard APIs like PKCS #11 for interacting with HSMs.
You would then need a computer and a PKCS #11 client application. If you don't have a computer you can trust to pass keyboard inputs to a USB port without being intercepted, you've got problems that a yubikey will not solve.
Thanks, that was the piece I was missing.
Unfortunately the easiest way to "export" is likely to rely on the RP, as if they effectively use the sign_counter they may flag such a key as cloned. They should ideally just let you register multiple (and that's an RFC 'SHOULD').
Not a shill by the way, just a happy solokey owner.
The risk/reward ratio doesn't justify it in their lives. It's also a pernicious ratio because there is almost no way to increase the "reward" portion, just decrease "risk."
In my experience, solutions balanced on this type of ratio always fail to solve the fundamental problem. Which is why we have to have commercials that tell people "medicare will _never_ call you. If anyone calls and says they're from medicare, hang up immediately!" So, I'm assuming we can now look forward to "no one will ever call and ask for information from your key, if they do, hang up!"
I also expect a similar outcome.
Eh, my non-tech savvy friends/relatives find themselves guessing at and then finally resetting their password surprisingly frequently. There's some room for "reward" there.
There's usually no way to take your key off your device, so don't worry about that :P
So people invented OpenID and OAuth and stuff, but all those things are fundamentally flawed because users were no longer a source of their “own” identifies. Their identities became provided by third parties - and this is notoriously bad.
WebAuthn (and FIDO stuff) is not centralized, on the contrary - users still own their credentials and are sources of their identities (though there are optional attestations). It doesn’t require cryptography knowledge to use it, but it does to implement it - thus the certification (though anyone can surely do it without certifying for anything).
Human are also bad at not losing/breaking their magical security totem. I need to know that I can easily backup codes to any of these hardware tokens for if/when one is lost. Ultimate security be damned.
I'd rather know that each token is unique and not wonder how many copies of the token exist.
L1 (software based) obviously fits this requirement. I think L2 also can because while it is a physical key it could allow for the user to import their own secret. L3 takes that away as it must come from the manufacture with a key that cannot be accessed. Not 100% on any of this, but it's what I get from their level doc... https://fidoalliance.org/certification/authenticator-certifi...
This comes with (some) additional complexity for implementing more complex auth flows for developers.
If you think that passwords are working "well enough" today you are clearly not educated on how most users (mis)use them. If you built a site and tried out the passwords people send to you on the logins for providers of the email addresses they send to you, there'd be a large fraction of people reusing their email account password for your service, allowing you to access their email.