4 ms·
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 authentica
by 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 agoRight, 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 agoJust 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 agoThe 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 agoGot 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 agoThis 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 agoHi 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.