I still don't understand what problem passkeys solve for me that my random passwords in my password manager didn't already solve. This is both about threat model and credentials management.

Threat model: it seems to me that passwords protects against whom I want to be protected against.

Credentials management: I sync my password manager db across my devices. If I lose one device for any reason, I have the passwords on the other ones and in the backup.

> I still don't understand what problem passkeys solve for me that my random passwords in my password manager didn't already solve.

I just don't understand them at all. As in, I somehow can't just wrap my head about that they are.

My current understanding is that they are like NIH client TLS certificates, but whose content you can never even read (not even the encrypted bytes), that you can't backup (because you can't read), and that's why you have to use a proprietary device with custom hardware from a random company to act as a middleware between your actual secrets (hidden in-device) and you, and trust that device and company to handle the auth for you.

At least that's my current understanding, as far as the details I could find about them (my search terms seem to be failing me). If I could understand them better, maybe I wouldn't be so pessimistic.

So, given that that's how they look to me, they rank pretty low in my trust scale of stuff that I should let handle my auth, including ownership of any secret material. That scale currently looks like this (most trusted first):

(1) Open source software > (2) Desktop computer components that you can plug into motherboard > (3) Smartphones > (4) Let Google/Apple/Microsoft generate and control my secrets > (5) USB sticks from random companies.

(P.S.: Yes, computer components are closed, but even if I don't completely trust them they still rank higher based just on them having existed for longer, so you kinda know what to expect and how incidents are handled.)

> I somehow can't just wrap my head about that they are.

Passkeys are just resident webauthn credentials. Nothing more complicated than that.

> and that's why you have to use a proprietary device with custom hardware from a random company to act as a middleware between your actual secrets (hidden in-device) and you, and trust that device and company to handle the auth for you.

There's a few open source password managers that support passkeys now.

> Passkeys are just resident webauthn credentials. Nothing more complicated than that.

THIS is the explanation that I was looking for. Short and straight to the point.

Thanks!

The problem they solve is that almost nobody uses a password manager. The vast majority of people log in using PartnerNameYearOfBirth or Password123 and about two decades of trying to get people to stop doing that have failed.

For people using password manager implementations, passkeys also add a layer of protection by being practically unphishable. This comes at the restriction of companies not being able to drop the domain names they once used to set up authentication (there is tooling for migrating between domains, though) as passkeys bound to old domains won't be valid for new ones.

If passkeys are implemented well, using hardware encrypted storage, you also never risk a copy of your passwords falling into the wrong hands when you get infected by malware. Synchronised password databases are vulnerable to basic key loggers in a way that passkeys aren't.

> The problem they solve is that almost nobody uses a password manager.

Numbers pulled from Google seem to suggest 1/3 or so, which probably varies a lot across the world. But that’s not too bad given it’s never really been shoved down users' throats. They’ve been pushed pretty hard in PC magazines and media. They’re not entirely obscure.

> For people using password manager implementations, passkeys also add a layer of protection by being practically unphishable.

True, but it’s still some protection: auto-fill won’t work on a different domain so phishing is harder. However, note that many legit sites, even payment gateways etc, use multiple strange-looking domains sometimes. This is beyond irresponsible imo, and the clear fault of the service provider.

> If passkeys are implemented well, using hardware encrypted storage, you also never risk a copy of your passwords falling into the wrong hands[…]

This is only theoretically true. Regular people aren’t able to provision and secure multiple auth devices in case of house fire, theft, or loss. What happens in practice is an account recovery flow, usually through email, sms or support, which is prone to all kinds of non-crypto attacks, including phishing.

Per-device passkeys alone are possibly an improvement in convenience but not as a last-resort identity, in practice. From a security POV it’s very similar to pw managers, and so far I like them more because of they’re vendor agnostic. Ideally we’d have pw managers simply manage key material instead of a random pw, when supported by the provider. I already use GitHub this way, with Bitwarden.

> True, but it’s still some protection: auto-fill won’t work on a different domain so phishing is harder. However, note that many legit sites, even payment gateways etc, use multiple strange-looking domains sometimes. This is beyond irresponsible imo, and the clear fault of the service provider.

Which is why the Passkeys spec clearly spells out this responsibility to the service providers and breaks if they get it wrong, truly making it their problem to solve. (It's the direct source of most of the complications described in the linked article's section #13, and indirectly mentioned in other sections.) Passkeys are domain specific and only domain specific and browsers do and will enforce that. It does what auto-fill can't and if a service provider uses multiple domains and gets things wrong, they are broken and have a service outage on their hands to fix, rather than "maybe they temporarily changed domains" still being a phishing vector for those relying on auto-fill as an anti-phishing deterrent (that still catches people that should know better because too many well known services are unreliable about temporarily jumping domains or just plain using way too many domains due to internal silos that shouldn't be so visible externally [cries in Azure]).

Thanks for clarifying. And I agree with you. Users doing manual domain matching by gut feeling and glancing on the critical path was not a great idea, but made even worse by jittery companies who confused DNS with their org chart. So in that sense passkeys are superior, even to (traditional) pw managers. I’d be the first to cheer for a great passkey integration in my pw-manager of choice.

What I worry about is that companies will (yet again) grossly misuse improved auth technology to make the combined auth flows an even bigger shit mound than it already is, both for users and the poor souls who have to implement them. I don’t know exactly how, but I’m sure they’ll find a way.

What all big platforms encounter is that the actual attacker already knows the password. That is because (1) it has been leaked on another platform and the user uses the same or (2) because it has been stolen from the computer of the user or (3) the user gave it away voluntarily because he has been phished. Most of the time it is (1) and (3). On Hacker News, we are a very tech-savvy group, and I agree if you stick to your approach that's secure. In a bigger view, that is absolutely not the reality for big B2C platforms. With passkeys (1) and (3) technically impossible and (2) is nearly impossible. Does that make sense?

The problem is that, while your setup has excellent de-facto security, what matters is security posture. The parties that you authenticate to do not know and cannot know that your actual security is better than your posture visible to them. They have nothing to rule out the hypothesis that you use the same password everywhere else, and they still suspect that you can, by mistake, enter the same password on a phishing site.

By using passkeys, you prove to the relying parties that you do not use the same credential on another possibly insecure (hackable) website and that the browser will not reuse the credential for you on a phishing site, as it is technically impossible.

EDIT: all of the above is based on the marketing materials. I do not have any passkeys, but I use my Nitrokey U2F for 2FA on some important websites. I will possibly switch once platform-level or browser-native support for passkeys (as opposed to extensions like the ones provided by BitWarden or KeePassXC) is available on desktop Linux.

the principle is the reason why I am staying up to date on this. In principle I would feel better if the stuff stored in my bitwarden account are hardware related keys that do not help an attacker even if they guessed my master password and downloaded them all. I consider that an important security benefit... although honestly at this point I don't even know anymore if this is still true given that passkeys now sync across hardware... surely...

Disclaimer: I am a Corbado Co-Founder.

I have commented further down, and I really think that, from a broader perspective, there is a great chance that there will be strong positive effects for consumers. I agree that there is a threat with attestation being used to lock out certain implementations. On the other hand, the technical details do not allow that because the IDs can be changed easily. Also, there is no attestation enforced for passkeys, and that should stay that way. But I agree with one concern: If Apple or Google wanted to achieve such things, they could, just because of their market dominance in browsers. However, I just do not see how that would make sense for them from an economic perspective.