Hacker News Reader

Comment by Rygian | Hacker News Reader

> Safe from server leaks. Because servers only keep public keys, servers are less valuable targets for hackers.

It's still an attack scenario to keep in mind. If a server can be tricked into storing the wrong public key, authentication is defeated.

View on HN

By the same token, if the server can be tricked into storing the wrong password, authentication is defeated. However, with passkeys, even downloading the entire database doesn't give the attacker any useful credential information. This is in contrast to today, where a database download gives you salted & encrypted passwords that are (generally) knowable (given enough time). I'll take passkeys over passwords any day.

This is my view as well. I think in the more technical crowds but outside of people who actively deal in identity and authentication daily, there seems to be this fixation on the marketing of passkeys that focuses on the FIDO component, and this muddies the virtues of the specification.

Many focus too much on the (potential) MFA use case rather than the idea that we can use effectively the same tech as in Yubikeys (etc) to make phishing resistant authenticators everywhere.

The (IMO) messy rollout by the major platforms really doesn’t help either. They absolutely could have spent a little more time baking the UX and designing edge case mitigations, but they didn’t.

I think that is why it is both good and bad that Apple have effectively taken the lead in the rollout. They are great at UX and keeping an eye out for edge cases and trying to sand down the worst sorts of gotchas. If anyone can make sure that Passkeys feel good to the average user it is probably Apple.

On the flipside, that early lead also led to so many of the misconceptions about Passkeys that people have. People think it by nature has to be a locked, walled garden, because Apple has the lead and loves walled gardens when it has the lead.

I think that's why this newest rollout announcement is such great news (which we knew was coming, but wasn't obvious to some of those misconceptions from Apple being in the lead): complete integration with the larger ecosystem of password apps already in the App Store wild (use your 1Password passkeys just like you can use 1Password passwords), and a UX for grouping passkeys and sharing those groups with other contacts (that also helps with all the misconceptions about passkeys being some sort of crack down on password sharing).

These UX flows would have been great to have seen in the initial rollout to assuage a lot of fears about Passkeys. It is great to see them happening right now while it is still early enough to stop most of the FUD before it starts to get outside of the HN paranoia bubbles and into average consumer ears.

The point is that a hacker can’t use the public keys obtained in a data breach to access your accounts on other services. This is a common problem when a lot of people use the same email and password for many different sites.

Yes, but that's not a leak

And how might this happen?

account recovery process

Just chiming in to ask -- the immediate need for account recovery is in cases with lost or forgotten passwords. Am I right in assuming that account recovery becomes a much smaller attack surface when using passkeys? Or are there scenarios I'm overlooking?

It’s mostly how sites will likely still allow full account recovery with just sms-based authentication, making account recovery the weakest link. It’s still required, though, in case someone e.g. signs up with a passkey on their Windows desktop then forgot to enroll one on their phone before taking a vacation.

So you're covered for "forgotten" - but "lost" is still an issue. What happens when a user loses their passkey? (stolen phone, no backups, house fire, etc).

Got it, thanks. A blind spot on my part there. It's funny how quickly the concept of losing access to a phone has taken root, I'm fortunate to have never had that happen to me and I need to remember how easily it could.

Reply on news.ycombinator.com