Hacker News Reader

> And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.

I would be careful with the use of "suboptimal" here. PIN codes or mobile apps are possibly more convenient to some people, not necessarily more secure (a PIN can leak, a smartphone can be hacked).

I would argue that hardware keys are optimal in the use-case they solve. It's just that not everybody wants to solve this use-case. And that's okay: passkeys should allow users to choose.

Yea, the physical key is, to me at least, one of the top human inventions.

Ubiquitous, cheap, convenient, and provides sufficient security. My little brass key never needs charging, never refuses to open the door because I didn't apply the latest over-the-air update, doesn't phone home to an advertising firm to track every time I open and close a door.

I can make as many copies as I like and give them to friends and family in case I lose mine. There are some scenarios where it might be nice to have a smart lock, but for me at least, they are so few and far between that I'll stick with this tiny bit of metal.

I completely agree. I also call "citation needed" on physical keys being replaced.

This is valid: use case matters. But almost no one has a use case for which hardware keys are optimal.

If you live in an area where you don't have bars on your windows, you don't gain more security from using a physical key over a PIN or app. (Even if you do have bars, the physical key is likely still suboptimal).

If you're a regular user of the kind of application where anyone ever thought passwords were a valid authentication solution, you don't benefit from a hardware key.

And it's not just a question of more security than necessary: using a security mechanism that is overkill for your needs can actually leave you with lower total security, because you'll end up doing things to make your life more convenient that are worse than what you'd have done with a weaker mechanism (like in the physical case leaving the door unlocked to avoid locking yourself out).

I guess my point is: "don't ignore your tech-savvy users".

And more generally, don't think that 99.9999% of your users are morons. In this case, all it costs is to leave an alternative in the list.

Too much of the modern software completely sucks because the industry is obsessed with "hiding complexity". We should not hide complexity, we should offer abstractions on top, and leave access to the lower-level as much as possible.

I think the passkeys would have remained a great idea if all passkeys were provided either by hardware devices not sold by cloud services vendors, or by software not written by OS vendors.

I largely agree with your point, and I don't think most users should be using hardware tokens. But the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.

I stand by my original statement that the standard was fine until users started getting shoehorned into "use Google passkeys on your Android".

> by software not written by OS vendors.

In an ideal world, I'd prefer that to.

In the practical one we're living in, this would mean that almost no website would implement them, because almost no user would be capable of using them.

As much as I dislike the platform lock-in consequences, bootstrapping a two-sided network is incredibly hard and usually does not succeed without something aggressively pushed onto users (e.g. by preinstalling and preselecting it) to kickstart things. In the best case, this is then quickly replaced by user choice, and that's what has fortunately happened for passkeys.

> the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.

Do you mean TPM as a generic term for a hardened secure element/enclave? Unfortunately, these are not standardized at this point (actual TPMs are, but these are a PC thing).

And what would be the point? I could see secure enclaves/elements implementing CTAP2 instead of a proprietary interface, but I don't really see the benefits of that. The much more important thing would be that all applications on the OS can access that implementation through some API, and that would reasonably be the "FIDO backend" APIs both iOS and Android already provide.

> 10 recovery codes

Mostly unrelated, I fondly remember Google doing one of those "prove you're you" checks when I was in a different state, allowing me to waste one of my 10 recovery codes as one of the options, and still refusing to let me log back in till I got back on my home WiFi a few weeks later.

> Physical keys work because locksmiths exist,

Physical keys are not a security tool. They are a tamper evidence tool.

> have no equivalent of locksmiths

...because there is always someone on the other side of the door who is entitled to change the lock for you.

> Hardware keys were designed for a spherical humanity

They were just designed for a world where there is actual customer service. This apprehension on hardware keys seems to be rooted mostly in this fact.