[jjav]

> more secure

"more secure" is a completely meaningless statement, I wish this usage would die already (in general).

You need to talk about security in the face of a very specific threat, then you can say solution A is better than solution B against threat T1, worse for T2 and about a wash for T3 and so on.

Security is not a linear scale from 0-100 where you can say "more secure". There are many different criteria and any given solution will be better in some, worse in others. You must do a threat model for your specific use case to say if something is better or worse for those specific threats, and keep in mind other people will have very different threat models for the same solution.

[jesseendahl]

Threat #1: Credential theft from server breaches

Threat #2: User creates a weak credential

Threat #3: User reuses a credential (uses same credential across multiple services)

Threat #4: Phishing

Attackers use huge password dumps compiled from multiple server breaches, and then try them against other services. Relying on a combination of the fruits of their labor from all four threats, attackers successfully compromise millions of accounts on the internet every year.

If you want to see the data, check out the Verizon Data Breach Investigation Report that comes out every year.*

These threats affect a majority of both consumers and enterprises.

Passkeys address all four of these major real-world threats. Passwords address none of them.

Threat #1 mitigation: with passkeys, only a public key is stored on the server. Attackers can steal all the public keys they want; it will not help them compromise any user's account.

Threat #2 mitigation: passkeys (which are WebAuthn credentials) are guaranteed to be cryptographically strong. It is not possible for a user to generate an insecure passkey. This is because the browser the the Operating System APIs take care of generating the credential.

Threat #3 mitigation: passkeys (which are WebAuthn credentials) are guaranteed to be unique. It is not possible for a user to reuse the same passkey across multiple apps/websites. This is because the browser the the Operating System APIs take care of ensuring that a new, unique credential (passkey) is generated for every new app/website the user sign's into.

Threat #4 mitigation: passkeys (and all WebAuthn credentials) are bound to the server FQDN at the time they are created. The browser and Operating System APIs take care of ensuring the credential is only ever sent to the app/website server it was created for. Users cannot be tricked (via phishing) into using their passkey on a malicious app/website controlled by an attacker.

* https://www.verizon.com/business/resources/T249/reports/2023...

[sanitycheck]

You are correct about all of that.

But personally, as a technically able user, my risk of randomly losing access to my Google (or MS, Apple, Meta, etc) account is far greater than from all those threats combined.

If we had a trustworthy and accountable authority operating this stuff then it would be great. But we don't, we have a bunch of companies who are neither of those things.

It's like mandating that everyone must use self-driving cars that are on average safer than human motorists but occasionally randomly drive off a cliff.

[jesseendahl]

You can use whatever passkey/password manager you want to though. You don’t need to use Google or Apple’s password/passkey manager apps if you don’t want to. Passkeys are WebAuthn credentials, which is an open standard, and it’s being supported by an increasing number of password manager apps.

[sanitycheck]

In theory. Let's see how that pans out over the next couple of years, I think imposing platform lock-in in is going to be impossible for them to resist.

[bshacklett]

What about the users who _aren’t_ technically able? That’s where this technology is most important at the moment.

That aside, what happens if you lose your current password? Every major platform out there has a method for recovery. Why can’t that be used for passkeys as well? I don’t see how there’s any incentive for companies to lock us out of accounts, when the platform is pointless without people consuming it.

We may have very little power, as users, but if enough people have trouble getting into their own accounts, that’s going to directly impact the bottom line of the company locking them out. From a purely capitalist standpoint, that’s a really good reason to make sure that that doesn’t happen.

Lastly, at least Bitwarden is planning on having passkey support in their password manager very soon, so there’s real competition that will allow users to be in full control of their own passkeys.

[jjav]

Password managers completely solve #3 and #4. They also largely solve #1, unless the leak happens from a company that stored them in cleartext or base64. But since the password was unique, it doesn't matter in practice except for that single backwater site so who cares. Not a threat.

Password managers don't solve #4. But you left out the huge one, losing access to the account. Which for most people is a larger risk than all the others put together.

For just about every person and account, the near-zero chance of getting personally spearphished is much less relevant than the risk of complete loss of access.

[jesseendahl]

>But you left out the huge one, losing access to the account.

Losing access to your passkey/password manager is a separate concern from the strength of the credential itself. Passkeys and passwords are just credentials. What you use to manage them is a separate concern. The concern about losing access to your passkey manager is super valid, but that same concern applies to all password managers that exist today. It's not a new concern that's specific or unique to passkeys. Yes, if you lose access to your password/passkey manager, then whatever solution you're using better have a great recovery story.

I know that at least both 1Password and iCloud Keychain have pretty great recovery flows. I am not sure about Google or the other password/passkey managers (I haven't looked into it deeply).

>of getting personally spearphished

100% agreed that most people don't need to worry about spear-phishing attacks. But that's (sadly) not super relevant, because many users fall for run-of-the-mill basic phishing attacks that any reader of HN would never fall for in a million years.

[keskival]

The most problematic and the most probable security risk I have relating to logins is losing access. It for example took a week to restore access to my Apple account after I had forgotten to update my phone number there.

Since this is the greatest security problem, I would hope all the vendors trying to improve security would focus on that.

[jjav]

> The most problematic and the most probable security risk I have relating to logins is losing access.

Exactly. Unrecoverable secrets tied to closed hardware solve for the scenario where your most important criteria is that no attacker be able to ever access your account, even at the expense of yourself possibly losing access to it forever.

Does this solve a problem anyone actually has for consumer accounts? No.

That threat model makes sense for highly classified information where it is preferable to lose the information forever than have an attacker get it. Other than that, it's not a reasonable threat model to optimize for.