Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sure they are: Passkeys are phishing-resistant, and random passwords are not. This is pretty basic stuff.


Random passwords in a password manager are also phishing-resistant. My password manager remembers the URL that I used the password in and will refuse to fill it in on other pages unless I deliberately work around that protection. They may be less phishing-resistant than passkeys (in which case add it to the list of small disagreements I have with the original poster), but it's not a wide open field for phishing attacks.

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.


Passkeys are cryptographically phishing-resistant, and password managers just disable a convenience feature when a heuristic check fails. It's not the same thing. I don't care if you feel like the latter protection is sufficient for you or should be for others; they simply aren't the same, and that was what the comment upthread suggested.


Whether or not they're the same as a bit of a red herring, the question is whether the marginal added benefit of cryptographic phishing resistance is worth the trade-off in UX which introduces new kinds of vulnerabilities due to undesirable user behavior and/or implementation workarounds. And to answer that question you can't just dismiss the security offered by password managers—it's a very real protection that needs to be factored in to your assessment of the strengths and weaknesses of each system.


Take it up with the person who said the two countermeasures were literally equivalent. You're not going to get anywhere with me on this.


Which user/comment are you referring to? The top-level comment? I'm the person you replied to initially, and that's not what I said, so I'm assuming you're referring to something else.


passkeys stored in a password manager aren't any more secure in practical terms than random passwords stored in a password manager

It is my contention that this statement is:

1. Categorical,

2. False, and

3. Categorically false


And you would be wrong. You somehow jumped from "in practical terms" to "literally equivalent".


They are not comparable in practical terms.


Maybe, maybe not. You went out of your way to attack a straw man instead of showing any of that. So why should I believe you now?


I have no idea who you are, am comfortable with who does and does not believe me here, and think you should do you. But no: the two approaches do not offer comparable practical security.

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.


Not at all. One phishing vector is: (On a phone call) "Hi, this is $your_bank, please go to your password manager, open the entry for $your_bank and read your password out loud to me on the phone, thank you!"

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.


One big selling point of passkeys is that almost every workaround is impossible, whether that is good security or bad UX or both seems to be under discussion


If that's one of the big selling points then that's a problem, because workarounds are totally possible and actively implemented in the real world. As an obvious example: syncing passkeys is a workaround for their terrible UX that takes them further from the original design in ways that compromise some of the original security guarantees.


Can you illustrate how workarounds to passkeys are being actively implemented?


Password manager support.

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.


Passkeys were always designed as being synchronizable and not necessarily be secure hardware backed.

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.


Attestation would be terrible to have in passkeys because it will allow sites to block certain implementations.

PayPal does this already by only allowing safari or chrome. With bitwarden on Firefox I'm locked out.


> Attestation would be terrible to have in passkeys because it will allow sites to block certain implementations.

Attestation is already coming. Why do you think Microsoft is pushing TPM2.0 so hard?


How so? Not the type of attestation we're talking about here (i.e. not the early 2000s trope of "zomg Microsoft is locking down our PCs", which ironically is what Apple is now doing instead, all without any evil TPMs).

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.)


All Apple and Google hardware have TPMs/secure enclaves.

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.


I'm sure Microsoft would have done that in the 2000s if they could have gotten away with it. All the big players did exactly that when they got the chance with mobiles that didn't have any precedent. And no I don't think it's ok even there. But I'm aware I'm a minority.

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.


> 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.


I just love that @wkat4242 (the parent comment you're replying to) lists attestation as the reason they moved away from Apple/macOS and you're (rightly) pointing out that both Apple and Google stopped supporting hardware attestation for WebAuthn/passkeys.

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.


It's not attestation per se that got me to move away from Apple. More the lock-in in general when it comes to Apple. And the opinionated design (use it as-is, few configuration options).

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. Half the new features of every release didn't apply to me because I use so many different systems. 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. That was the other thing that bothered me. For example, I used to simply boot into recovery and make a 'dd' image of my laptop. I can't do that anymore on an Apple Silicon mac. I used to change my sshd_config to block password auth but since SIP the file got reverted back with every system updated and dumped on the desktop in a passive-agressive move. I just don't want Apple to have more control over my system than me.

This was really what got me to hate macOS, it's just not fit for purpose for me anymore. I have never liked opinionated design but in the beginning of macOS X my opinion was much more aligned with that of its developers.


Yeah, as a user, I'm mostly happy about the lack of attestation. In an ideal world, only relying parties that really need it would request it, but views on who really does might obviously differ a lot between users and service providers.

> 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").


> 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.


If you have malicious code running on your laptop, it is game over in any case.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: