Passkeys and Modern Authentication

(lucumr.pocoo.org)

184 points Bogdanp | 1 comments | 02 Sep 25 13:47 UTC | HN request time: 0s | source

Show context

alphazard ◴[02 Sep 25 17:11 UTC] No.45105959[source]▶

Unfortunately the tech community is full of people who pride themselves on being aware of and advocating for the latest standard put out by whatever company. That's how we end up with lots of complicated nonsense like most of what is sent in HTTP headers, or the contents of a TLS certificate.

On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.

replies(10): >>45106121 #>>45106140 #>>45106170 #>>45106176 #>>45106183 #>>45106261 #>>45106406 #>>45106911 #>>45107421 #>>45107745 #

agwa ◴[02 Sep 25 17:38 UTC] No.45106406[source]▶

>>45105959 #

The simplicity of SSH's public key authentication comes with a significant privacy downside: https://www.agwa.name/blog/post/whoarethey https://words.filippo.io/whoami-updated/

This isn't such a big deal in the SSH ecosystem, but it would be a disaster on the Web where there is an enormous incentive to track users. Part of WebAuthn's complexity comes from addressing that.

replies(2): >>45106633 #>>45117388 #

1. NoGravitas ◴[03 Sep 25 16:07 UTC] No.45117388[source]▶

>>45106406 #

Use a different public key for every site, specify which one in your .ssh/config. Only offer keys for the site(s) they correspond to. Done. This is already best practice, but could easily be improved by simple tools to manage it. You do not also need things like attestation and restriction of backups.

↑