4 ms·
> 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 on
by 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 agoIt is a physical hardware key (inside the device). It leverages the “Secure Enclave” or “TPM”. There’s no Google code involved.
- codedokode 4y agoI 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 agoI 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.