3 ms·

How is it higher entropy? What's stopping a password from having 128 or 256 bits of entropy in it? If the website is compromised it doesn't matter either way s

How is it higher entropy? What's stopping a password from having 128 or 256 bits of entropy in it? If the website is compromised it doesn't matter either way since that password is not shared with any other site. And the UX doesn't seem to be the same at all. For one, according to comments in this very thread, Google and Apple aren't making these portable or user-backupable. On top of that, to log in from a new device, with a password I just need to get it from the password manager and enter i t on the new device. I can copy the entire password store to the new device, and immediately be sure that I can access any and all accounts. Unless I'm grossly misunderstanding, that's not possible with passkeys, or at least not in the Google and Apple implementations? I would have to generate a new passkey on the new device, then enroll it with the website, and I would have to do that separately for each individual website/account? Not to mention, both devices have to be online at the same time? That's completely unworkable.

WorldMaker 3y ago
> How is it higher entropy? What's stopping a password from having 128 or 256 bits of entropy in it? Admittedly, using "entropy" as the word here is bordering on an analogy break. "A picture is worth a thousand words": "a private key is worth a thousand characters of a password". It greatly increases the information complexity needed to just "brute force guess", as a rough off hand we call that "entropy" but what a Password Manager shows for estimated "password entropy" isn't a directly comparable "metric" to private key entropy (other than assuming that a private key is an order of magnitude "jump"). > If the website is compromised it doesn't matter either way since that password is not shared with any other site. It still matters to using that specific site. If a website is breached and they get your password to that site, they can immediately use your password on that site. The potential damage is limited in theory to just the one site (and only limited in theory, not in practice, because in practice many social engineering attacks start with just a single site breach and spread), but the potential damage is still real. Whereas if they get a public key a website is using for authentication they might be able to encrypt some nastygrams that only your private key can read, but they can't actually authenticate anywhere with just a public key, not even the site they stole the public key from. > And the UX doesn't seem to be the same at all. For one, according to comments in this very thread, Google and Apple aren't making these portable or user-backupable. There's a lot of different definitions flying around for what constitutes "portable" and "user-backupable". There's also a lot of promised interoperability tools that haven't yet materialized and will answer some of these questions. In terms of "average user UX" though, it is very comparable: on Apple devices if you use iCloud Keychain as your password manager, Apple's passkey implementation syncs the exact same (E2E) way and is not much different from "browser generated" passwords in Safari today. (Google's is similar but swap Apple names for things and E2E is "optional" for some dumb reason. Microsoft's is similar but swap OneDrive for iCloud and use more interop with iOS and Android phones.) > Unless I'm grossly misunderstanding, that's not possible with passkeys, or at least not in the Google and Apple implementations? I would have to generate a new passkey on the new device, then enroll it with the website, and I would have to do that separately for each individual website/account? Not to mention, both devices have to be online at the same time? That's completely unworkable. It sounds like you misunderstand how passkeys work. In general in the Apple implementation (which I have slightly more direct experience with) passkeys are built and stored like passwords in the iCloud Keychain. They sync with E2E-encrypted keys that are device-specific, but you enroll an Apple device once while two devices are online together (unless you have a much more desperate and harder recovery scenario) and once enrolled both devices have full offline access to all synchronized passkeys in exactly the same way they have access to all synchronized passwords in the same "Password Manager". (Think of it as a hierarchy with a few device-specific keys as the foundation being used to transfer lots more non-device-specific, but less powerful and website-specific keys to be used as passkeys.) There are small exceptions that do make this easy to misunderstand/confuse: if a website "needs" an attestation similar to previous 2FA it may need something signed by a device-specific key in some situations. That should be much more rare in practice than the more password-like sort of passkey. That's also where more of the key operations want both devices online and talking via Bluetooth LTE personal area network. It's a 2FA operation trying to test that you have current access to a specific device. It shouldn't be something used for 95% of logins in the future once Passkeys are more stable. (It is used a bunch right now for bootstrapping synchronization tools and cross-platform needs. Using iOS keys on Windows, for instance. Some of that is just waiting on some of the cross-provider interop features planned but not yet ready. Microsoft's efforts which are still somewhat behind Apple and Google are expected to be very much the "glue provider" as they will absolutely need to support both Apple and Google interop in Windows.)
- boring_twenties 3y ago
  > they can't actually authenticate anywhere with just a public key Duh, obviously. Sorry about that stupid statement. Yes, public keys are more secure. However, that doesn't matter, because: > use iCloud Keychain as your password manager This is exactly the thing that is a total non-starter. A proprietary, closed-source third-party service that can go offline at any time? I would maybe trust that with my hackernews login and that's about it. Not even reddit. > once while two devices are online together This is also still a non-starter. What happens when you are traveling with only one device, and lose or break it? I simply buy a new phone, go get the USB drive with all my passwords on it from the hotel safe, connect it to the phone, and I'm back in business. What do you do with passkeys?
  - WorldMaker 3y ago
    > This is exactly the thing that is a total non-starter. A proprietary, closed-source third-party service that can go offline at any time? There will be open-source options eventually. Certainly, the wheels are spinning among some of the HN sorts that think about such things. Apple and Google (and Microsoft) have a head start because they have to coalition build on these standards to make them work, but it is all still based on standards (all of FIDO2, WebAuthn). But in the context of "just save the randomly generated password in your browser's password manager", the big 3 cover the majority of average users' browsers, so the UX should in theory be simple for the average user, not just the technically proficient user (nor the "I only trust open source" user). Firefox is, of course, working on their passkey tools as well. > What happens when you are traveling with only one device, and lose or break it? The same recovery process that happens for your primary account on the device, your Apple iCloud account or Google Account. That part isn't changing in all of this. Those are closed source so whatever details for how they already today escrow recovery keys for scenarios like that where no other device is available to bootstrap recovery from. Though once bootstrapped from a recovery state, all the passkeys should flow to the new device just as all the passwords in the password manager and you are back in business. Recommending owning at least two Apple devices connected to your account is already common security recommendation going back several years now because of Apple's E2E guarantees when you do so. That's not new guidance unique to their passkeys implementation, but also a cornerstone of existing Apple ecosystem security.

WorldMaker 3y ago

> How is it higher entropy? What's stopping a password from having 128 or 256 bits of entropy in it? Admittedly, using "entropy" as the word here is bordering on an analogy break. "A picture is worth a thousand words": "a private key is worth a thousand characters of a password". It greatly increases the information complexity needed to just "brute force guess", as a rough off hand we call that "entropy" but what a Password Manager shows for estimated "password entropy" isn't a directly comparable "metric" to private key entropy (other than assuming that a private key is an order of magnitude "jump"). > If the website is compromised it doesn't matter either way since that password is not shared with any other site. It still matters to using that specific site. If a website is breached and they get your password to that site, they can immediately use your password on that site. The potential damage is limited in theory to just the one site (and only limited in theory, not in practice, because in practice many social engineering attacks start with just a single site breach and spread), but the potential damage is still real. Whereas if they get a public key a website is using for authentication they might be able to encrypt some nastygrams that only your private key can read, but they can't actually authenticate anywhere with just a public key, not even the site they stole the public key from. > And the UX doesn't seem to be the same at all. For one, according to comments in this very thread, Google and Apple aren't making these portable or user-backupable. There's a lot of different definitions flying around for what constitutes "portable" and "user-backupable". There's also a lot of promised interoperability tools that haven't yet materialized and will answer some of these questions. In terms of "average user UX" though, it is very comparable: on Apple devices if you use iCloud Keychain as your password manager, Apple's passkey implementation syncs the exact same (E2E) way and is not much different from "browser generated" passwords in Safari today. (Google's is similar but swap Apple names for things and E2E is "optional" for some dumb reason. Microsoft's is similar but swap OneDrive for iCloud and use more interop with iOS and Android phones.) > Unless I'm grossly misunderstanding, that's not possible with passkeys, or at least not in the Google and Apple implementations? I would have to generate a new passkey on the new device, then enroll it with the website, and I would have to do that separately for each individual website/account? Not to mention, both devices have to be online at the same time? That's completely unworkable. It sounds like you misunderstand how passkeys work. In general in the Apple implementation (which I have slightly more direct experience with) passkeys are built and stored like passwords in the iCloud Keychain. They sync with E2E-encrypted keys that are device-specific, but you enroll an Apple device once while two devices are online together (unless you have a much more desperate and harder recovery scenario) and once enrolled both devices have full offline access to all synchronized passkeys in exactly the same way they have access to all synchronized passwords in the same "Password Manager". (Think of it as a hierarchy with a few device-specific keys as the foundation being used to transfer lots more non-device-specific, but less powerful and website-specific keys to be used as passkeys.) There are small exceptions that do make this easy to misunderstand/confuse: if a website "needs" an attestation similar to previous 2FA it may need something signed by a device-specific key in some situations. That should be much more rare in practice than the more password-like sort of passkey. That's also where more of the key operations want both devices online and talking via Bluetooth LTE personal area network. It's a 2FA operation trying to test that you have current access to a specific device. It shouldn't be something used for 95% of logins in the future once Passkeys are more stable. (It is used a bunch right now for bootstrapping synchronization tools and cross-platform needs. Using iOS keys on Windows, for instance. Some of that is just waiting on some of the cross-provider interop features planned but not yet ready. Microsoft's efforts which are still somewhat behind Apple and Google are expected to be very much the "glue provider" as they will absolutely need to support both Apple and Google interop in Windows.)

boring_twenties 3y ago
> they can't actually authenticate anywhere with just a public key Duh, obviously. Sorry about that stupid statement. Yes, public keys are more secure. However, that doesn't matter, because: > use iCloud Keychain as your password manager This is exactly the thing that is a total non-starter. A proprietary, closed-source third-party service that can go offline at any time? I would maybe trust that with my hackernews login and that's about it. Not even reddit. > once while two devices are online together This is also still a non-starter. What happens when you are traveling with only one device, and lose or break it? I simply buy a new phone, go get the USB drive with all my passwords on it from the hotel safe, connect it to the phone, and I'm back in business. What do you do with passkeys?
- WorldMaker 3y ago
  > This is exactly the thing that is a total non-starter. A proprietary, closed-source third-party service that can go offline at any time? There will be open-source options eventually. Certainly, the wheels are spinning among some of the HN sorts that think about such things. Apple and Google (and Microsoft) have a head start because they have to coalition build on these standards to make them work, but it is all still based on standards (all of FIDO2, WebAuthn). But in the context of "just save the randomly generated password in your browser's password manager", the big 3 cover the majority of average users' browsers, so the UX should in theory be simple for the average user, not just the technically proficient user (nor the "I only trust open source" user). Firefox is, of course, working on their passkey tools as well. > What happens when you are traveling with only one device, and lose or break it? The same recovery process that happens for your primary account on the device, your Apple iCloud account or Google Account. That part isn't changing in all of this. Those are closed source so whatever details for how they already today escrow recovery keys for scenarios like that where no other device is available to bootstrap recovery from. Though once bootstrapped from a recovery state, all the passkeys should flow to the new device just as all the passwords in the password manager and you are back in business. Recommending owning at least two Apple devices connected to your account is already common security recommendation going back several years now because of Apple's E2E guarantees when you do so. That's not new guidance unique to their passkeys implementation, but also a cornerstone of existing Apple ecosystem security.