Comment by BoppreH

> and suddenly I'm enrolling them everywhere without ever noticing

That's a clever attack and it indeed seems viable.

In my proposed protocol the public recovery key defines a "profile", and the account "username" is generated based on this key plus the service domain. So an attacker replacing this key would be reflected in the app as a completely new profile, and cause all your logins to fail. Not a perfect mitigation, but something.

I would be happy with that already, but I think even better solutions might exist.

Another issue of using one "master recovery keypair" naively with passkeys, is that you have to register the same recovery public key on every service, losing your pseudonymity. In my protocol that's not a problem because the recovery key pair is used for decryption, not signature, so the "public" key is never shared. Also, all these services already require an email anyway.

(I'm not trying to advertise my protocol because I never figured out a good way to do multi-device sync without trusting the cloud or having bad ergonomics. SQRL solved it by having deterministic keys, but that makes much worse the problem of a past leak compromising your future accounts)

> Nothing prevents an attacker [...]

I mean, hopefully the device security does! That's as bad as someone adding a hidden forwarding rule to your email account, or adding a new device to your password manager cloud sync.