5 ms·

Google Password Manager, and the Apple equivalent, backup the passkeys for you. How they do this is fairly complicated. https://security.googleblog.com/2022/10/

Google Password Manager, and the Apple equivalent, backup the passkeys for you. How they do this is fairly complicated. https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html https://security.googleblog.com/2022/10/SecurityofPasskeysin... You don’t have control of your keys exactly, but Google can’t see your keys either and you can survive device theft/failure and transfer to a new device. So it’s pretty good in my opinion.

knaik94 4y ago
If I don't control my keys, they are not my keys. It seems more limiting and worse in practice than what it's supposed to be improving on. Google already encrypts my password in password manager, it already can't see my password and can't generate my 2 factor. Being fairly complicated is not a good excuse to let Google manage the keys for me.
- lll-o-lll 4y ago
  WebAuthn is a huge improvement from a security perspective. The private key is an anchor to a combination of factors. Proof of ownership (I have the device), proof of person (biometric) and/or proof of knowledge (pin code). Your password is not protected, it’s transmitted when you use it. If you’re infected with malware, that’s it, password exposed. With WebAuthn, nothing can be exposed.
  - knaik94 4y ago
    That is the purpose of 2 factor. 2 factor + password matches those same goals. I am not worried about transmitting my password on a device I own to a website I trust. If I am infected with malware, my 2 factor and separate login recovery email will keep me safe. I understand the theory of using SSH like public private keys to move one step away from passwords, but the reality is if I don't have control over the private keys, they are not my keys. Not having control over my private keys outweighs any benefits I would get from using WebAuthn.
  - codedokode 4y ago
    > With WebAuthn, nothing can be exposed. With solution proposed by Google, the keys are stored on the phone. If an attacker gains access to the phone using one of numerous vulnerabilities in Linux kernel, they can bypass any biometric locks. And PINs are short, so they can be easily bruteforced. The better solution is a physical hardware key that doesn't have tens of megabytes of ponentially vulnerable code and is not controlled by Google.
    - lll-o-lll 4y ago
      It is a physical hardware key (inside the device). It leverages the “Secure Enclave” or “TPM”. There’s no Google code involved.
      - codedokode 4y ago
        I cannot agree with this. First, as I understand, many Android phones do not have a TPM, they use "Trusted Execution Environment" instead. Second, Google can transfer private keys from device to Google cloud which means that if you can get root access to the phone, you can extract the keys using the same method.
        lll-o-lll 4y ago
        I think you are more correct than I am on this. There is some mechanism that attempts to prevent the private key from being exposable when going from device to device, but how exactly does it work? You could imagine the trust chain working by taking device 2 and encrypting the private key with its public key. But I can’t see any truely secure mechanism for cloud backup that doesn’t involve “please trust me”. I suppose the trusted compute environment may refuse to expose the key without a verified public key chained back to an embedded list of authorities (to encrypt the key). Still, that would be relying on trusting Google/Apple. (Stops the hacker who has your device, but doesn’t stop the gov who can legislate stuff for Google to do). I should dig some more to figure out exactly what they are doing.
- stetrain 4y ago
  Then use your own password manager that supports passkeys?
- brookst 4y ago
  You’re doing the free beer versus free speech semantics thing.
  - knaik94 4y ago
    I am not sure I understand what you mean. An open standard requires interoperability with all other implementations. No one is discussing the cost of anything.
    - brookst 4y ago
      Sorry, that wasn’t clear. I meant, you are pivoting the definition of “my keys” to a different principle even though it’s the same words. Same way people can argue endlessly about whether copyrighted software given away for $0 is “free” by defining “free” differently, there can be endless debate about “my keys” among those who define the term differently. To me, “my keys” are the materials I need to access something. If I rent an apartment, they are still my keys even though I eventually need to return them. Your framing is about ultimate control over the materials rather than their use, so presumably you’d say those apartment keys are not really yours. Both can be right but it becomes a semantic disagreement rather than a substantive one.
codedokode 4y ago
The article doesn't specify how the backup is encrypted, but it says that in can be decrypted with a PIN or unlock pattern. These are weak keys and can be easily bruteforced by Google. Also if you get banned from Google then you might lose access to your keys.
- lll-o-lll 4y ago
  They can only be decrypted on the device with the TPM. Google would need to have your device.
  - codedokode 4y ago
    I think that you are wrong. The blog post [1] says: > In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup. > To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys. This clearly states that you don't need original device to decrypt the keys: you only need a backup and a PIN code or unlock pattern which are easy to bruteforce. [1] https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html https://security.googleblog.com/2022/10/SecurityofPasskeysin...
    - brookst 4y ago
      > of another existing device that had access to those keys Doesn’t that mean you have to be able to log in to a device that has the keys stored locally? I did not take that to mean you can just give google the pin and they can provide the keys.
  - codedokode 4y ago
    Also, on Android instead of real TPM they often use a Trusted Execution Environment, which is basically a CPU mode.
josephcsible 4y ago
How are you supposed to make use of those backups if Google decides to unperson you?

knaik94 4y ago

If I don't control my keys, they are not my keys. It seems more limiting and worse in practice than what it's supposed to be improving on. Google already encrypts my password in password manager, it already can't see my password and can't generate my 2 factor. Being fairly complicated is not a good excuse to let Google manage the keys for me.

lll-o-lll 4y ago
WebAuthn is a huge improvement from a security perspective. The private key is an anchor to a combination of factors. Proof of ownership (I have the device), proof of person (biometric) and/or proof of knowledge (pin code). Your password is not protected, it’s transmitted when you use it. If you’re infected with malware, that’s it, password exposed. With WebAuthn, nothing can be exposed.
- knaik94 4y ago
  That is the purpose of 2 factor. 2 factor + password matches those same goals. I am not worried about transmitting my password on a device I own to a website I trust. If I am infected with malware, my 2 factor and separate login recovery email will keep me safe. I understand the theory of using SSH like public private keys to move one step away from passwords, but the reality is if I don't have control over the private keys, they are not my keys. Not having control over my private keys outweighs any benefits I would get from using WebAuthn.
- codedokode 4y ago
  > With WebAuthn, nothing can be exposed. With solution proposed by Google, the keys are stored on the phone. If an attacker gains access to the phone using one of numerous vulnerabilities in Linux kernel, they can bypass any biometric locks. And PINs are short, so they can be easily bruteforced. The better solution is a physical hardware key that doesn't have tens of megabytes of ponentially vulnerable code and is not controlled by Google.
  - lll-o-lll 4y ago
    It is a physical hardware key (inside the device). It leverages the “Secure Enclave” or “TPM”. There’s no Google code involved.
    - codedokode 4y ago
      I cannot agree with this. First, as I understand, many Android phones do not have a TPM, they use "Trusted Execution Environment" instead. Second, Google can transfer private keys from device to Google cloud which means that if you can get root access to the phone, you can extract the keys using the same method.
      - lll-o-lll 4y ago
        I think you are more correct than I am on this. There is some mechanism that attempts to prevent the private key from being exposable when going from device to device, but how exactly does it work? You could imagine the trust chain working by taking device 2 and encrypting the private key with its public key. But I can’t see any truely secure mechanism for cloud backup that doesn’t involve “please trust me”. I suppose the trusted compute environment may refuse to expose the key without a verified public key chained back to an embedded list of authorities (to encrypt the key). Still, that would be relying on trusting Google/Apple. (Stops the hacker who has your device, but doesn’t stop the gov who can legislate stuff for Google to do). I should dig some more to figure out exactly what they are doing.
stetrain 4y ago
Then use your own password manager that supports passkeys?
brookst 4y ago
You’re doing the free beer versus free speech semantics thing.
- knaik94 4y ago
  I am not sure I understand what you mean. An open standard requires interoperability with all other implementations. No one is discussing the cost of anything.
  - brookst 4y ago
    Sorry, that wasn’t clear. I meant, you are pivoting the definition of “my keys” to a different principle even though it’s the same words. Same way people can argue endlessly about whether copyrighted software given away for $0 is “free” by defining “free” differently, there can be endless debate about “my keys” among those who define the term differently. To me, “my keys” are the materials I need to access something. If I rent an apartment, they are still my keys even though I eventually need to return them. Your framing is about ultimate control over the materials rather than their use, so presumably you’d say those apartment keys are not really yours. Both can be right but it becomes a semantic disagreement rather than a substantive one.

codedokode 4y ago

The article doesn't specify how the backup is encrypted, but it says that in can be decrypted with a PIN or unlock pattern. These are weak keys and can be easily bruteforced by Google. Also if you get banned from Google then you might lose access to your keys.

lll-o-lll 4y ago
They can only be decrypted on the device with the TPM. Google would need to have your device.
- codedokode 4y ago
  I think that you are wrong. The blog post [1] says: > In some cases, for example, when the older device was lost or damaged, users may need to recover the end-to-end encryption keys from a secure online backup. > To recover the end-to-end encryption key, the user must provide the lock screen PIN, password, or pattern of another existing device that had access to those keys. This clearly states that you don't need original device to decrypt the keys: you only need a backup and a PIN code or unlock pattern which are easy to bruteforce. [1] https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html https://security.googleblog.com/2022/10/SecurityofPasskeysin...
  - brookst 4y ago
    > of another existing device that had access to those keys Doesn’t that mean you have to be able to log in to a device that has the keys stored locally? I did not take that to mean you can just give google the pin and they can provide the keys.
- codedokode 4y ago
  Also, on Android instead of real TPM they often use a Trusted Execution Environment, which is basically a CPU mode.

josephcsible 4y ago

How are you supposed to make use of those backups if Google decides to unperson you?