raron

How do you exactly define "no rolling/twisting of the cable"?

For a quick test I projected a flat QR code onto the surface of a cylinder, printed the distorted image on a household printer, wrapped the paper around a 3 mm diameter wire. The result is readable from a still image made by a smartphone.

It haven't worked with 2 mm image / cable, but I'm pretty sure that's just limit of my printer's resolution. With 600 DPI there is only 2-3 dots per QR code pixel.

You could repeat that pattern with few degrees of rotation so one will always be in the right enough orientation to decode.

> 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.

Commercial screens are full of the same connectivity and anti-features that nobody (well maybe except if you are a hotel or similar) wants.

Computer monitors doesn't exists about something like 32".

Is that really that impractical?

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.

> We shouldn’t just give up because everything is inherently insecure.

True, but no sane way to mass revoke Passkeys from stolen / lost device is just bad design.

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.

> 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.

> You generate another passkey is your answer. How do you do that? The exact same way you do today.

How can I do that, if Passkeys are the only option to log in?

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.

> Why would you need to delete invalid passkeys? You wouldn't.

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.

An non-revocable authentication mechanism is just stupid.

I don't think that would work either.

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.

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.

> Use short expirations

And now you can use time correlation attack to unmask people.

I think that depends on how do you define PII.

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.