good article and another reason why ppl really need to stop using chrome
Passkeys: A shattered dream
631–640 of 789 posts
Re: Passkeys: A shattered dream
#632Earlier quoted context omitted.
I have 400 accounts in my password manager. There’s no way I’m doing that for each of them (or figuring out which ones support passkeys).
Then don’t change phone OS, or put your passkeys in a third party password manager.
Or... use passwords and 2FA which we have been using forever and for years respectively.
Re: Passkeys: A shattered dream
#633Earlier quoted context omitted.
You are able to share an Apple passkey to any nearby Apple device at any time using AirDrop. Passkeys can also be used cross-platform during sign in via an NFC/Bluetooth handshake initiated by QR code. Additionally, passkeys are just a synced-via-cloud implementation of FIDO2, an open standard that has other implementations you may feel more comfortable using. For someone who requires being able to sign in to, say, G…
This all sounds like "it's technically possible, but it's a huge huge hassle and sticking with passwords is significantly easier".
Seems like it. And the primary reason I haven't switched. Seems like a huge hassle and offers no advantages to me.
Re: Passkeys: A shattered dream
#634Earlier quoted context omitted.
You get a link (or more commonly a QR code) that you open from the device on which you already have the passkey to grant access to the new device. Then you add the passkey for the new device. FWIW I don't think that this makes passwords redundant in general, but with passkeys, password becomes a last-ditch safety valve to regain access to the account. Meaning that it can be generated, very long, and stored in a way t…
One big issue with this QR thing is that phone will need to talk via bluetooth to the PC. Like every PC comes equipped with bluetooth chip. Should be some kind of pin code instead.
No, it doesn't. There only communication is happening through the site. The site issues a challenge to the PC, the previously registered phone confirms to the site that the challenge is met, and from now on the site trusts the PC. The PC and the phone can be on different continents.
The problem though is that you have to do this for every single site you access. So if you have 100 log ins and are switching PC or phone, you'll have to do this same dance 100 times in the next period. And of course, if you're switching because you lost your one device that was registered this way...
Re: Passkeys: A shattered dream
#635Earlier quoted context omitted.
You are able to share an Apple passkey to any nearby Apple device at any time using AirDrop. Passkeys can also be used cross-platform during sign in via an NFC/Bluetooth handshake initiated by QR code. Additionally, passkeys are just a synced-via-cloud implementation of FIDO2, an open standard that has other implementations you may feel more comfortable using. For someone who requires being able to sign in to, say, G…
Number 2 is not true. I have a Yubikey and it can't be used on Android without a Google made app or account. It's always the same story, give a plausible option to seem open or neutral, but make sure there are "details" that establishes chain of consequences preventing it that is weird enough to allow denying intention. Even though I'm not that young I thought I just need to wait for Firefox to implement it, but as t…
Wow. I just bought a couple of new YubiKeys for the OpenPGP Curve25519 support. I was looking forward to using the NFC feature with my Android phone. Is it just a Chrome problem? I downloaded some OpenPGP app from fdroid and it says it supports NFC keys.
Re: Passkeys: A shattered dream
#636Earlier quoted context omitted.
I'm assuming tech people would also like to know that a passkey is not just "a really long password" but also one that's never sent to the server directly - instead it's used in a challenge/response protocol (like SSH keys). Which requires software, either the browser or an external password manager, to run. I think that's what you're getting at in paragraph 3? There's no reason you couldn't have an open source passk…
It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves. The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was creat…
> The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
That's simply false, and there are passkey managers that allow this - KeePassXC for example.
Re: Passkeys: A shattered dream
#637Earlier 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.…
You can have multiple passkeys per username. This is a huge difference from regular passwords, and the source of a lot of confusion about lock-in. You can’t easily move a passkey out of the service managing it—true. But you should be able to easily add another passkey from another service. Then you deactivate the first passkey. It’s a different mental model and the key is in the name. Passkeys are like keys. You can…
It's not a problem of mental model, it's a problem of scale. If I'm switching phone, the last thing I want to do is to go to every website I have an account on and essentially do a second sign up. This is simply a non-starter, and is a big part of why companies like Apple and Google are pushing for this spec: it nicely ties you in to their ecosystem and gives you a huge reason not to move to a different ecosystem.
Re: Passkeys: A shattered dream
#638Earlier quoted context omitted.
One big issue with this QR thing is that phone will need to talk via bluetooth to the PC. Like every PC comes equipped with bluetooth chip. Should be some kind of pin code instead.
No, it doesn't. There only communication is happening through the site. The site issues a challenge to the PC, the previously registered phone confirms to the site that the challenge is met, and from now on the site trusts the PC. The PC and the phone can be on different continents. The problem though is that you have to do this for every single site you access. So if you have 100 log ins and are switching PC or phon…
That's not true. Phone and PC have to communicate via bluetooth.
Re: Passkeys: A shattered dream
#639Earlier quoted context omitted.
No, it doesn't. There only communication is happening through the site. The site issues a challenge to the PC, the previously registered phone confirms to the site that the challenge is met, and from now on the site trusts the PC. The PC and the phone can be on different continents. The problem though is that you have to do this for every single site you access. So if you have 100 log ins and are switching PC or phon…
That's not true. Phone and PC have to communicate via bluetooth.
Edit: everything I say below is not just wrong, but confidently wrong...
"Communicate over bluetooth" doesn't mean anything. What app or BT device would they be using? How would a PC communicate with a YubiKey over bluetooth?
I have no idea where you got this strange concept from, but registering multiple passkeys from multiple devices on the same account on a site requires no communication between the devices - it only requires a trusted device to approve the request.
Re: Passkeys: A shattered dream
#640I’m surprised no one has written a tool (probably would involve disabling SIP) to import/export passkeys on macOS. They’re in memory, right?