←back to thread

225 points Terretta | 1 comments | | HN request time: 0.206s | source
Show context
dustyventure ◴[] No.41864055[source]
I find it silly and backwards to implement this. One has a private key and one could use it to act as a ~CA attesting for the establishment of another key with the relying party. Then one would always know what the hell happened when keys inevitably end up getting compromised by the poor practices of some of the vendors.
replies(1): >>41864672 #
greycol ◴[] No.41864672[source]
It's clearly a compromise, but if we were going for a perfect implementation then everyone would have a local/self hosted soloution. This just means in the case of a bad vendor/unwanted default/change to a better vendor you can migrate away from them quickly (and not need to visit them again) without having to update all your pass keys at once.

I'd expect good vendors to be popping up "You haven't updated your passkey for this site since you migrated to us, you should go to your account settings and do so" on login to a site.

replies(1): >>41866732 #
1. dustyventure ◴[] No.41866732[source]
Leaving everyone finding the custom way to update/add a passkey when the fix for that would prevent sharing keys and needing to manually do something 100-1000 times to regain a little security.

The need for this compromise doesn't even make sense in light of all the past compromises. We pretty much know the RP is an an always online web site instead of variety U2F enables because that was apparently too hard and thrown out with everything else that didn't please always online keyvault makers.. Who is needing to compromise here?