| > There is one way to get both, which I assume Google is offering here: Have the key inaccessible to the user of the device, but allow some cloud provider access, so it can be automatically backed up to the cloud. It's a bit more complicated than that: if you enable synchronization, Google or Apple have stored encrypted blobs but they don't have access to the data. To decrypt it you still need access to one of your linked devices. The other thing to remember is that the keys can be exposed only for the time it takes to install them: you get a new phone, it downloads the blob and has one of the other devices approve decryption, and that key is immediately re-encrypted locally. That makes it a lot harder to get a copy because the attacker has to compromise one of the registered devices enough to attack that process rather than simply getting access to an unlocked phone. Finally, it's not as simple as one-key-to-rule-them-all: the WebAuthn handshake has both the synced key and a device key. That means that a high-security application could still do additional checks any time they see the synced key used with a previously-unseen device key. > If a phone is in the wrong hands, it's much easier to gain access to the phone using fingerprints than it is using passwords: There is a good chance some usable fingerprints from you are still on the device cover itself. Sure, an attacker would need some resources to take the fingerprints and build something that can be used with the phone's sensor, but if enough people use fingerprints for auth, attackers will streamline this step quickly. Again, I would suggest looking at the decades of prior art (or considering that it's moot for the majority of Apple users using infrared facial scans with liveness checks). It's actually pretty hard to get usable prints since they need to have some structure, not just a single flat image, and people don't commonly build phone cases out of things which record that kind of detail. It's not impossible but the odds are already low even before you consider that the attacker only has a few tries and a time window to accomplish it in. Most people are not interesting enough to launch this type of attack against (think about what it's like trying to make money with that unlocked phone without leading the police to your door) and in a targeted attack looking for something like political dirt they're going to get that password by watching the user type it because not using more advanced systems means they're forced to do so frequently. > That's bad enough if it grants "only" access to the phone itself, but now it would also grant the attacker access to each and every online account. Kind of like what happens if they get full unrestricted access your phone without this and recover all of the saved passwords? Remember that this is all optional geared at the vast majority of normal users. If you really think that the risk of someone recovering a fingerprint / facial scan is too high, you're free to continue using hardware WebAuthn tokens like you are hopefully doing right now. What this is solving is the friction around creating secure passwords and not losing them, and getting away from the idea that an email address is the real key to everything. If you want more details about how it works, I would definitely listen to Adam Langley's interview here: https://www.buzzsprout.com/1822302/11122508-passkeys-feat-ad... |