Comment by mkehrt
21 hours ago
Tell that to my mom who has created a bunch of passkeys all over the place without knowing what they are. I'm trying to unwind it but it's a mess.
21 hours ago
Tell that to my mom who has created a bunch of passkeys all over the place without knowing what they are. I'm trying to unwind it but it's a mess.
“All of the place” meaning where? There’s only a few places you can put them and they’re all more secure than passwords so it sounds like not a huge issue.
Passkeys are an antipattern in UX design. You want to make it simple for the users? Great! But stop treating them as too stupid to decide anything on their own. Stop locking them out of the decision loop and doing things behind their back. This is practically the corporate design philosophy of the past two decades. You can see this a lot in smartphone design.
I keep asking what advantages passkeys offer over TLS self-signed client certificates. I haven't got any answers so far. Perhaps increase the security by encrypting the private key with a password or an external token. This is safe, like SSH and unlike regular passwords, because no secrets are sent to the server. TLS certs and (encrypted) keys are more tangible and easier to manage.
Perhaps passkeys do offer some advantages over TLS certs. But can't those be added to TLS, rather than rollout an entirely new system? The infuriating part is that this facility exists in browsers. They just let it rot to an extend that it's practically unusable. Meanwhile, Gemini browsers are using it quite successfully (for those who use Gemini).
Passkeys ARE self-signed certs. You can store their private key on a hardware token, but you don't have to.
Their only difference is the automated provisioning.
> Passkeys ARE self-signed certs.
So they took something that works well and created a bad UX around it, while ignoring the working, yet languishing UI/UX that was already around?
7 replies →