| ▲ | jesseendahl 2 days 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. |
|
| ▲ | benlivengood 2 days ago | parent | next [-] |
| > 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 2 days ago | parent [-] | | I 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. |
|
|
| ▲ | phs318u 2 days ago | parent | prev [-] |
| > 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 2 days ago | parent | next [-] | | "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 2 days ago | parent | next [-] | | So just a password manager? | | |
| ▲ | jesseendahl 2 days ago | parent [-] | | Passwords are still significantly less secure than passkeys even when using a password manager. | | |
| ▲ | inigyou 2 days ago | parent [-] | | Why? | | |
| ▲ | coffe2mug a day ago | parent | next [-] | | Passkeys 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. | | |
| ▲ | someguydave 10 hours ago | parent | next [-] | | Hiding the underlying exchange of data from the user does not mean the data is unstealable | | |
| ▲ | coffe2mug 10 hours ago | parent [-] | | With your logic nothing is unstealable. Go and watch film inception. The main point is the average Joe it works seamless. And average Joe won't have to remember things. Yes, it does. Not everyone wants to maintain password database. |
| |
| ▲ | inigyou a day ago | parent | prev [-] | | how do I back it up and transfer it to a new device? This is relevant because an attacker can also do that. | | |
| ▲ | coffe2mug a day ago | parent [-] | | Buy 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. | | |
|
| |
| ▲ | Ajedi32 a day ago | parent | prev [-] | | Because as I just outlined, passwords, even when stored in a password manager, can be misused. (Phished, set to something weak/guessable, reused on multiple sites, leaked in a database breach, etc.) Password managers make it easier to avoid those pitfalls, but passkeys make it nearly impossible to fall into them. |
|
|
| |
| ▲ | 2 days ago | parent | prev [-] | | [deleted] |
| |
| ▲ | TeMPOraL a day ago | parent | prev | next [-] | | It'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 a day ago | parent [-] | | Not only that, they don’t need to worry if they lose their phone they’re locked out of their accounts too! |
| |
| ▲ | crote 2 days ago | parent | prev [-] | | > at which point it’s no different to password syncing You still get the phishing resistance, though! | | |
| ▲ | TeMPOraL a day ago | parent | next [-] | | Is the "phishing resistance" just inability to view and manage your own data? That's a bug, not a feature then. | | | |
| ▲ | choo-t 2 days ago | parent | prev [-] | | Password managers prevent phishing as they check for the domain name before inputing the password. | | |
| ▲ | jesseendahl 2 days ago | parent [-] | | Password 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. |
|
|
|
