| ▲ | emmaexe 2 days ago | |||||||
There isn't one correct answer because all those things are implementation dependent. Passkeys just define how a website, browser and OS communicate logging you in between eachother. If someone in charge of making a website designs a bad login system on top of that you will get a bad experience. > Do I need a unique passkey per device? If you store it in the device itself (passkey isn't moveable) and not a password manager (you can move the passkey around) then yes. > If my passkey is on my phone what happens if I lose my phone? Delete the passkey using another device. If your phone is the only trusted device/only device that had a passkey, begin account recovery (e.g. via email). > How do I rotate them? What if a device gets stolen? You shouldn't need to, if they are properly stored in the device (in hardware) and not a password manager they should not be extractable. But if you lost your device/it got stolen and you have no lockscreen password you would need another device that also has a passkey that you would use to invalidate the other one from the account settings page similarly to how you would change your password (you are logged in with another passkey, that is your "existing password" in the password model and you don't set a new password but instead delete the other passkey and create a new one). If instead you use a password manager and it gets breached, either rush in to create a new passkey (e.g. on device temporarily) and then delete the old one, or if they got ahead of you begin account recovery, similarly to if your password got extracted from your password manager. > How do I login on a device or browser that I've never logged in before? Similar to steam and discord's Qr code login system if you've ever used that. Ideally when you visit the website would generate a login session and you could then login from a personal device you have on you by scanning a qr code or manually entering a code (for devices without a camera). Probably also tick a checkbox that you are logging in on a public device and that you only want a short lived session, but such a feature doesn't generally exist in login systems that use passwords either, even though it would be convenient to have. --- All these answers above depend on the login system being well designed. If the people writing the website don't let you register multiple passkeys or don't make it convenient to register a new one whenever you login on a new device, or don't offer the aforementioned Qr code login system or don't offer good account recovery - you will have a bad experience. | ||||||||
| ▲ | xg15 2 days ago | parent [-] | |||||||
> All these answers above depend on the login system being well designed. If the people writing the website don't let you register multiple passkeys or don't make it convenient to register a new one whenever you login on a new device, or don't offer the aforementioned Qr code login system or don't offer good account recovery - you will have a bad experience. But this is one of the points being discussed here. All of depends on a large number of choices that each site owner will have to get right. You could always argue "well, it's the site's fault for not doing it better", but the matter is that the site owner has to decide those things at all - and if course they will make their own tradeoffs or simply don't bother with certain features. So you will always have a wildly inconsistent mix of different functionalities and constraints depending on the preferences of the individual services. Whereas with passwords, implementers don't have to do any of those choices, the basic implementation already supports all those usage scenarios. The QR code login flow is one such example. I probably have some bias that I don't like the thought of making my phone the sole authority for all my accounts, but even if you accept that, it's an exotic technically complicated flow for the exclusive usecase of "login on untrusted device". There are probably few sites that weigh that usecase high enough to implement the flow - whereas with passwords, there is nothing you have to implement, because the functionality is just a natural consequence of how passwords work. | ||||||||
| ||||||||