> This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.
That only works if the device has working camera and bluetooth. What if I want to log in from my new desktop PC to an account whose Passkey is stored on my old desktop PC?
Probably the whole authentication thing shouldn't be implemented by the website at all. There should be some standardized way to ask for authentication that's implemented by the browser or the operating system.
And now you have to log into your email with a Passkey that probably you lost at the same time you lost your Passkey to the original site (e.g. lost or stolen device).
If you are not using Passkeys for your email (and the site supports that type of account recovery), then you still have only the security of passwords, just with additional steps.
Well, it puts people in a bind. The current status quo of TOTP 2FA with recovery codes is bad, but it's probably the best we have - because applying passkeys to your primary e-mail is beyond stupid at this point, it's putting your digital life in mortal peril.
With a quick calculation 50 ms time offset would mean about 20 meter difference. You can get that accuracy with NTP over residential internet and a better TCXO could hold that for a day. You could sync clocks and download the almanac at each airport. The almanac could be digitally signed and NTP has an option for authentication, too. That's about 10 USD of hardware (plus what you need for image capture and processing).
I'm pretty sure with dedicated hardware and better solutions you could get much better accuracy.
Let's say I have a new account and a single Passkey in the TPM of PC1. I want to log in from PC2, too. How can I do that? (I know there is some trickery with Bluetooth, but I haven't seen anything supporting it, and desktop PCs usually doesn't have Bluetooth connectivity.)
AFAIK some browsers can do some magic to use a Passkey from your smartphone on a PC, but you need to log in to the same browser-sync account from both device (which brings back us to the same issue).
Also the whole thing becomes a mess when you change devices. You need to log into all the services you have ever used to delete the Passkeys from devices you no longer have, and you need to add a new passkey from a new device you bought to all the services you use.
Can these services not use the same fallback mechanism that already exists for non-passkey logins? i.e. an email with a 1-time code or similar. Yes that somewhat defeats the purpose of passkeys but that option is going to exist for a long time regardless of passkey adoption.
If you don't want to downgrade security, how about requiring confirmation from another session that is already logged in using a passkey? e.g. You try to log in on PC2. A prompt appears with something like "confirm this login from [PC1, etc.]". You log in on PC1 using your passkey. The service recognizes that the login id definitely you, or at least someone in possession of your physical device and login method for that device. Therefore, it then allows PC2 to register a new passkey. Kinda similar to how google confirms new logins by sending a notification to your phone.
That could work, but then the service needs to implement complex non standardized authentication mechanism outside of Passkeys. You will have 14 different services with 15 different options. I don't think that's really user-friendly.
Also it could be vulnerable to MFA fatigue attack, if people would constantly get new "confirm this login" popups, they would press anything to make it go away.
So you would need something that is explicitly initialized from a trusted session, then you need something to connect the trusted session to the new login. If you want that to be user friendly you need some short codes and can't rely on QR code / Bluetooth, or two-way interaction. And that brings up the phishing / MitM attacks again.
You generate another passkey is your answer. How do you do that? The exact same way you do today. Why would you need to delete invalid passkeys? You wouldn't.
> How can I do that, if Passkeys are the only option to log in?
It is not feasible to remove password login or some other recovery login method.
> If I can just use a password to log into a website without Passkeys, then Passkey is useless and doesn't add any security benefit.
It isn’t useless, point is you don’t get to type in your password on a device that has passkey generated already, or get phished on a fake web address for example.
> I sell my old (and no longer updated) phone or PC and don't want someone to get access to my account by getting access to the secret keys.
Passkeys are meant to be protected by either PIN or biometrics, however they are also meant to be revocable on the web, at least they are for services i’ve been using with passkeys.
> It is not feasible to remove password login or some other recovery login method.
Then passkeys doesn't provide any real value if you have other less secure recovery option.
Let's say I have a bank account, going to the branch and doing an in person ID check is a valid recovery option, but nobody would want to do that just to log in from a new device.
> It isn’t useless, point is you don’t get to type in your password on a device that has passkey generated already, or get phished on a fake web address for example.
That's solved by letting the browser to remember the passwords.
> Passkeys are meant to be protected by either PIN or biometrics, however they are also meant to be revocable on the web, at least they are for services i’ve been using with passkeys.
PIN and biometrics doesn't have any inherent security. They rely on some hardware (or software separated from main system) feature, and even those can have vulnerabilities.
Using strong password as you suggested is a solved problem for your use case, but that is not universal. Passkeys provide universal security for all.
Also PIN or biometrics verification to access passkey from device bound TPM or security enclave solved the problem you implied might happen, such as losing your device. How do you protect your password manager, if any?
> even those can have vulnerabilities.
We shouldn’t just give up because everything is inherently insecure.
The enforcement of GDPR is more or less nonexistent for big companies. Even if they get fined, that is just cost of business for them.
In the text nothing prevents the manufacturer to stream the vide of your face to their servers all over the world and do the image processing there. It would even comply with GDPR if everybody pinky promised they not using that data for anything else.
How? The websites don't see anything consistent from one session to the next. They can't tell when the credential is renewed, and don't see a credential id.
I suspect the ZKP proof or token is practically unique and related to you, so I could be personal data if you use the definition from GDPR.
With ZKP the entity and the original verifier shouldn't be able to match your identity to the ZKP proof or token, but the app on your phone of course can do that.
The app probably will be made some government contractor and there is no technical measure that would prevent them to just share all that data with whoever they want.
The app can be open-source and verified to not be sharing extra info, though. Of course if no-one bothers to use the verifiable version of it, then it's all pointless, but this is true regardless (they could also just not use ZKPs).
That only works if the device has working camera and bluetooth. What if I want to log in from my new desktop PC to an account whose Passkey is stored on my old desktop PC?
reply