9 ms·

I am very bearish about the current push to passkeys. To start with, why throw out the password? We have literally spend a decade getting people to use 2FA - a

by crote 4y ago

I am very bearish about the current push to passkeys. To start with, why throw out the password? We have literally spend a decade getting people to use 2FA - and rightfully so. Why would we suddenly voluntarily compromise security and go back to 1FA? Sure, people suck at passwords, but even a poor password combined with an authenticator would be better than solely an authenticator. I am quite worried that websites will adopt this form of 1FA as the "new normal", compromising the security of anyone who still wishes to use secure passwords. Second, it looks like a blatant attempt to vendor-lock to me. The ability to sync passkeys across multiple devices is touted as a core feature, but meanwhile vendors only allow syncing between their own devices. This makes a multi-vendor environment extremely challenging to use, not to mention that switching to another vendor risks losing access to a lot of websites. And that's even ignoring the possibility of a vendor getting mad at you and deciding to nuke your account - and all the passkeys with it. Until there is a proper (open!) standard for exporting and importing passkeys, this is an unacceptable risk to me. Some of this could be mitigated by a universal pluggable passkeys backend, but I am not really seeing any substantial movement in this direction. To me, it looks like Google/Apple are trying to replace "Log in with Google/Apple" with "Log in with Passkeys" to make it seem like it is an open platform, while still locking it down as tightly as possible. Despite being an open standard, the implementations are anything but. Meanwhile, syncing provides a security risk. Every synced device has access to all websites all of the time. If you lose sight of a device, an attacker also has access to those websites - and they might even clone the passkeys. This opens you up to attacks which are extremely hard to detect, and due to the passkey being shared between all devices also relatively difficult to stop. I am also seeing a lot of misleading statements surrounding its security. For example, the claims that the keys are stored in a TPM/Secure Enclave. Meanwhile, in practice the TPM is only used for the local encryption of a copy of your passkeys. They also happily live on the cloud because they are being synced, and the vendors seem to be offering ways to recover them without access to a single device. They seem to be intentionally reusing language traditionally reserved for security implementations where the private key is stored solely in a HSM with no way to export it, but that is not at all what is happening here. Security-wise, it's nothing more than a rebranded cloud-synced password vault. Meanwhile, hardware token vendors like Yubikey point this out, but they do not see it as a threat as they are selling this synced implementation as not suitable for high-security environments - and rightly so. Luckily, the protocol has a built-in way to bypass this: the passkey backend can be asked for attestation, which in essence is an immutable certificate embedded in the hardware key, signed by the hardware vendor. If you want people to use a high-security passkey implementation, simply require attestation from a small list of well-known vendors - ideally only Yubikey of course. By hopping on the Passkeys bandwagon, they are able to erect significant barriers to entry for any potential competitors. Finally, Passkeys provide a privacy risk. With traditional Webauthn the user provides a username to the server, and the server responds with a set of opaque blobs which the user's tokens use for further bidirectional authorization. With Passkeys, the server asks the token for their set of domain-relevant passkeys, which include the username. This is required for the intended single-click usernameless login, but the flip side is that an attacker would be able to discover all of your accounts by probing the token. Alternatively, the server would be able to discover an association between multiple accounts of the same person, destroying attempts to retain an anonymous alt account. All in all, to me Passkeys looks like a thinly-veiled attempt to lock users into certain ecosystems, using convenience as a carrot-on-a-stick. Meanwhile, it adds significant security and privacy risks while claiming to be more secure. Seeing this being touted as a "more secure password replacement" by such major players makes me weep for the future.

zamadatix 4y ago
The below adds my understanding, which may very well be horribly wrong, of things. Corrections welcome as I try to figure this out myself! > We have literally spend a decade getting people to use 2FA This still supports MFA it just also supports SFA. Requiring MFA 100% of the time is a guarantee for something people won't use even if it fits security ideals better. > Second, it looks like a blatant attempt to vendor-lock to me. The ability to sync passkeys across multiple devices is touted as a core feature This one isn't as clean as I like either. There is a cross-device authentication flow, you can sign up multiple authenticators, and yubico has a backup authenticator proposal but none of these are necessarily ideal. I get not wanting to make the private key exportable for security reasons but if it's going to be allowed to sync on software authenticators over the internet I'm with you it should be able to sync between providers too. I'm not saying everyone should have to use cross-vendor sync I'm just saying it should be a capability. > Meanwhile, syncing provides a security risk. Every synced device has access to all websites all of the time. If you lose sight of a device, an attacker also has access to those websites - and they might even clone the passkeys. This opens you up to attacks which are extremely hard to detect, and due to the passkey being shared between all devices also relatively difficult to stop. You don't have to use external sync if you don't want and the standard still supports MFA on the passkey if you want but the truth is any solution that forces both of these 100% of the time will never see mass adoption. > I am also seeing a lot of misleading statements surrounding its security. I think a lot of it has to do with there being different levels of passkey store for different use cases. John Doe may want the convenience of just setting up a key on his phone and having it sync to all his devices for personal stuff but Jane Doe may need a hardware key with MFA for accessing the code repo at work and every option in-between. I don't think the security promises are misleading just maybe more complicated than one would wish because it's trying to be 1 way to cover all users and use cases not just "secure way" or "easy way for 1 particular device". > Meanwhile, hardware token vendors like Yubikey point this out, but they do not see it as a threat as they are selling this synced implementation as not suitable for high-security environments - and rightly so. Luckily, the protocol has a built-in way to bypass this: the passkey backend can be asked for attestation, which in essence is an immutable certificate embedded in the hardware key, signed by the hardware vendor. If you want people to use a high-security passkey implementation, simply require attestation from a small list of well-known vendors - ideally only Yubikey of course. By hopping on the Passkeys bandwagon, they are able to erect significant barriers to entry for any potential competitors. I don't know about "they are able to erect significant barriers to entry for any potential competitors" as the open passkey standard is specifically part of the next generation hardware key standard (FIDO2) rather than get locked into a proprietary hardware passkey format but I do agree it's the high-security way to use passkeys (as highlighted in my comments above). Not being able to export the private key, while annoying/disappointing in the cloud sync use case, is a hard requirement for the high-security use case so isn't an example of being there to provide lock-in. Especially with the ability to register multiple hardware authenticators for the same account. > Finally, Passkeys provide a privacy risk. With traditional Webauthn the user provides a username to the server, and the server responds with a set of opaque blobs which the user's tokens use for further bidirectional authorization. With Passkeys, the server asks the token for their set of domain-relevant passkeys, which include the username. I don't think the response contains any user identifying information. It does contain an opaque identifier the relying party can use to map to which user it was called the user-handle but that's not the user name it's a 64 byte sequence that can be mapped to a username if the other side already has it.

by crote 4y ago

zamadatix 4y ago

The below adds my understanding, which may very well be horribly wrong, of things. Corrections welcome as I try to figure this out myself! > We have literally spend a decade getting people to use 2FA This still supports MFA it just also supports SFA. Requiring MFA 100% of the time is a guarantee for something people won't use even if it fits security ideals better. > Second, it looks like a blatant attempt to vendor-lock to me. The ability to sync passkeys across multiple devices is touted as a core feature This one isn't as clean as I like either. There is a cross-device authentication flow, you can sign up multiple authenticators, and yubico has a backup authenticator proposal but none of these are necessarily ideal. I get not wanting to make the private key exportable for security reasons but if it's going to be allowed to sync on software authenticators over the internet I'm with you it should be able to sync between providers too. I'm not saying everyone should have to use cross-vendor sync I'm just saying it should be a capability. > Meanwhile, syncing provides a security risk. Every synced device has access to all websites all of the time. If you lose sight of a device, an attacker also has access to those websites - and they might even clone the passkeys. This opens you up to attacks which are extremely hard to detect, and due to the passkey being shared between all devices also relatively difficult to stop. You don't have to use external sync if you don't want and the standard still supports MFA on the passkey if you want but the truth is any solution that forces both of these 100% of the time will never see mass adoption. > I am also seeing a lot of misleading statements surrounding its security. I think a lot of it has to do with there being different levels of passkey store for different use cases. John Doe may want the convenience of just setting up a key on his phone and having it sync to all his devices for personal stuff but Jane Doe may need a hardware key with MFA for accessing the code repo at work and every option in-between. I don't think the security promises are misleading just maybe more complicated than one would wish because it's trying to be 1 way to cover all users and use cases not just "secure way" or "easy way for 1 particular device". > Meanwhile, hardware token vendors like Yubikey point this out, but they do not see it as a threat as they are selling this synced implementation as not suitable for high-security environments - and rightly so. Luckily, the protocol has a built-in way to bypass this: the passkey backend can be asked for attestation, which in essence is an immutable certificate embedded in the hardware key, signed by the hardware vendor. If you want people to use a high-security passkey implementation, simply require attestation from a small list of well-known vendors - ideally only Yubikey of course. By hopping on the Passkeys bandwagon, they are able to erect significant barriers to entry for any potential competitors. I don't know about "they are able to erect significant barriers to entry for any potential competitors" as the open passkey standard is specifically part of the next generation hardware key standard (FIDO2) rather than get locked into a proprietary hardware passkey format but I do agree it's the high-security way to use passkeys (as highlighted in my comments above). Not being able to export the private key, while annoying/disappointing in the cloud sync use case, is a hard requirement for the high-security use case so isn't an example of being there to provide lock-in. Especially with the ability to register multiple hardware authenticators for the same account. > Finally, Passkeys provide a privacy risk. With traditional Webauthn the user provides a username to the server, and the server responds with a set of opaque blobs which the user's tokens use for further bidirectional authorization. With Passkeys, the server asks the token for their set of domain-relevant passkeys, which include the username. I don't think the response contains any user identifying information. It does contain an opaque identifier the relying party can use to map to which user it was called the user-handle but that's not the user name it's a 64 byte sequence that can be mapped to a username if the other side already has it.