Live data from Hacker News

Passkeys were invented by engineers with zero understanding of consumer brain

twitter.com

741–750 of 813 posts

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#741

Earlier quoted context omitted.

Why?

Passkeys cannot be stolen. Yes, don't say that what if someone steals my iPhone, PIN, and adds their fingerprint. Let's say eBay asks user to login. With passkey. Press and hold fingerprint etc. login done. Even with laptop. And average Joe doesn't want to maintain a keepassdatabse sync it. Yes, you can always use your own server etc but others have life.

how do I back it up and transfer it to a new device? This is relevant because an attacker can also do that.

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#742
post #647

Earlier quoted context omitted.

> Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors. They obviate the need for a user identifier as the key is itself unique, but removing the 2nd factor is a choice of the service, not the designers of the Webauthn standard. > Also they decided they should be cloud-synchronised The earlier versions of the spec required that the keys be resident in hardwar…

> The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud). From what I know, Apple ignores `platform` and `ResidentKeyRequirement` claims and always creates cloud-synced key pairs. Moreover, the strongest claim value allowed for the `ResidentKeyRequirement` is “discouraged”, which per spec is treated as SHOULD in RFC 2119 sin…

The service may require attestation and verify the actual authenticator metadata.

If the passkey is not accepted by the service, it can use the signaling API to indicate that the passkey was not registered validly.

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#743

Earlier quoted context omitted.

The author of this ticket seems to come across as an arrogant know-it-all that thinks "the threats i thought of (or personally face) are the only threats that are significant, fuck anyone in a different situation." I proudly print my entire KDBX file including passkey private keys and I encourage my elderly parents to do so too. Lightning strikes (and assisting people with cleanup and repair from them) have taught me…

>I proudly print my entire KDBX file including passkey private keys and I encourage my elderly parents to do so too. Do you mean you print the raw values to paper or some encoding that would let you reconstitute the file (some giant QR code or something?)?

I print a nice HTML document - each entry has each field/value in a HTML table and each group gets its own header.

On macOS I use Strongbox's Print Database capability. On Windows, I'm testing a KeePass plugin I created that does the same thing and more (not quite ready for public release).

If I'm still around and coherent, I can re-type it into a KDBX-supporting app by hand (or maybe if I'm lucky only enough entries to get to a backup in cloud storage).

If the worst happens and I'm no longer capable of using a computer, it's an obviously-important document for whoever is cleaning up after me (I bet most people would understand the importance of a document with a bunch of usernames and passwords). They won't have to somehow break into my computer first to be able to figure out what online/digital matters of mine need to be dealt with.

EDIT: My current printout is 46 pages long.

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#744

Earlier quoted context omitted.

Passkeys cannot be stolen. Yes, don't say that what if someone steals my iPhone, PIN, and adds their fingerprint. Let's say eBay asks user to login. With passkey. Press and hold fingerprint etc. login done. Even with laptop. And average Joe doesn't want to maintain a keepassdatabse sync it. Yes, you can always use your own server etc but others have life.

how do I back it up and transfer it to a new device? This is relevant because an attacker can also do that.

Buy a new iPhone. Sign into it. Everything is now available.

That is the reason: for the average Joe not having exportable passkeys is good.

Average Joe doesn't have to do backup. It is all automatic.

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#745
post #587
post #395

Earlier quoted context omitted.

I pair of hardware keys (Token2, Yubico, etc) has the benefits from both worlds.

Except enrollability. Got a new account? You need physical access to both tokens to enroll it. Got a new token? You'll have to individually enroll every website - provided they even support multiple tokens at all... Yubikey tried to solve this, for obvious reasons. Their proposal was DOA.

[deleted]

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#746

Earlier quoted context omitted.

A password manager let's me use my service specific credential from any device, securely and decentralized. Passkeys lock into a specific device and seem easy until you need to use another device. But instead of being a credential you own and control, across what could even be a local password manager, it's one password to everything. Maybe it is more secure than a regular password in some cases but it largely seems…

You're arguing against a straw man. All password managers support passkeys. Both apple and google allow exporting your existing passkeys to third party password managers too. Also each website gets it's own unique public key with passkeys. It isn't a single credential You're literally arguing a strawman

[deleted]

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#747
personally it works well for me as a way to login.

however, lately the anti-bot/spam shenanigans from big tech has ruined any ux work they have spent trillions on.

one fine day, i was trying to log into my google account at google's office. for some reason their internal wifi was serving the internet through a corporate vpn, which was based out of the US. this tripped their security system, which then made me jump 3-4 hoops to log in back to my account. i recall sms verification (where you send them a code), some part where i had to scan a qr code and open on my phone (not logged into google btw), and the usual 2fa, among others.

likewise ticketmaster asking for verification for a decently used account over the years out of the blue. this is when booking a new ticket from a residential internet without any shady business. was made to reset my password three times in a row, and still got blocked!!!

the false positive rate of these systems have reached a boiling point at some instances. yet they don't seem to stop the spammers and scalpers, but cause great pain to regular folks who don't pass the sieve. passkey-based verification is just a symptom of the larger problem.

PS: don't even bother using a non-normie browser, as it is a sure-shot way to get restricted, even on this website. it is as if we are all using tor browser if it is not the latest chrome.

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#748
post #223

Earlier quoted context omitted.

I’ve relied on iCloud as well, but just learned that it allows apps to store persistent data. This data is synced between all devices, and there’s no way for you to view or manage/delete it. Even determining which apps do this requires you to enumerate the apps entitlements, which is nontrivial. And so an app you install on your iPhone can have configuration or credentials persist to each iCloud-connected device, and…

Is this different from the per-app enumeration in Account —> iCloud —> Storage? That provides a means to delete per app

Does it provide a way to edit or at least view it?

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#749

Earlier quoted context omitted.

Nothing in the post you're replying to is about "is 2000 passkeys storable", it's about "if I have 2000 passkeys and I need to move between an Apple device and an Android device, do I need to establish a second set of 2000 passkeys"?

Not at the moment. But if you sign into google account in iPhone then you can use Google's passkeys in iPhone. At the end, passkeys are built not for the tin-foil, (I hate Google Apple fellows), I want to keep every single locally, RMS fans. No. A majority will benefit. End of matter. A majority don't change platforms (I have not seen them do it). And lets be honest - even if they were portable are you privacy person…

No, the majority will not. If through some miracles, passkeys gain sudden and wide adoption, there will be a day of reckoning come around the next mobile refreshment cycle, maybe earlier.

People break their phones. That is normal experience. Entirely unsupported by passkeys as they are today.

I'm actually surprised we didn't have more pushback for ubiquitous 2FA, as they have similar threat profile - i.e. addressing the tin-foil threats of cybersecurity aficionados, while entirely ignoring the common threats to real people, in particular the one of broken or lost mobile device.

Re: Passkeys were invented by engineers with zero understanding of consumer brain

#750

Earlier quoted context omitted.

> Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case. What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple.…

> the only possible way to compete with that UX is to sync the private key across the user’s devices This is my issue with passkeys. Either we lessen security to improve UX (syncing across devices implies extracting private keys from secure enclaves, at which point it’s no different to password syncing), or we have a proliferation of different keys per website across devices (assuming the website supports multiple pa…

It's still ignoring one of the main features of passwords for regular people, which is authority delegation via password sharing, aka. "could you please log in to my ${service} and do ${something}, my password is ${password}...".

Yes, that is a feature and a normal use case that has equivalents in meat space, that security aficionados refuse to recognize even exists, much less support.

Post reply on HN