This isn’t true, and that’s where your confusion comes in. Passkeys cannot be phished because the protocol includes the server name and does not expose the key to the remote server. The past decade of U2F/FIDO/WebAuth deployment has used that as the marquee selling point because it’s a very common exploit which cannot easily be prevented with traditional passwords and MFA.
the only difference is maybe in-app browser where the passkey integration might work more easily but even so:
1) it is still a matter of integration and/or using an actual browser
2) in-app browsers are inherently insecure anyway (at least on android)
No, it doesn’t. Most password managers allow you to fill passwords for other domains and all of them allow copy-paste. The people who support those users know that phishers can convince people to do that which is why they’re encouraging adoption of WebAuthn.
And this is an important distinction to make—if passkeys have a terrible UX (which right now they absolutely do) and are only marginally better at phishing protection than a password manager, they could actually be a less secure solution overall by encouraging lazy workarounds.
It is my contention that this statement is:
1. Categorical,
2. False, and
3. Categorically false
From the questions and comments across the rest of this thread, the misunderstanding here seems clear: the person I'm responding to did not realize that FIDO2 cryptographically binds credentials to sites.
If my password manager running on my desktop can provision and access the passkey for use on another device like my phone, then so can malicious code running on my desktop, and exfiltrate it to hackers. The original design, where the private key only exists on a TPM and the private key never leaves the TPM doesn't have that flaw.
I think there’s a place for both of them in WebAuthN based on the security/availability/convenience tradeoff which will be different for every application.
If you care about your users only using the trusted hardware, non-synchronizing kind, you have to use attestation anyway (or malware running on their device could create credentials that only appear to be backed by secure hardware).
Unfortunately both Apple and Google seem to have unshipped their attestation support without replacement (they used to support hardware backed credentials in their devices too for a while) in the interest of not confusing users about what is and isn’t synchronized – now everything is.
PayPal does this already by only allowing safari or chrome. With bitwarden on Firefox I'm locked out.
> PayPal does this already by only allowing safari or chrome. With bitwarden on Firefox I'm locked out.
It works for me! However I do vaguely remember having to set them up on Chrome initially, but after that, they now work well even in Firefox. (Only on my computer; on my phone, I get an absurd non sequitur of "security keys only work on desktops").
Oh ok, I haven't tried that. I don't even have Chrome installed anymore.
And yeah I get that message too on my phone, even with standard FIDO2 MFA (not full passwordless Webauthn). Stupid because it does work just fine with other sites.
Attestation is already coming. Why do you think Microsoft is pushing TPM2.0 so hard?
Apple and Google very intentionally threw FIDO attestation out of the windows without replacement, and Microsoft frankly doesn't matter enough for non-corporate contexts at this point. (Imagine your bank only allowing passkeys on Windows, but not iOS, Android, or macOS.)
And yeah I moved away from Mac for this reason among others. My devices should answer to me and me alone.
But I think the upheaval in the 2000s helped to make the TPM not the horror scenario it could have been. I don't think the ruckus was overblown at all. Don't forget Microsoft still wanted to kill Linux back then.
And yes Apple has tpm. It's just built into the cpu and called differently.
Yeah, so does Google. But as mentioned before, even though they were both using it for WebAuthN in the past, they both stopped doing so.
What stronger proof for attestation being dead in the context of WebAuthN can you possibly get than the two largest implementers actively discontinuing it?
There are many good reasons to be cautious of how attestation is used and critically examine who it serves – a company you're doing business with, you, or both – but in this specific context, it's arguably no longer relevant.
This really embodies what's wrong with the world in 2024 — people believing in their world views so strongly that they ignore actual real world evidence that is directly contrary to their very strongly held but incorrect world view.
Every release macOS got more closed and removing features I cared about. At the same time introducing stuff that only works if you're all-in on Apple. I use every OS under the sun. So that didn't work for me. Because all Apple's cloud stuff works on Apple alone (with a handful of exceptions on windows).
The lock-in of passkeys was just one of the things that bothered me. Not really the attestation per se, I'm aware it doesn't currently have it though I wouldn't be surprised if they introduce it if passkeys actually take off.
But like I said, Apple does have hardware control over other features. They do have a secure element which is just like a TPM which blocks you from changing certain files on the system and if you disable system integrity protection they turn off some of the features of the OS, like the ability to use iOS apps on macOS. It's basically DRM.
Android calls it the Play Integrity API now. Hardware-backed enforcement isn't reported from the attestation servers to 3rd-parties yet because there are still a few old devices with broken implementations, but that switch can be flipped at any time.
The only remaining gap is Windows.
You can't read out a passkey, nor can you read out a challenge to somebody that they are to sign with their passkey, because it's not possible by design.
Are you sure that Microsoft’s solution means that they are “physically incapable of restoring a customer’s account?” Apple’s system keeps copies of recovery keys in their cloud [1], unless you explicitly tell them not to do this. It seems like a reasonable compromise for most people’s security needs.
[1] Or effectively something like that.
Another factor here is the number of logins that a user is required to perform. Anecdotally this seems much higher in a corporate setting than personal. I might login to Microsoft SSO 15+ times per day for different services. Signing in to apps on my phone is rare.
We're not talking about annoyance here, we're talking about data breaches on the one hand and permanent account lockouts on the other. There is no world where the majority of people remember distinct passwords for each service, and there's likewise no world where the majority of users carry a Yubikey or even download their recovery codes at all, much less carry them with them.
So we're left really with two choices at the extremes: do we go for the failure mode where people reuse passwords and lose money and data that way, or the failure mode where a company is physically incapable of restoring a customer's account? Given the choice between these extremes, companies will always choose the former.
Now, these extremes aren't the only choices, but then you get to the crux of OP's argument: passkeys stored in a password manager aren't any more secure in practical terms than random passwords stored in a password manager. Your auth system is only as secure as its recovery mechanism (which is the observation that led Slack to initially not bother with passwords at all).
There's one way in which I disagree with op, which is that passkeys prevent users from typing in a password and storing it in the password manager, which many users do—they effectively enforce random passwords rather than it being just a best practice that needs to be taught.