> Why would we suddenly voluntarily compromise security and go back to 1FA? Nothing about passkeys precludes you from doing additional security checks. The ch

> Why would we suddenly voluntarily compromise security and go back to 1FA? Nothing about passkeys precludes you from doing additional security checks. The challenge is that once you say "but an iCloud-synced passkey is not secure enough", there are very few options which are better - specifically because the attacker model requires either user participation or both an iCloud and existing local device passcode compromise. Many sites are relying on SMS, TOTP, or email second-factor challenges, when the attacker already would have more than enough information to clone the TOTP from backup, to port the SMS number over (or just get the same push on a new device they control), or to read your email. So unless you are doing in-person verification or relying on a secondary hardware-bound factor, there's limited "strength" utility in additional checks. We are generally hitting the edges of what the multi-factor model can represent. All models have limitations. My opinion in particular is that MFA is meant to represent an organization's challenges for authentication factors, rather than requests challenging against an externalized authentication process with its own business logic. > 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. We can only hope. This is both more secure and more usable than what consumer facing websites do today, including many banks, from a user perspective. The challenge is that an externalized authentication process will not map into risk mitigation processes or regulatory requirements today. I suspect what will happen is that there will be a broad rollout, without actual security events, in a lot of verticals, and the statistics from that (e.g. phishing on password+SMS vs passkey logins) will motivate more productive reasoning on how new verticals can accept it. > Sure, people suck at passwords, but even a poor password combined with an authenticator would be better than solely an authenticator. Passkey-capable authenticators can do user verification, such as with a PIN or biometric. User verification is the expected mode of operation for passkeys. The challenges are that the site is abstracted away from understanding what steps were taken, and that a multi-device credential does not meet strong physical possession requirements. Speaking broadly, there is a conflict between supplying a site with more control over the options which may or may not be supported in an authenticator, vs such control leading to sub-par user experience and even rejecting the user's choice of authenticator. I don't think anything will resolve this conflict other than time changing people's perceptions on what they need. > 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. There are capabilities to use devices across ecosystems. Generally this is done via a proximity-backed QR code initiated flow. The expectation is that sites will allow for multiple registered passkeys against a single account, and that sites will be motivated to register an additional passkey for future local login if such a cross-device flow was used. > Some of this could be mitigated by a universal pluggable passkeys backend, but I am not really seeing any substantial movement in this direction. Android has publicly announced future plans to support such a thing, although I don't believe they have announced an approach or timeline. 1Password and Dashlane have both announced their web extensions will allow them to operate as passkey providers, and I believe both have now shipped at least early access code. I would certainly say the 'interest' is there to support pluggability. > 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. How is this different than the state of password managers over the last decade? Both passwords and passkeys require local multi factor (possession of the mobile device plus a passphrase/biometric) to do any of these actions. > 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. In practice, it is quite a bit more complicated, including being specific to the device or software ecosystem. On Apple devices, in addition to normal HSM clustering-style provisioning of new devices, there is support for a user-controlled paper recovery key. Like most implementations of cloud-synced vaults we've seen over the last decade, the vendor has no capability to read the data of the vault. From an organizational risk perspective, there's no way you can legitimately accept passkeys when you can't evaluate their authentication policies or backing security. From a user's risk perspective, they are 100% correct in assuming this is a secure system. > 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. A workforce can do this by requiring the keys they provision, but it is not am acceptable course of action for a public-facing domain. See https://www.chromium.org/security-keys/ https://www.chromium.org/security-keys/ : "To this end, public websites that restrict the set of allowed Security Keys should do so based on articulable, technical considerations." "If Chrome becomes aware that websites are not meeting these expectations, we may withdraw Security Key privileges from those sites. " You must map your policy for what are acceptable security keys onto the _ecosystem_ of available attested security keys. Just accepting Yubikeys may eventually cause your site to lose access to WebAuthn API in certain browsers. My understanding is that this is done so that early movers in the security key space (like a Yubico, who has proposed, co-authored or contributed to most of these specifications) don't gain market lock-in. > 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. The Web Authentication API does not provide a way to introspect which authenticators are available or which credentials they may store. Instead, the user is given some consent interface by which to release one credential on one authenticator. Since credentials are also origin-bound, the only difference is that an attacker with malicious code on that origin could get you to release a credential without phishing any previous steps (e.g., asking you for your username and first-factor password login, so that it can see valid credential handles). For CTAP, there are two protections. CredProtect prevents enumeration of credentials without user verification, so someone who gets your key cannot see the domain you have accounts on without further interaction from the key fob owner. Second, platforms have generally been locking down the ability for applications to directly interact with CTAP 2 interfaces, possibly behind an entitlement.