Live data from Hacker News

Passkeys: A shattered dream

fy.blackhats.net.au

221–230 of 789 posts

Re: Passkeys: A shattered dream

#221

I've never tried to use passkeys, but determined a while ago my hard, non-negotiable, a priori requirements which would have to be met for me to be willing to use them: 1. I can, if I choose, have a passkey in software (no hardware enclave, no captive key, no TPM) even if the security of that sucks: => Implication: I can backup and copy a passkey without restriction, e.g. putting the key material in an airgapped pass…

1Password includes Passkeys in archive/exports of the 1Password database. Safari developers have stated that it is a planned feature to support Passkey exporting (but not currently supported) including between apps.

I'm not aware of any restrictions at this time on your second point. I also haven't seen any examples of attestation and Passkeys being used in practice.

Re: Passkeys: A shattered dream

#222

The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials bu…

KeepassXC says that it is adding (has added) passkey support. I haven't tested this yet, but if it works, that would avoid platform lock-in. Assuming, of course, that the platforms don't somehow intercept the passkey requests and refuse to allow KeepassXC to do its job. The big tech companies (Google, Apple, MS) have all become evil.

> Assuming, of course, that the platforms don't somehow intercept the passkey requests and refuse to allow KeepassXC to do its job.

My understanding is the ability to do that is built directly into the spec with the attestation feature. The only thing that might slow it down is Apple choosing to not implement it and zero out their device string. Others can piggy back on that to protect themselves behind Apple's skirt, at least until Apple changes their stance anyway.

Platforms of course could just not allow Apple passkeys and only allow Apple users to use other 2FA options as well. Rest assured that small players like KeepassXC will be the first ones to have their passkeys blocked or not supported.

The whole thing is a trap IMO.

Re: Passkeys: A shattered dream

#223
post #206
post #75

Passkeys can't actually replace passwords, right? I will always need a username and password with a website, then can generate a passkey as a separate auth mechanism, which if I lose, I will recover by setting up again using my username and password? I don't get how we can get to a place where passkeys are all, how do you get a passkey on a new device when you only have passkey auth on some other device enabled?

They can, and hopefully will. To get a new passkey on another device, the provider needs to allow you to prove you have possession of your other device first. They can do that by sending you a one-time code, for example, when you authenticate using your existing device, which you can then type in the new device, and that lets you associate your new device-generated key with your existing account. With iCloud, you don…

Long recovery code is definitely a password lol. Needs to just have email recovery and call it a day.

Re: Passkeys: A shattered dream

#224
post #195

Earlier quoted context omitted.

The mental model is very simple. If you use things like Yubikey, it is exactly like a key you use to start your car. A single password protected key maybe. In essence, it is your password manager but something that everyone can use. And something that doesn't need to be on the cloud.

Well that doesn't help understand: How passkeys can be backed up? Where/how they are stored? What if I loose my phone, computer? How can I login to some app using pc/mobile? I haven't been into passkeys as you see, but some easy login like that leaves me with a lot of questions.

The TL;DR version in my opinion is that passkeys are quite similar to a SSH key pair, like one you'd use on GitHub. Basically you generate a key pair, the server stores the public key, and the client stores the private key. When you want to authenticate, the server sends a challenge, you sign it with your private key, and send it back. The main debate is over how to manage those keys after generation.

- Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.

- Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up. So the passkeys are stored encrypted on disk, and the decryption key is stored in the keychain/keystore. Other options include passkeys actually stored in hardware (eg. Yubikeys, but then you can't back them up) or 3rd party password managers.

- Login: It's pretty seamless, just click "login with passkey". The browser handles finding the right passkey, and part of the signed challenge includes the domain the passkey is for, preventing MITM-style attacks. There's also a whole separate thing for authenticating a session on a different device via scanning a QR code or Bluetooth.

Here's a good fairly high-level breakdown of how it all works, if you want some additional detail: https://webauthn.wtf/how-it-works/authentication

Re: Passkeys: A shattered dream

#225

My biggest issue with passkey is not passkey itself, which, when it works, is great, but more the implementation of it done on most websites. Use a passkey on https://www.passkeys.io and it works great! On google too. But use it on PayPal, it does not anymore. Who’s to blame?

I've added a few passkeys to 1Password. It works pretty well on github.com, and sometimes on google.com. But apparently, passkeys.io bypasses 1Password and asks the OS for passkeys? So passkeys.io doesn't actually work for me, unless I want to store the passkey in the OS keychain. Which I don't, because I don't want to be locked into that. How can it be that the website decides which password manager I should use to…

Interesting. What OS/browser do you use?

Re: Passkeys: A shattered dream

#226
post #46

Earlier quoted context omitted.

Password managers can store the passkeys just like they store passwords. 1Password has had strong support for them for quite a while now

Yeah probably can. But why do I need Passkeys?

1: Phishing protection

2: Protection against data breaches since Passkeys are not reused

3: Ability to login to devices you don't own without entering a password (QR code scanning)

Re: Passkeys: A shattered dream

#227

Earlier quoted context omitted.

That's not the idea, no. The idea is that - instead of a password - you have a cryptographic key. Like an SSH key. This key is managed for you, so you never have to see it or type it. You ought to be able to either have just a few keys, or else a different key for every service you use. Unfortunately, the big players are trying to force this (really excellent!) idea into platform dependency. They want to store the ke…

Wouldn't transferring the keys around just massively increase the attack surface? There's a security reason why we want them stored on-device and never moved, right?

The KeepassXC file is encrypted (granted, only with a password). Sure, that file is now on multiple devices, so somewhat more vulnerable.

The problem with storing on-device comes when you use multiple devices. I have three devices (PC, laptop and phone) that I use regularly and interchangeably. What am I supposed to do, if the keys are tied to a single device? Worse, what do I do if that device dies, or is stolen?

Re: Passkeys: A shattered dream

#228
post #152

Yeah, unfortunately passkeys are confusing and the UX is generally fucking awful. I hesitate to just blame the tech companies for being greedy, as a result of my experience with passkeys I'm starting to wonder if maybe they've legitimately just lost the skills and knowledge necessary to actually make usable software. What's most disappointing is, password managers have already solved the problem of syncing credential…

FWIW: MacOS and iOS allow third party password managers to ingrate directly into AuthenticationServices and list passkeys in the native passkey UI through a "Credential Provider" extension. And it's documented how: https://developer.apple.com/documentation/authenticationserv... This is the same Credential Provider API they already have to integrate with to show the password autofill in iOS so there is already _some_…

> 1Password _could_ just integrate with the native UI. But they chose not to. This however means shipping a native app which is a lot more heavy-weight than shipping a web extension.

I mean, I kind of understand this; they're going to have to do the WebExtension either way, since there's no standard API across platforms.

Re: Passkeys: A shattered dream

#229
This was so obvious from the start. Whenever big tech creates "standards" now you already know it's going to be total horse shit. Look back at the old threads when passkeys launched. HN was full of fanboys thinking it's the best since sliced bread and passwords are so yesterday. Managing your passwords takes a bit of effort like everything in life where you don't want do give away control completeley to some corporate aholes. Whenever you let someone else manage your stuff you set yourself up to getting ducked.

Re: Passkeys: A shattered dream

#230

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 mental model is very simple. If you use things like Yubikey, it is exactly like a key you use to start your car. A single password protected key maybe. In essence, it is your password manager but something that everyone can use. And something that doesn't need to be on the cloud.

It is like a key to start your car, except you can register it with multiple cars. And it has 25 or so "slots" for car registrations. If you lose the key, you cannot order a copy from the car manufacturer. You also cannot make a copy yourself. But you can (usually) register multiple keys with the same car. You do this by plugging two keys into the same car, and the car learns both keys belong to the same owner. You just have to be careful and keep track of which car is registered with which key, and vice-versa. Sometimes the key will not work with a particular car. Also, after you plug in the key, the car will not start right away. It will first ask you to select which key to use. If you use Bitwarden, it may hijack the key insertion interaction and will offer to use its soft-key instead. So, some small differences ;-)
Post reply on HN