6 ms·

I find the general idea in this quote hard for me to swallow: "And passkeys can’t suffer mass exposure like passwords because apps and websites only store the

by taeric 3y ago

I find the general idea in this quote hard for me to swallow: "And passkeys can’t suffer mass exposure like passwords because apps and websites only store the public key — the private key remains safely stored on your device. If everyone used passkeys, much of the harmful effects of data breaches would disappear." If a service can sync your passkey between devices, then by definition it can be copied off. And if it can be copied off, then it can also be caught in a data breach. And as soon as your passkey can be part of a data breach, we seem largely back where we started? What am I missing? Is it better than it was? Almost assuredly. But a large part of the annoyances brought up in this post are specifically to limit breach exposure. Apple wants to make sure any keys it has synced can only be lost by a breach at Apple. Same for Google. If this is opened up to allow syncing by other actors, each other actor in the chain is now a potential breach, no?

the_snooze 3y ago
Passkey private keys are encrypted at rest, even on the user's device. You typically need a PIN, password, or biometric to unlock the private key for authentication. Getting your hands on a sync data breach won't do you much good because each user's encrypted blob (containing the private keys) has its own decryption key. It's not 100% fool-proof, but it's a huge improvement over password-based authentication. Remember, security is a "better than" game.
- taeric 3y ago
  Right, that part I largely get. At least, I think I do. Such that if I am saying something that is off in that, please correct me. My question is basically, as soon as they are exportable across devices, then you are trusting the encryption of every actor involved, no? Such that, if there was a process to share from Google to any other company involved, then that means any company involved could be breached and the key compromised. You could do time bound shares. But, that is ultimately going to fall back on access to Google being what secures you. Right? (And replace Google with Apple for the same general scenarios.) Now, Yubikeys worked by never letting you get the private key off the device. As such, if you lose the device, you can no longer use those secrets to authenticate. Solution then, was to have multiple keys all configured such that you would have to lose all of them. If you needed to reestablish a brand new set of keys, you had to do that in another way. At companies, this was largely done by doing it in front of an IT person that should either know you, or validated some other identification. (A bank would similarly require you to be there in person with government ID.) What is the article's proposed way of letting you share passkeys at will across devices and companies, that doesn't largely compromise the security?
  - the_snooze 3y ago
    Just to be clear, are you asking about syncing passkeys across devices (ostensibly within the same ecosystem)? Or exporting passkeys between different ecosystems? The typical use case for passkeys is that you can register multiple passkeys on an account, representing each authorized device. Each device can have its own distinct passkey provider. Services like 1Password allow you to sync passkeys between different devices, but those all stay within the 1Password ecosystem. 1Password also lets you export passwords and passkeys to different credential managers, but that's a one-off operation, presumably because you're leaving that ecosystem for another.
    - taeric 3y ago
      The article was specifically upset with Google and Apple for not letting you export across ecosystems. So, I'm specifically asking how they think that could work. Am I misreading the article on that?
      - the_snooze 3y ago
        Got it. I think import/export is a solved problem, assuming you're OK with (at least temporarily) having your secrets unencrypted. Password managers already do this. It's not a technical issue that's preventing Apple or Google from making their passkeys importable/exportable.
        taeric 3y ago
        This doesn't seem to address my question, though? That is, agreed it is not a technical issue, but it is a security one? As you stated, if you are ok with your secrets being unencrypted, then sharing is totally possible. But this seems to walk headlong into having to trust everyone that you share the unencrypted secret with?
        protonpass 3y ago
        Hi there, it is up to individual websites whether they require passkeys or passkeys + 2FA etc.. It is also important to note that most attacks are phishing-based, and passkeys are phishing-resistant, and will only work on the originating website. Proton Sentinel also helps to protect account takeovers, even when an attacker has stolen your password.
vinay_ys 3y ago
Passwords can be compromised on client side or server side and since users tend to reuse them, compromise on fun.com can compromise your bank.com account. Passwords+OTP plus a whole bunch of heuristics based account lockdown mechanisms improve this quite a bit. But still OTP is vulnerable for sophisticated targeted attacks. Passkeys improve on this while actually improving the usability as well. Passkeys come in two flavors – independent-hardware-bound (example: yubikey) and platform-authenticator-bound (example: Passkeys by Apple). The former is bound to a single hardware token but can be used on many devices (your phones, laptops etc) to login to your accounts. The latter is primarily tied to your Apple ID account (where Apple is the platform provider, for example) and also to your Apple devices like iPhones and MacBooks where your Apple ID is already logged in and iCloud Keychain syncing is turned on. Apple automatically and securely syncs your passkeys to those devices. Obviously hardware-bound is a bit more secure than platform-authenticator bound, because platform authenticator can have a SPOF within the platform (a compromise anywhere within that platform stack - client-side, server-side etc. large surface area) where such a compromise is also completely hidden from the user. In contrast, the hardware-bound has a much smaller surface area. Only possibility of compromise are the hardware, the client (browser or the app), and the particular app backend server-side. Like all software stack, it is very likely this stack also has bugs that can be exploited. But this stack is relatively lot simpler to audit and secure.
- taeric 3y ago
  Right, I don't know how to be precise in simple paragraphs about the ideas here. Basically, though, if you can authenticate from two or more devices (or, in a real sense, even applications on the same device), then whatever compute or secret is doing the authentication has to be copied between them. A brief dump of my understanding: (Edit to add, I put this dump here largely to see if I actually understand the general landscape. If there are holes/mistakes here, please call them out.) This was historically done by trusting the user to manage a secret that they attest they will not let anyone else know. In this world, the "compute" was often common knowledge, but hinged on a hard to guess part. This is no different than a credit card, so far. You agree that you will not let unauthorized users have your credit card. A not surprising hole in this security, was that you had no way of knowing if someone else had your secret. You could do audits, but in general access patterns had to checked by others. (Note, this works better than folks give credit.) Security keys took the path of making it so that the secret never gets off of the token device. There would be a challenge protocol that you could only succeed if you knew the secret, which was offloaded to the token. If you lost your token, you could not just get a new one. As the secret was flat out gone. Passkeys are taking a lot of the security lessons learned there, and trying to bring them to the general public. In doing so, though, they are looking to increase user friendliness by letting your secret be managed by their ecosystem. In the case of Apple and Google, they are basically taking the route that, as long as you are sticking to their programs and services, they will replicate a secret for you. This article is upset that Apple and Google are limiting the replication. Calling it a trap of passkeys. But... what is the alternative that is being pushed? Note that if the argument is that the increase in security is already enough with existing audits and non verbally communicated passwords, that is probably fine. I got the tone from the article that something sinister was at play from Apple/Google. Sounds like the sinister motivation is more of wanting high security, though?
cdumler 3y ago
The reason why it can't be abused the same way is because of the nature of the paired-one-way-encryption system. A normal password is one-way encrypted. The algorithm makes it easy to turn an input string into encrypted gibberish, but virtually impossible to take encrypted gibberish and turn it into a suitable input string. Your password is run through this "hash" algorithm and stored. To prove your authenticity, you provide the password and the system encrypts it the same way. If the gibberish matches, you must have known the original password. The problem is that this is subject to several attacks, notably a dictionary attack where you just have a big long list of known passwords. The attack encrypts each one and see if you find one that generates the same gibberish. So, let's take the user generated password out of the loop. The trick is that symmetrical, public-pair encryption creates two keys, such that: * A key used to encrypt a string or sign a blob cannot be used to decrypt or verify it (one-way). * A key's pair is the only one that can decrypt or verify a signature (symmetrical). * A completely random initial value (aka password) starts the process, but after which is no longer relevant to use. With this, we can create two keys: one we hold to ourselves (private) and one we hand out (public). When we want to authenticate, it goes something like: Server: Here is a blob of data I generated and encrypted with your public key, prove to me you know what I did. Client: Sure thing. (Decrypts blob with private key, wraps it with a private key signature, hands it back). Here ya' go! Server: OH.. Nice. Only you could have decrypted it, and only you can sign the results that match the public key I have on file for you. You must be you. If the public key is stolen, it doesn't do the attacker any good. Anything it encrypts is only good for you, and anything that it signs can only be verified by you. In theory, the attacker could get you to authenticate with them and that would show you are you. But, your password manager generates a new key for every site and authenticates with the key it knows. Even if the attacker uses one of your keys, it doesn't work unless it is for the site in question, meaning a man-in-the-middle attack. But, this isn't about stopping that. That is what DNS certificates are for. Passkey prevents having anyone but you ever knowing what the password was.
- taeric 3y ago
  Right, I think this is largely covered in sibling posts. I agree that what you are describing is more secure than only using a password. It is, at a basic level, standard asymmetric encryption, right? My assertion is more that the more you copy the private secret around, the more you are at risk of exposure. That some companies try to increase usability by copying it in their ecosystem is to make life easier for their users. They are shying from letting you export the secret, but not necessarily out of nefarious motivations? Indeed, there seem to be solid security motivations to not do so. Right?

by taeric 3y ago

the_snooze 3y ago

Passkey private keys are encrypted at rest, even on the user's device. You typically need a PIN, password, or biometric to unlock the private key for authentication. Getting your hands on a sync data breach won't do you much good because each user's encrypted blob (containing the private keys) has its own decryption key. It's not 100% fool-proof, but it's a huge improvement over password-based authentication. Remember, security is a "better than" game.

taeric 3y ago
Right, that part I largely get. At least, I think I do. Such that if I am saying something that is off in that, please correct me. My question is basically, as soon as they are exportable across devices, then you are trusting the encryption of every actor involved, no? Such that, if there was a process to share from Google to any other company involved, then that means any company involved could be breached and the key compromised. You could do time bound shares. But, that is ultimately going to fall back on access to Google being what secures you. Right? (And replace Google with Apple for the same general scenarios.) Now, Yubikeys worked by never letting you get the private key off the device. As such, if you lose the device, you can no longer use those secrets to authenticate. Solution then, was to have multiple keys all configured such that you would have to lose all of them. If you needed to reestablish a brand new set of keys, you had to do that in another way. At companies, this was largely done by doing it in front of an IT person that should either know you, or validated some other identification. (A bank would similarly require you to be there in person with government ID.) What is the article's proposed way of letting you share passkeys at will across devices and companies, that doesn't largely compromise the security?
- the_snooze 3y ago
  Just to be clear, are you asking about syncing passkeys across devices (ostensibly within the same ecosystem)? Or exporting passkeys between different ecosystems? The typical use case for passkeys is that you can register multiple passkeys on an account, representing each authorized device. Each device can have its own distinct passkey provider. Services like 1Password allow you to sync passkeys between different devices, but those all stay within the 1Password ecosystem. 1Password also lets you export passwords and passkeys to different credential managers, but that's a one-off operation, presumably because you're leaving that ecosystem for another.
  - taeric 3y ago
    The article was specifically upset with Google and Apple for not letting you export across ecosystems. So, I'm specifically asking how they think that could work. Am I misreading the article on that?
    - the_snooze 3y ago
      Got it. I think import/export is a solved problem, assuming you're OK with (at least temporarily) having your secrets unencrypted. Password managers already do this. It's not a technical issue that's preventing Apple or Google from making their passkeys importable/exportable.
      - taeric 3y ago
        This doesn't seem to address my question, though? That is, agreed it is not a technical issue, but it is a security one? As you stated, if you are ok with your secrets being unencrypted, then sharing is totally possible. But this seems to walk headlong into having to trust everyone that you share the unencrypted secret with?
        protonpass 3y ago
        Hi there, it is up to individual websites whether they require passkeys or passkeys + 2FA etc.. It is also important to note that most attacks are phishing-based, and passkeys are phishing-resistant, and will only work on the originating website. Proton Sentinel also helps to protect account takeovers, even when an attacker has stolen your password.

vinay_ys 3y ago

Passwords can be compromised on client side or server side and since users tend to reuse them, compromise on fun.com can compromise your bank.com account. Passwords+OTP plus a whole bunch of heuristics based account lockdown mechanisms improve this quite a bit. But still OTP is vulnerable for sophisticated targeted attacks. Passkeys improve on this while actually improving the usability as well. Passkeys come in two flavors – independent-hardware-bound (example: yubikey) and platform-authenticator-bound (example: Passkeys by Apple). The former is bound to a single hardware token but can be used on many devices (your phones, laptops etc) to login to your accounts. The latter is primarily tied to your Apple ID account (where Apple is the platform provider, for example) and also to your Apple devices like iPhones and MacBooks where your Apple ID is already logged in and iCloud Keychain syncing is turned on. Apple automatically and securely syncs your passkeys to those devices. Obviously hardware-bound is a bit more secure than platform-authenticator bound, because platform authenticator can have a SPOF within the platform (a compromise anywhere within that platform stack - client-side, server-side etc. large surface area) where such a compromise is also completely hidden from the user. In contrast, the hardware-bound has a much smaller surface area. Only possibility of compromise are the hardware, the client (browser or the app), and the particular app backend server-side. Like all software stack, it is very likely this stack also has bugs that can be exploited. But this stack is relatively lot simpler to audit and secure.

taeric 3y ago
Right, I don't know how to be precise in simple paragraphs about the ideas here. Basically, though, if you can authenticate from two or more devices (or, in a real sense, even applications on the same device), then whatever compute or secret is doing the authentication has to be copied between them. A brief dump of my understanding: (Edit to add, I put this dump here largely to see if I actually understand the general landscape. If there are holes/mistakes here, please call them out.) This was historically done by trusting the user to manage a secret that they attest they will not let anyone else know. In this world, the "compute" was often common knowledge, but hinged on a hard to guess part. This is no different than a credit card, so far. You agree that you will not let unauthorized users have your credit card. A not surprising hole in this security, was that you had no way of knowing if someone else had your secret. You could do audits, but in general access patterns had to checked by others. (Note, this works better than folks give credit.) Security keys took the path of making it so that the secret never gets off of the token device. There would be a challenge protocol that you could only succeed if you knew the secret, which was offloaded to the token. If you lost your token, you could not just get a new one. As the secret was flat out gone. Passkeys are taking a lot of the security lessons learned there, and trying to bring them to the general public. In doing so, though, they are looking to increase user friendliness by letting your secret be managed by their ecosystem. In the case of Apple and Google, they are basically taking the route that, as long as you are sticking to their programs and services, they will replicate a secret for you. This article is upset that Apple and Google are limiting the replication. Calling it a trap of passkeys. But... what is the alternative that is being pushed? Note that if the argument is that the increase in security is already enough with existing audits and non verbally communicated passwords, that is probably fine. I got the tone from the article that something sinister was at play from Apple/Google. Sounds like the sinister motivation is more of wanting high security, though?

cdumler 3y ago

The reason why it can't be abused the same way is because of the nature of the paired-one-way-encryption system. A normal password is one-way encrypted. The algorithm makes it easy to turn an input string into encrypted gibberish, but virtually impossible to take encrypted gibberish and turn it into a suitable input string. Your password is run through this "hash" algorithm and stored. To prove your authenticity, you provide the password and the system encrypts it the same way. If the gibberish matches, you must have known the original password. The problem is that this is subject to several attacks, notably a dictionary attack where you just have a big long list of known passwords. The attack encrypts each one and see if you find one that generates the same gibberish. So, let's take the user generated password out of the loop. The trick is that symmetrical, public-pair encryption creates two keys, such that: * A key used to encrypt a string or sign a blob cannot be used to decrypt or verify it (one-way). * A key's pair is the only one that can decrypt or verify a signature (symmetrical). * A completely random initial value (aka password) starts the process, but after which is no longer relevant to use. With this, we can create two keys: one we hold to ourselves (private) and one we hand out (public). When we want to authenticate, it goes something like: Server: Here is a blob of data I generated and encrypted with your public key, prove to me you know what I did. Client: Sure thing. (Decrypts blob with private key, wraps it with a private key signature, hands it back). Here ya' go! Server: OH.. Nice. Only you could have decrypted it, and only you can sign the results that match the public key I have on file for you. You must be you. If the public key is stolen, it doesn't do the attacker any good. Anything it encrypts is only good for you, and anything that it signs can only be verified by you. In theory, the attacker could get you to authenticate with them and that would show you are you. But, your password manager generates a new key for every site and authenticates with the key it knows. Even if the attacker uses one of your keys, it doesn't work unless it is for the site in question, meaning a man-in-the-middle attack. But, this isn't about stopping that. That is what DNS certificates are for. Passkey prevents having anyone but you ever knowing what the password was.

taeric 3y ago
Right, I think this is largely covered in sibling posts. I agree that what you are describing is more secure than only using a password. It is, at a basic level, standard asymmetric encryption, right? My assertion is more that the more you copy the private secret around, the more you are at risk of exposure. That some companies try to increase usability by copying it in their ecosystem is to make life easier for their users. They are shying from letting you export the secret, but not necessarily out of nefarious motivations? Indeed, there seem to be solid security motivations to not do so. Right?