Ricky Mondello (@rmondello@hachyderm.io)
hachyderm.io
If you actually read the “Passkeys are a trap. Do not use them.” post going around, you’ll find a transparent attempt to clumsily string together a conspiracy. The post is predicated on the idea that a feature of WebAuthn called “attestation”, which is only used in high-assurance and usually corporate scenarios, and usually with physical hardware security keys, will be leveraged to hurt people, somehow. The post posits that a website like X will bait and switch users: first, you get a passkey. Then, later, scary “attested” passkeys! This simply isn’t possible to do because attestation isn’t supported on the web for mass market, consumer authentication. Attestation for passkeys (software-based, syncable credentials) is antithetical to their mass market goals, and would freeze out independent, non-corporate-backed credential managers. It’s an explicit non-goal of the designers of passkeys, who work together in a forum anyone can join. And trust me, websites and apps like banks repeatedly asked for attestation at the beginning of the industry’s passkey journey. The platforms, browsers, and credential management apps have held firm that the goal of passkeys is reducing phishing and **not** some kind of trusted computing scheme. (And I will note: over my dead body!) Besides the theory of the case being fundamentally wrong, there are several things that make the post disqualifying in terms of arguing something useful or important in the realm of security, privacy, and user authentication: 1. Intentionally presenting things that are complicated as inherently suspicious. (Delivering security by design can be complicated, yes!) 2. Describing TOTP as a “great solution” for adding security to a password-based account. When the most common threat model on the web is phishing (a word the post never mentions!), TOTP hardly buys you _anything_. TOTP is phishable. 3. Seeming to be unbothered by how many logical leaps are being taken without actually understanding the topic being discussed. There are bad things happening in tech and untrustworthy people and companies do exist, but they’re largely in the AI space, not the “let’s stop people we love from getting compromised through phishing” space.

A rebuttal to an anti-passkey, pro-TOTP post that has made the rounds on Lemmy as well.

  • hirihit640@sh.itjust.worksEnglish
    1·
    3 hours ago

    By integrated into the OS, I’m talking about the major corporate implementations, like Apple, Microsoft Windows, or Google Android. The advantage is that you don’t need to install an app or browser extension, and then give that app permissions. Everything is already set up. I’ve seen some websites like Amazon try to automatically set up passkeys for you, so it’s likely that a good portion of the population already has passkeys set up in these corporate passkey managers, before they have the opportunity to learn about alternatives.

    Speaking of Keepass, you should check out these discussions:

    https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994673954

    https://github.com/keepassxreboot/keepassxc/issues/10406

    In short, keepass had a way of exporting passkeys unencrypted to disk, and some people did not like that, threatening things like:

    This implementation is not spec compliant and has the potential to be blocked by relying parties.

    The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I’ve already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).

    This is exactly what the “passkeys are a trap” article warned about. Passkey attestation allows websites to reject specific clients, just like how SafetyNet allows apps to block GrapheneOS users. In the future, banking websites or google.com could force usage of passkeys, and block usage of keepass. Are there enough keepass users to protest this? Certainly hasn’t worked well for GrapheneOS and SafetyNet.

    this seems to be an EEE scheme of Authy specifically

    Functionally, it’s locked down because it’s nearly impossible to migrate the TOTP codes to another app.

    You don’t really see custom TOTP apps because users don’t want to have to install an app just to generate TOTP codes for a specific website. Google Authenticator could have done this, but I think Google decided to start moving towards passkeys instead of enshittifying Google Authenticator.

    There is much more incentive to do this with passkeys, because you can lock down passkey sharing in ways that can’t be done with TOTP. For example, Netflix could block passkeys from any client that allows passkey copies and exports, like Keepass, in order to block account sharing.