Password managers have already made passwords obsolete. I literally don't know any of my passwords except my master one. Passkeys are an insanely overcomplicated solution we don't really need.
Browsers just need a simple HATEOAS API for password managers to hook into, and web apps expose some HTML that triggers the browser. The password manager can then determine how to authenticate the user (however the user wants!), auto-inject the secret for that website, and the user is automatically logged in. E-mail reset if anything goes wrong.
From the "we're a website that wants super fancy security" perspective, I get that they want something more complex. But there should be levels of security that the user can opt-in to.
For example: most websites are fine with a simple password hash, assuming the password manager uses random passwords. Any website can implement that, every password manager can implement that, and it's better than 99% of regular users' password use today. So there's your baseline auth method.
Then if you want something like TOTP, OIDC, public-key crypto, etc the server can advertise it, the client can opt-in to it, and authentication can continue. But not every site needs to implement it, and not every user cares to use it. Basically, we don't need every site and every user to use the most secure methods. We just need to make it easier to get a baseline of improved security, and allow people to slowly opt-in to stronger security.
> Passkeys are an insanely overcomplicated solution we don't really need.
This is simply not true. WebAuthN is not overcomplicated needlessly (I wouldn't even call it overcomplicated, it's literally just a signed challenge/response dance). It improves on Passwords+2FA in a few notable ways:
1. It prevents shared secrets from traversing the wire.
2. It naturally enforces that users are all using secure authentication keys without password rules nonsense.
3. It kills 2FA by allowing Relying Parties to request user presence verification as part of the primary challenge.
4. It is origin-bound which mitigates phishing.
Passwords don't have any of these properties. And since your password manager handles the details for you, why wouldn't you want it to improve its implementation under the hood making things better for you with zero effort on your part?
I'm desperately looking forward to my password manager integrating support for Passkeys such that I can:
1. Back up my keys to paper and restore them from paper
2. Disregard/end-run around the "user presence verification" challenge if I want to.
I already deal with a ton of "acknowledge this push notification" or "type in this TOTP code" to verify, and automating every one of those interactions has lifted a huge amount of distraction and hassle from my everyday login-access dances interrupting me every hour or two.
I worry that more and more security people will make their orgs require authenticator attestation, which basically compares a burned-in cert against those certs blessed by FIDO. If too many websites submit to that stupidity, the idea that you can use your Bash-scripted password manager for resident key auth becomes a figment.
That is all way more complex than you're acknowledging. I bet you that for the hundreds of millions of dollars that will be spent every year on all of that crap, and all of the pain it will cause in a variety of ways, it will prevent maybe 1000 actual attacks globally per year.
Security does not need to be an arms race. Good enough is good enough.
Frankly I don't like the website getting to determine how I practice my own personal security: that's just the path of corporate lock-in, and it also has exactly one outcome - everyone will select either "maximum" because "that's secure" or "minimum" because "user experience".
It's the worst of both worlds (i.e. the insufferable thing banks do where they try to force you to type in your password with the mouse).
Browsers just need a simple HATEOAS API for password managers to hook into, and web apps expose some HTML that triggers the browser. The password manager can then determine how to authenticate the user (however the user wants!), auto-inject the secret for that website, and the user is automatically logged in. E-mail reset if anything goes wrong.
From the "we're a website that wants super fancy security" perspective, I get that they want something more complex. But there should be levels of security that the user can opt-in to.
For example: most websites are fine with a simple password hash, assuming the password manager uses random passwords. Any website can implement that, every password manager can implement that, and it's better than 99% of regular users' password use today. So there's your baseline auth method.
Then if you want something like TOTP, OIDC, public-key crypto, etc the server can advertise it, the client can opt-in to it, and authentication can continue. But not every site needs to implement it, and not every user cares to use it. Basically, we don't need every site and every user to use the most secure methods. We just need to make it easier to get a baseline of improved security, and allow people to slowly opt-in to stronger security.