129
Passkeys are not a trap. Use them! (hachyderm.io)
submitted 1 week ago by to c/privacy@lemmy.ml
173 comments fedilink hide all child comments
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] 22 points 1 week ago (9 children)

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.

The web wasn't supposed to be controlled by corps either, and look where we are now.

If passkeys were to follow the same path as the web, here's what it would look like. Corporate passkeys get the most users because of OS integration and convenience. Now that they have all the users they can commandeer the standards, and make them so complex and evolve so quickly that non-corporate implementations can't keep up (think Firefox vs Chrome). Corporations convince websites to drop support for outdated passkeys, citing security issues. Non-corporate implementations are locked out. Monopoly is established.

And now that passkeys are centralized to corps, the government can exert power on them, mandating hardware attestation for things like hardware-backed id and age verification. They push for backdoors, so they can log into anybody's account. Bye bye privacy.

  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 5 points 1 week ago* (8 children)

    Question: Why did these corps implement TOTP? You should be able to answer this from an economic perspective of them trying to save money.

    Another question: why aren't these corporations locking down TOTP to restrict them to their own validator apps, in the same way you're proposing that they might do for passkeys?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 11 points 1 week ago (1 child)

    why aren't these corporations locking down TOTP to restrict them to their own validator apps

    But they do. There are TOTP implementations that have been intentionally modified to prevent using standard apps. I don't remember other examples right now, but I think Steam Guard is one.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 week ago

    I'm sure a lot of people (like myself) would refuse to install a special custom TOTP app just to be able to use one site. They're only hurting TOTP adoption by doing that, and thus increasing the amount of support resources they need to allocate to account hacking / hijacking.

    I'm sure there are other companies too willing to go against their economic interests for various reasons, but they're going to be in the minority.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 6 points 1 week ago* (last edited 1 week ago) (2 children)

    Why did these corps implement TOTP?

    To reduce support load from people getting their accounts hacked and asking support to get them re-instated. I don't doubt that these incentives also drive the push for passkeys, but passkeys are much more opaque and tightly integrated with the OS, and is thus more vulnerable to centralization.

    why aren't these corporations locking down TOTP to restrict them to their own validator apps

    They are. Authy is the biggest offender I know.

    Edit: some info about how Authy locks you in: https://www.bentasker.co.uk/posts/blog/general/switching-to-aegis-for-totp-codes.html. Note that some websites integrate directly with Authy and force you to use Authy to set up the TOTP. The only way out is to use a rooted phone to transfer the codes to another app like Aegis.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 week ago (1 child)

    I don’t doubt that these incentives also drive the push for passkeys, but passkeys are much more opaque and tightly integrated with the OS, and is thus more vulnerable to centralization.

    I'm not sure what you mean by integrated into the OS. I use a FOSS password manager on android (keepassdx), storing passkeys both for apps and websites. When the browser or an app asks for a passkey, android uses the password filling service you've chosen (in my case keepass), and it loads up, no differently from when there's a password prompt. I'm not sure how it works on other platforms like iOS, windows, or linux, but at least on android, you can use a FOSS password manager not integrated into the OS.

    They are. Authy is the biggest offender I know.

    Specific sites aren't locking down TOTP, this seems to be an EEE scheme of Authy specifically, since as you say the TOTP codes provided by sites still work with other authenticators. I'm referring to the case where say, amazon forces you to use their app to login, or creates their own custom TOTP or passkey app, and won't let you log into their site without it, and then you have no control over your login method or codes.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 6 days 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 1 week ago (2 children)

    what makes passkeys any different from all the other times they have embrace, extend, extinguished? what, fundamentally, stops them from using attestation in the exact way the user described? specifically, what stops the following scenario from playing out?

    1. passkey support becomes commonplace across the web
    2. many websites stop using passwords due to their inherent security issues
    3. most users (for brevity, say 90% or more) just use their OS to store passkeys because it's easier
    4. apple provides attestation for passkeys stored in the Secure Enclave
    5. google provides attestation for whatever their business goals are
    6. google refuses passkeys that aren't attested due to their "security issues"
    7. apple does the same, which has the added benefit of killing devices without a Secure Enclave
    8. maybe PCI-DSS requires attested passkeys because of "security issues"
    9. maybe financial institutions require attestation (similar to the ctsProfileMatch issue with GrapheneOS)
    10. 90% or more of users don't notice or care about steps 4-9
    11. most of the 10% or less need to use at least one account that requires such an attested passkey
    12. idk what happens with firefox but i'm sure many firefox users (including me) have encountered a website that could work with firefox but chooses not to (based on User-Agent or similar)

    obviously that isn't the only scenario one could envision but i don't really see what makes this one unreasonable to expect

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 week ago (1 child)

    Once you can correctly answer the question you responded to, you'll see why its against their material interests to EEE logins, whether its TOTP or passkeys.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 week ago

    well idk about you but i have the steam guard app on my phone, and it's a pain in the ass too so it's not that. plus, unlike TOTP, passkeys are dead simple and integrated into the OS. so i can honestly say i have no idea what you're getting at and why it applies to passkeys as well as it applies to TOTP.

  • permalink
  • fedilink
  • source
  • parent