I don't know what the Bio FIDO ones have, but if it is similar, YubiCo may not have a product well placed for a large number of RKs.
~Edit: The Bio's have the same limit of 25
My issue then is that these keys allow total tracking. We need hardware implementing more complex and privacy protecting schemes (BBS+ etc).
Shared residual keys _should not exist_ (outside of short term temporary usage, e.g. not 2FA/FIDO).
They are a liability, they are a security risk, they promote bad security practices.
Best example TOTP (which from a security POV is quite flawed). You don't want to ever share the shared secret across devices (or back it up) but due to it being possible and flawed 2FA implementation being the norm not the expectation you are kinda forced into it. And as thinks look now passkeys will go into the same highly flawed user hostile direction.
Hard disagree there. I do not feel comfortable unless I can backup a key. Phones get lost/broken/stolen all the time. Is it less theoretically secure? Sure, whatever, but I am not James Bond.
How would you sign up a new service under this scheme?
Enroll with one device, swap the hardware key, and enroll with the other key?
What if two device are not in the same physical location?
For example "blessing" the enrollment of a device using another one, potentially across physical locations (i.e. similar to what discord and steam did at least for a time as far as I remember).
> How would you sign up a new service under this scheme?
the same way you do now, there is no difference
That's slightly more convenient but I don't see how it is more secure. With one key that has backups if I lose that key I can use one of the backups to disable that key.
Multiple keys is slightly more convenient in that scenario because with multiple keys I just have to disable the key that was lost, and then make a new key for the device that held that key and install it. With one key on multiple devices I'll have to install the new key on all of them.
There seems to be an obsession that if a digital key doesn't comprehensively solve all problems, it's terrible, despite the empirical evidence that people are fully capable of using physical keys despite their limitations.
you have a backup of a _different_ secret with a similar degree of "authority" (or if it's "copyable" with the only authority to be used for restoring 2FA once or similar)
then if you backup gets stolen you can just go into you account management API and disable/delete/flag it, in that case even if encryption is broken as long as you act fast enough the damage is trivially and conveniently contained (e.g. some password managers had insecure backup/storage in the past)
with the same key not only do you have to disable it, you first have to create a new key and then sync it to all your new devices and backups and then disable the old key, which isn't grate if you have more then one device or some of you devices are temporary out of reach (e.g. you one a business trip)
it's like reintroducing the "physical" problem of having to replace all locks when you loose your house key in a situation where you could have all the benefits one key per lock and a different door for each person (i.e. device) without any of the overhead/drawbacks this would normally introduce
and then use it with a backed up secure cold secret storage
OR (if you can, only for technical versatile people not a general solution at all):
as strange as it seems even with all the fancy new technology as far as I can tell the most reliable solution for long term account recovery(1) is to get a very small number of long ungussable one time use recover keys you encrypt in a blob and print out base64 encoded as a qr code(s) or similar and then put into a save, maybe in a bank, maybe more then one print
This solution while AFIK more reliable then any fancy technical solution is imperfect as in:
1. it isn't viable for everyone (i.e. you need a reasonable accidental damage save place which is preferable not in your home)
2. it requires the user to do the right thing
3. has some initial one-time time cost
This means it's not viable to be used for every single service.
Through you don't need it for that either, instead you can use it e.g. for a slow fallback to access encrypted blob storage in which you stored a database with one time code for resetting you various services. Then every time you sign up new services you extend that storage using you hardware bound keys and if you ever loose access to all hardware bound keys (unlikely to ever happen if you just act with a bit of care) you can go through the annoying process of getting you papers, scanning them, decrypting then and getting your one time reset codes.
Through now that I have already gotten way off topic, what I want is neither passkeys or having separate keys enrolled with tens of services. I want to have widely used standard interface where I can use the identity provider *of my choice* with *any* service (which is also easy to integrate for services).
There is AFIK no technical reason this doesn't exist and if we had that there wouldn't be any need for discussions about passkeys and password etc. Because for most people there would only be one or two logins + 2FA.
- Passwords are not guessable any longer
- Password managers don't expose secret material in normal operation, because they sign requests with keys stored in TEEs (i.e. most modern devices have an embedded security key)
password managers are a security liability which only exists because of how flawed password are
the original design of WebAuthn was all about taking both password and password manager out of the equation noticeable reducing the attack surface
instead how it now looks they will make password managers mandatory
until they make "blessed" storage mandatory basically now controlling the password manager and HSK industry (by deciding which ones work with their products) and then maybe kill the whole industry by only allowing the storage build into Android,iOs,Windows, etc.
And while stuff like this sound like a crazy conspiracy theory in the past the more I look into how passkeys developed in recent years (especially how they where represented) the more stuff like this sound quite viable. I mean big coperations which frequently have been found to abuse their power and try to get vendor locking wherever they can afford to, pushing a technology which looks like an improvement but can easily be abused to facilitate vendor lock-in and control over parts of an industry with the goal to abuse that... that isn't anymore conspiracy territory, that is what Microsoft has been doing in the past non stop and only stopped doing because it was no longer monetary beneficial for them. But in this case it would be. For them and Apple and Google and a few other huge companies.
And if this is acceptable, honestly, do we need a new standard? Password managers exist today. Such that I already do what you are suggesting here with passwords. Does it really become much more secure by the move to passkeys?
I mean, I get the obvious ways that a challenge system is better than a bearer token. But I feel a ton is lost as soon as you move to the exportable keys.
Love to see an exploration on these topics. I confess I have not been following them much, lately.
This model has been tested to some extent with Apple pay and Google wallet which people take relatively seriously since there's money involved. I think the model makes sense to improve security for the masses, but it's not good for people that want and demand more (like people that already bought YubiKey products).
Consider, that is largely replacing 20ish numbers with something else. Is slightly more convenient for folks, as you have your phone with you a lot.
So, for the passkeys, I know that there is a secure enclave in phones. I was not aware that they could store resident keys. Know what the limits are, there?
Personally, I think there is significant friction to adopting passkeys, so there is little risk of being forced into using them in the near future. Longer term, though, I have no idea.
What does the cost look like? Are we talking $50 or $500?
Additional flash that is just as secure would be expensive mostly because other Smart Card uses don't need it, but it doesn't really have to be secure because storing resident keys could be done in a similar opaque style as a server and only really brought in to the secure context when needed.
Edit- misremembered NXP->STM and added USB as difficulty getting significant flash within the NFC powered chip is an important consideration.
When I bought a (single) Yubikey from their website late last year, it was Fedexed to me directly from their Palo Alto downtown office, not some distribution center in the middle of nowhere. That can't be cheap.
This flies in the face of previous promises where 'every key can handle an unlimited amount of accounts'. In my eyes, this looks like a big push towards phones as passkeys, and nothing else. Would fit with the Bluetooth sync strategy as well.