4 ms·
> Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound If you watch the original Apple WWDC talk present
by jesseendahl 3mo ago
> Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound
If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case.
What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple.
The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.
- phs318u 3mo ago> the only possible way to compete with that UX is to sync the private key across the user’s devices This is my issue with passkeys. Either we lessen security to improve UX (syncing across devices implies extracting private keys from secure enclaves, at which point it’s no different to password syncing), or we have a proliferation of different keys per website across devices (assuming the website supports multiple passkeys). Perhaps this trade off is not resolvable in a way that happily satisfies both the security constraint and the UX requirement.
- Ajedi32 3mo ago"A better version of password syncing" is exactly what Passkeys are and ought to be. Just like passwords, but unphishable, unguessable, not reusable across sites, not vulnerable to data breaches, and with better UX. Stranding private keys in clone resistant secure enclaves has unacceptably bad UX for the average user, which is why very few implementations try to do that.
- inigyou 3mo agoSo just a password manager?
- jesseendahl 2mo agoPasswords are still significantly less secure than passkeys even when using a password manager.
- inigyou 2mo agoWhy?
- coffe2mug 2mo agoPasskeys cannot be stolen. Yes, don't say that what if someone steals my iPhone, PIN, and adds their fingerprint. Let's say eBay asks user to login. With passkey. Press and hold fingerprint etc. login done. Even with laptop. And average Joe doesn't want to maintain a keepassdatabse sync it. Yes, you can always use your own server etc but others have life.
- inigyou 2mo agohow do I back it up and transfer it to a new device? This is relevant because an attacker can also do that.
- coffe2mug 2mo agoBuy a new iPhone. Sign into it. Everything is now available. That is the reason: for the average Joe not having exportable passkeys is good. Average Joe doesn't have to do backup. It is all automatic.
- deleted 2mo ago[deleted]
- crote 3mo ago> at which point it’s no different to password syncing You still get the phishing resistance, though!
- choo-t 2mo agoPassword managers prevent phishing as they check for the domain name before inputing the password.
- jesseendahl 2mo agoPassword managers do not architecturally, cryptographically make phishing impossible. Ultimately a user can still be tricked to copy/paste their passwords into fake websites, even when using a password manager. You could blame end-users for this behavior, but attackers don't care about blame. Ultimately, it doesn't matter who's at fault when there are massive phishing attacks happening at scale every single hour of every day. The only real solution to solve this problem for the entire internet is to make credentials architecturally, cryptographically unphishable by design. That's what passkeys give you.
- TeMPOraL 2mo agoIs the "phishing resistance" just inability to view and manage your own data? That's a bug, not a feature then.
- coffe2mug 2mo agoDownloading and keeping safe local data is a bug for others
- TeMPOraL 2mo agoIt's still ignoring one of the main features of passwords for regular people, which is authority delegation via password sharing, aka. "could you please log in to my ${service} and do ${something}, my password is ${password}...". Yes, that is a feature and a normal use case that has equivalents in meat space, that security aficionados refuse to recognize even exists, much less support.
- lazide 2mo agoNot only that, they don’t need to worry if they lose their phone they’re locked out of their accounts too!
- benlivengood 3mo ago> The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices. Another way would be auto-enrolling passkeys from other devices you own through a standard API. Enroll your trusted Apple device in your Google Account's settings, or your Bitwarden/KeePass, and vice-versa. When your iPhone creates a passkey at a site, iCloud notifies Google, which issues a new passkey and sends the public key to iCloud, which auto-enrolls it at the site alongside the iCloud passkey. BitWarden gets the same treatment. When you open your KeePass vault it checks Google and iCloud and picks up any pending offers for passkey enrollment and completes them. Simple, secure, opt-in, and users control their devices and passkey vaults with minimal hassle. If a device is lost, the other services can help you automatically delete the compromised passkeys and set up your new replacement device. Matter does something very similar with cross-compatibility between Apple and Google (and the rest of the ecosystem) when new devices get enrolled with the user's choice of PAA; the only thing missing is roughly cross-PAA enrollment but that would be just one additional trivial trust relationship in both ecosystems.
- jesseendahl 2mo agoI like it. The high level UX of this idea feels very compelling to me as a "yes and" -- aka a world where vendors continue to offer end-to-end encrypted syncing within an ecosystem, but then this idea gets layered on to solve the cross-ecosystem problem. I think the trickiest part would be how to do it in a privacy-preserving way, but that's solvable.