4 ms·

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 encryp

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.

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.