Live data from Hacker News

Passkeys: A shattered dream

fy.blackhats.net.au

451–460 of 789 posts

Re: Passkeys: A shattered dream

#451

I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not in…

I agree, framing it as a mental model makes sense.

Here’s the issue: when a site rejects my password, I understand the potential reasons—wrong site, wrong account, or forgotten password update. But what does it mean when a passkey fails? How can I resolve this? Is it even fixable?

My lone attempt to use a passkey for login involved an unrecognized fingerprint authentication, leading to repeated failures and ultimately, a return to traditional passwords due to the opaque nature of passkeys.

For now, I’ll stick with what I understand.

Re: Passkeys: A shattered dream

#452

Earlier quoted context omitted.

I agree. So far I think KeePassXC is the only one that allows you to export your Passkeys. I believe Bitwarden are working on it as well. That said, it's unclear whether this will provide any portability of passkeys between providers.

untrue, 1Password stores the private key just like any other key material, and one can export it or get the private key from the bamboo menu "passkey": { "type": "webauthn", "createdAt": 1696352105, "privateKey": "eyJrdHkiOiJ...", "userHandle": "cafebabeDeadBeef..." },

Where did you see that?

This comment just 4 months ago from 1Password says that exporting isn't possible: https://www.reddit.com/r/1Password/comments/18m4iph/comment/...

And I haven't seen any announcements in the opposite direction.

————

Edit: so I just checked and I can confirm that it's not possible to export passkeys from 1Password. Neither of the two available export options include passkeys.

> • 1PUX A 1Password Unencrypted Export (1pux) file will export all your data, except your passkeys. You'll need to create new passkeys with your next password manager

> • CSV (Export only certain fields) A comma-separated values file (.csv) will export only certain fields. It won't export data such as custom fields or file attachments.

Re: Passkeys: A shattered dream

#453

Earlier quoted context omitted.

Keys can require a pin (or maybe a password depending on implementation). But in general I haven't felt these are secure enough for the reason you say. While my practical threat model today would make passkeys seem great, the theoretical future threat model in my head does not support it.

PINs and passwords on HSM keys like this are typically very secure as they will wipe themselves or at least lock themselves after a small number of failed attempts. For example if you only allow 5 failed attempts a 4 digit random PIN has a 0.05% chance of being guessed and a 6 digit PIN is 0.0005%. So the only real risk is key extraction, hardware key extraction is always possible but likely incredibly expensive, so…

PIN+limit is still a much worse user experience than a password:

- a PIN is hard to memorize, so people are more likely to use personally-relevant or common numbers, whereas a password can be easily be both complex and memorable - it's easy to burn through even 10 login attempts through any combination of temporary/permanent disability, stress, being drunk, damaged device... - a wipe-after-failed-attempts system is trivial to abuse, be it by a prankster or a real adversary - it's much easier to see someone's PIN over their shoulder or film them entering it

Re: Passkeys: A shattered dream

#454
> "If you really want passkeys, put them in a password manager you control. But don't use a platform controlled passkey store"

That is my main reason for avoiding Passkeys;

I will only use Passkeys, when i can export/backup them easily and store an offline backup, without depending on some Big Tech company or whatever. (KeepassXC can export them, but not sure if it's released and fully functional in the stable build yet.)

What also worries me however, is that apparently if i read correctly, each server/service/website can decide/restrict "which password managers/apps" are allowed to be used for the Passkeys they offer...

Re: Passkeys: A shattered dream

#455
post #193

Earlier quoted context omitted.

Apple’s iCloud for Windows includes an iCloud Password app which allows accessing and managing your keychain stored passwords on Windows. They also have a browser extension for Chrome and Edge which does autofilling in those browsers on Windows. I haven’t used them in a long time so I don’t know if they have added passkey support to them yet.

How do you sync to an Android phone?

I don't sync anywhere because I don't use the Apple keychain for my passwords. No idea if there is a solution for Android but the original claim was syncing between your devices was only possible if you stayed strictly with the Apple ecosystem. This is not accurate since you can sync to Windows even if you can't sync to Android.

Re: Passkeys: A shattered dream

#456
post #444

This feels overly cynical to me. The article is a bit rambly so let me try to distill the problems: 1. Most relying parties support resident keys only. This makes a bad user experience because users are surprised when they run out of space, and may have to wipe their device to get more. 2. Most authenticators do not allow you to export your keys. If a relying party only allows a single credential per account, this cr…

If the underlying technology is poorly specified and confusing enough that it doesn’t get implemented well in 95% of cases, then yes, that does indict the technology. See also: PGP and email encryption in general. But even if on balance the tech is worth implementing, it’s clearly not easy and your suggestions to “just” do several things that aren’t happening ring a little hollow.

I only used "just" twice, and they were both justified. Having people remember their email addresses, and explaining something in a couple of sentences, are both pretty easy.

Points #1 and #2 are not entirely trivial, but they're not much more complicated than the alternatives. A relying party has to store the public key counterpart to a user's private passkey no matter what. Is it really that much harder to associate that public key with their user ID? Point #2 is probably the hardest to overcome if you already baked in the assumption of 1 key per user. That's concerning. But that problem can also be mitigated by the authenticator, by supporting export.

I'm not saying the article fails to identify real issues. I'm saying it fails to identify insurmountable issues. The nice thing about software is that a good canonical implementation can be used by everybody for free.

Re: Passkeys: A shattered dream

#457
post #450

Earlier quoted context omitted.

... with some of the functionality of SSH keys removed, like being able to use one key for many accounts, or many keys (on many machines) all for the same account. At least that's how I understand it.

I think you're right about the first part...a passkey being tied to a single account on a single site. But not the second: on Github for example you can have multiple passkeys for the same account.

>But not the second: on Github for example you can have multiple passkeys for the same account.

People mention the "only a single passkey instead of multiple passkeys" issue because they run into some websites such as PayPal that only let you add one passkey. E.g. :

https://old.reddit.com/r/yubikey/comments/14h0d7y/single_key...

https://www.paypal-community.com/t5/Managing-Account-Archive...

Re: Passkeys: A shattered dream

#458

Earlier quoted context omitted.

People keep trying to answer this question, so I'll try, too, but I'm going to do a better job than anyone else. ;-) Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password. By requiring the passkey to be managed by a password manager, you get some anti-phishing protection.…

> Passkeys can make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager. This part right here is what I fear the most about Passkeys. I've read too many horror stories of people getting banned from Google (often for no valid reason) and losing access to all of their data. It is ab…

I have been using passkeys for a while in the form of yubikeys

Best practice is to register two keys to every website. Keep one physically in a safe.

With password managers I would say the same basic practice applies. Make sure you have a working offline backup of whatever secrets you hold dear.

There are some sites that only allow you to register a single passkey for an account (AWS Console last I checked) but these should be getting fixed as it becomes more popular

Re: Passkeys: A shattered dream

#459

I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up. I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not in…

The primary advantages of passkeys are phishing resistance, uniqueness per site, and breach resistance.

Phishing resistance is improved over what a good password manager can provide (unique passwords per site, checking web origin before providing options). Since WebAuthn is a protocol, the origin of the requesting site is stamped into the authentication response; even if the user had the option to override a passkey to be sent to a different malicious domain, it is meant to be rejected if replayed on the legitimate website. WebAuthn really needs an attacker to compromise the legitimate site or to compromise DNS and TLS infrastructure for phishing to be successful.

The uniqueness is really two benefits in one - you don't need to think of multiple unique passwords (if doing manual password management), or suffer with password complexity rules (if doing either manual or automated password management). It is just a public key, usually a P-256 curve point. The security of the user authentication process is abstracted upstream, so it is secured with the local password/biometric or via an activation PIN (same as password managers).

The breach resistance means that if XSS gets onto the page, if a hacker gets read-only access to the password database, it is still infeasible for them to leverage anything they gain to answer future authentication challenges. If your passwords aren't unique, a breach is a big deal and can create a lot of lateral movement. Even if they are unique, attacker visibility of the password means account compromise. The private key in a passkey is separate from the website infrastructure, so that attacker is not going to be able to authenticate from anything they observe.

Re: Passkeys: A shattered dream

#460
post #421

Earlier quoted context omitted.

People keep trying to answer this question, so I'll try, too, but I'm going to do a better job than anyone else. ;-) Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password. By requiring the passkey to be managed by a password manager, you get some anti-phishing protection.…

> By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain. There are so many apps that don't get this right. Make a login on the website, store it in 1password, and then try to login in their mobile app and it doesn't sho…

1password has a URL field. All you have to do it add the extra URLs

Better yet, while on mobile, search for the entry of the desktop site and have it fill. 1password will ask if you want to update the entry for this site

Post reply on HN