5 ms·

i kinda see passkeys being useful for all those websites i really don't care about and just have a short simple password for/something saved in a password manag

i kinda see passkeys being useful for all those websites i really don't care about and just have a short simple password for/something saved in a password manager i use once in a blue moon and wouldn't be too upset to loose access.

boring_twenties 3y ago
I don't see how passkeys would be better for that (or for anything, really) than simply letting the browser autogenerate a password and save it in its built-in password manager?
- acdha 3y ago
  It’s much faster, doesn’t require you to tweak the generated password to fit their weakening requirements, and you’re never nagged to rotate it. I have used a password manager since the 2000s and for most sites like that I end up hitting the forgot password flow because they broke their password database or use inactivity expirations. You also don’t have problems when their front end developers break their form entry or validation for your password manager, which is common, and pushing this removes the justification for adding insecure MFA systems like SMS or emailed codes.
- WorldMaker 3y ago
  Think of passkeys as the browser autogenerating a password with much higher overall entropy (whose secret details can't be leaked if that website's database were to be compromised). The UX is basically the same: as a user, let the browser deal with it. Let the browser's password manager/keychain restore/backup/sync it. The overall security is higher (higher entropy, public-key cryptography). The DX for building that website is a little more complex, but not arduously more complex (especially for any website already previously supporting FIDO and WebAuthn standards for 2FA).
  - boring_twenties 3y ago
    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

I don't see how passkeys would be better for that (or for anything, really) than simply letting the browser autogenerate a password and save it in its built-in password manager?

acdha 3y ago
It’s much faster, doesn’t require you to tweak the generated password to fit their weakening requirements, and you’re never nagged to rotate it. I have used a password manager since the 2000s and for most sites like that I end up hitting the forgot password flow because they broke their password database or use inactivity expirations. You also don’t have problems when their front end developers break their form entry or validation for your password manager, which is common, and pushing this removes the justification for adding insecure MFA systems like SMS or emailed codes.
WorldMaker 3y ago
Think of passkeys as the browser autogenerating a password with much higher overall entropy (whose secret details can't be leaked if that website's database were to be compromised). The UX is basically the same: as a user, let the browser deal with it. Let the browser's password manager/keychain restore/backup/sync it. The overall security is higher (higher entropy, public-key cryptography). The DX for building that website is a little more complex, but not arduously more complex (especially for any website already previously supporting FIDO and WebAuthn standards for 2FA).
- boring_twenties 3y ago
  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.)