Comment by drhagen
8 days ago
Can someone tell why the whole standard for authentication on the web is not just this:
me: Can you show me my stuff?
website: HTTP 401, who are you? I understand EasyAuth 1.0, if that is good for you.
me: Sure, here's my EasyAuth 1.0: Hi <website>, I'm <user_id>. The time is <timestamp>. Signed, <digital_signature>.
You have described, at a high level, passkeys.
Well, it's a fair question why Webauthn ended up so much more complicated, which has unquestionably been a hindrance to adoption.
Because the various cloud providers want to lock you into their own proprietary ecosystem, of course. How else could they in the future force you to pay a subscription to be allowed to log in to any website?
Backwards compatibility. Webauthn is the same standard that has been used for physical security keys for decades. Passkeys are a simplification UX layer on top of decades of hardware support and a complex ecosystem of key providers and key types.
1. It's not that complicated
2. The complexity in the standard is there to ensure things are done securely (think: not doing password checking via comparison loop).
3. The unnecessarily complexity in individual implementations in websites and passkey stores is due to general baseline corporate "incompetence".
Admittedly, my experience comes from OAuth and Webauthn. I have yet to try to implement passkeys. My exposer to passkeys comes completely from long blog posts complaining about it.
2 replies →
Design by committee
Because you or someone needs to publish "<digital_signature>" in a way that cannot be forged, stolen, MiTM'd, or otherwise compromised. Basically the key generating that signature just becomes another password, far more difficult to use in practice, and sharing all the same disadvantages.
So no one implements it for site-local login. Even the biggest sites like Amazon, for example, still use old-school passwords+2FA.
The way secure auth works for small sites is that a third party[1] authenticates you, who the website trusts more than mere users. And that's where all the complexity comes up. You need something secure stored on your known-secure device, a password alone won't do.
[1] In practice Google or Meta. Occasionally Apple or Microsoft. Everyone else is noise.
> far more difficult to use in practice
I guess I am envisioning the user agent doing all of this. You go to a site and create click account, your browser shows a pop-up: "<website> is asking you create an EasyAuth account. Would you like to create an account on this site?" If you click yes, then the user agent does this in the background:
website: Sure you can have an account. Use this token <token> once and this ID <user_id> forever.
me: Ok, here's your token <token> for ID <user_id> and my public key is <public_key>. Signed, <digital_signature> to prove it works on my end.
Maybe generating a unique public key for each website is not substantially better than generating a password, but at least a signature cannot get stolen on the server side or in transit. You wouldn't have to change your public key if their database got slurped.
Passwords also aren't standardized, so they are pain to generate (special characters required or disallowed?). They don't reliably autofill into a website. You still have to go through a manual flow to login; user-agent doesn't just keep you logged in. I guess I would be fine if the user-agent knew how to authenticate me to every website.
Maybe this is what the passkey system was before it got designed-by-committee'd into oblivion. I am just always amazed by how complex authentication is when the user-agent should be able to handle this rather painlessly.
> I guess I am envisioning the user agent doing all of this.
That's literally what a passkey is, that the linked article argues against. It relies on the platform vendor of your device hardware to validate the full stack of software. You can't just do it in a browser because anything that reads the browsers data (or attaches a debugger, or runs the browser in an instrumented VM, etc...) can exfiltrate the key.
> Even the biggest sites like Amazon, for example, still use old-school passwords+2FA.
While that is an option, I've been using passkeys on Amazon since 2023.
Right. For clarity: the choices are "use a third party authentication mechanism (like passkeys)" or "roll your own". And among vendors that continue to roll their own authentication, even the largest and most capable (like Amazon) don't try to do crypto like the upthread commenter was suggesting. It's just not practical unless you control the hardware platform. Passwords and telephone-2FA remain the rule.
Ok, I guess you also need a way to say "Oh, and next time I talk to you I'll use public key <public_key>."