Live data from Hacker News

Passkeys: A shattered dream

fy.blackhats.net.au

291–300 of 789 posts

Re: Passkeys: A shattered dream

#291
post #219

Earlier quoted context omitted.

Yes but what I'm still confused about is that: 1) Is one/some of your public key reused on different services 2) Or is there a different public key for each service 1) In the first case what will prevent different services to track users by comparing public key... and if so I would be more at ease with a site specific randomly generated password 2) In the second case when one service is breached you'd still have to m…

>2) In the second case when one service is breached you'd still have to manage rotation of public key somehow Why would you need to rotate your keys? If they're storing passwords/hashes it makes sense to rotate because they might be able to brute force the hashes on a GPU cluster, but you're not going to be able to brute force a randomly generated public key.

If I have any fear that the associated private key have leaked. For instance if my off-site encrypted backup is stolen. I sure would want to rotate my private key because my secret would be only as safe as the encryption method at the time the backup was stolen. I'm still not entirely sold on the "quantum will break any current crypto" but better safe than sorry.

Re: Passkeys: A shattered dream

#292
post #3

Oof, the Passkeys ecosystem is incredibly complex. Even as someone that deals with it day in and day out at $CURRENT_CO, it can be a headache. As an exercise from a developer's perspective, try creating a chart of every device type (mobile, desktop etc), browser, and Passkeys platform provider (Apple, Microsoft etc). Then fill out how each behaves across each combination, it is a nightmare! I'm hopeful that we'll see…

I am exploring this now, actually got 2 students doing their thesis on this. It's very complicated and unnecessarily so. My conclusion so far is that it's a promising technology, but no way as mature as I'd like it to be. Unfortunately we are stuck with emails and passwords for the foreseeable future, at least as a back-up mechanism for credentials recovery, which, funnily, makes the whole thing pretty much pointless…

Noone put any thought into the goals of passkeys and it shows.

You have to beat email/password with optional password manager (syncing, remembering , autofilling) and optional MFA (physical proof)

passkeys cant beat that in any area because they have no goals

Re: Passkeys: A shattered dream

#293
post #272
post #186

Earlier quoted context omitted.

You're wrong, with password managers you can definitely be phished. Unless it's literally impossible to extract the password to enter it manually, but I don't think password managers make that impossible (and if it's possible, users will do it). With passkeys it's literally impossible.

> With passkeys it's literally impossible. I dunno about you. But I like being able to get my passwords out of the password manager. How is not being able to do so a feature?

Because that opens you up for being phished.

Re: Passkeys: A shattered dream

#294

Earlier quoted context omitted.

> I’ve avoided passkeys so far because I just don’t have a good mental model of them. OK, so the simplest way to understand is to first know about the previous generation. U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes. In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compr…

> "and use fingerprint/faceid instead of a password" This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.

The unstated value of a USB key is the functional similarity to metal keys for ordinary people.

Re: Passkeys: A shattered dream

#295

Earlier quoted context omitted.

Store your passkeys in BitWarden.

I love Bitwarden but they still don’t support that on mobile phones.

I think it's very close to landing into the release version. I've seen people discuss it working in the testflight/beta release on iOS

Re: Passkeys: A shattered dream

#296

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…

You can store passkeys in a password manager as well: https://1password.com/product/passkeys The super simple explanation is: SSH keys for websites. You have a unique private key for each website account stored on your device, in a local password manager, or in a cloud synced password manager (iCloud account, Google account, 1Password, etc). The website only gets the public key, so unlike password auth your secret is…

I currently use the 1Password passkeys, and when they work, it's pretty good. I get all the fun of showing up on a website, and with three clicks, I'm in. But I've used them on just a few websites (email and GitHub), and they work correctly maybe 10% of the time.

First, I had to figure out how to get the website to request the passkey. Then I had to figure out that I didn't want to use the browser's passkey but 1Password's, which is different on different browsers and platforms. And good luck if I'm on mobile, I don't think it's ever worked.

At this point I'm taking a break from signing up new passkeys. I'll stick to UN+PW+(TOTP|Yubikeys).

PS: Why is it that no financial institution lets you use anything more than a SMS U2F?

Re: Passkeys: A shattered dream

#297

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…

You can store passkeys in a password manager as well: https://1password.com/product/passkeys The super simple explanation is: SSH keys for websites. You have a unique private key for each website account stored on your device, in a local password manager, or in a cloud synced password manager (iCloud account, Google account, 1Password, etc). The website only gets the public key, so unlike password auth your secret is…

It's still not a great multi-platform/multi-device story. I use multiple machines regularly (and I've migrated away from 1Password to the KeePass ecosystem, by the way) so syncing passkeys from my Mac(s) to my iPad, to my Fedora machines and my Windows working environment is simply not happening any way I look at it.

Passkeys are great for consumers who use one or two devices (or browsers - I also switch browsers frequently). For anyone with more than one platform or one device in their lives they suddenly become added complexity, because even though you _can_ have more than one passkey per account per service, in practice there are all sorts of weird edge cases.

They're just not mature yet, period.

Re: Passkeys: A shattered dream

#298

Earlier quoted context omitted.

> "and use fingerprint/faceid instead of a password" This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.

The unstated value of a USB key is the functional similarity to metal keys for ordinary people.

This is exactly how I describe them to many as well. I just wish there was a USB key with the durability of a metal key.

Re: Passkeys: A shattered dream

#299

Earlier quoted context omitted.

> I’ve avoided passkeys so far because I just don’t have a good mental model of them. OK, so the simplest way to understand is to first know about the previous generation. U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes. In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compr…

> "and use fingerprint/faceid instead of a password" This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.

The fingerprint/faceid is just a local proof to unlock the actual asymmetric encryption key. It is not your actual identifier to the remote server. So if you need to redo your auth, you just rekey and stash the new key in your authenticator (or have your authenticator originate the key material and never expose it to main memory at all).

Think an SSH key protected by a passphrase. Your passphrase isn't the thing that actually logs you into the server, its just what you use to unlock your actual key material you use in your SSH handshake. Your fingerprint/face identity is just your local unlock of the actual key material stored in some other secure enclave.

Re: Passkeys: A shattered dream

#300

Earlier quoted context omitted.

The risk of your password getting stolen in between your browser and whatever hash algorithm the service you're authenticating with puts your password through before storing/verifying it. That's the benefit you get from passkeys that no password manager will otherwise be able to give you.

If they control the information flow can't they simply steal the passkey too?

Nope.

Passkeys use public-key authentication wherein the server only stores the public half of a keypair and the client authenticates by correctly signing a challenge sent by the server, which the server then verifies using the public key.

At no point is the private key ever sent over the network or otherwise exposed to any infrastructure or code controlled by the server.

Post reply on HN