@nsa@hachyderm.io
"#Passkeys are useless to me because I use a fancy password manager and always look at the URL".
Yes but the other users of the site don't so you also have to pay the shitty 2fa tax like everyone else.
Also I promise you you can get phished.
I would simply develop an authentication standard that asks the browser to report the current origin so I can compare it to the expected origin such that I can't fuck it up
I just wish they fixed the usability flaws in the spec.
For example:
* there is no way to check if a user has a passkey and let the user log in with it seamlessly. To check, the user will get a popup and be asked for verification, and then shown an empty list if none is available.
* there is no standard way to annotate the passkeys in a good way, so when you open the security settings on the server, you just get a list of passkeys with very little information per entry.
* passkeys never expire, so if you get the opportunity to add one to some users account, they are backdoored "forever"
* if a website loses your passkey, a new one can't be created until you also delete the existing one on the client
* there is no way to sync across ecosystems, passkeys is the perfect vendor-lockin scheme, and will benefit Google and Apple for decades to come
With that said, passkeys beat passwords every time, and I still want them to win
1. Native apps can fire a passkey sign in if the user has passkeys that fails immediately if there are none with no UI. It's tricky to do on the web without impacting privacy, but we're exploring this! We know it's a problem.
2. You can use the aaguid and turn that into a user friendly name. E.g. webauthn.io does this. There's a json file out there with known mappings.
1/n
3. I don't think this is a problem... but if you really wanted to, you could have your service create a new passkey with the same user.id and that would overwrite the previous one after some amount of time. It might be possible to use the new automatic passkey creation to do that seamlessly, and I've been toying with the idea of using the capability to allow migrating passkeys to post quantum seamlessly.
4. This isn't true, the website can override the passkey.
2/n
