244
Passkeys are a trap. Do not use them (nonfunctional.substack.com)
submitted 4 weeks ago by to c/privacy@lemmy.ml
177 comments fedilink hide all child comments
 

Comments

you are viewing a single comment's thread
view the rest of the comments
[–] 8 points 4 weeks ago (2 children)

Both also have the same potential for abuse, any service could require you use their specific app.

That's not true. TOTP is just a mathematical formula for how you mix a "shared secret/seed" with the current time.

In the authors article, they mention that you could write your own python program to generate the correct rotating numbers.

There is no way Big Tech could force you to use a specific app, because at the end of the day, TOTP is just math. 1+1=2, that could be calculated by you, your cellphone, or me - it doesn't matter.

According to the article, Passkeys, on the other hand include a bunch of metadata. For example, can this passkey be copied or moved to another device.

The article is also very clear that all those fields can be faked except attestation.

And for those at home, attestation is a cryptographically secure way for an application to be certain that the application, operating system, and hardware are not modified to work in a way that the OS provider, application, and hardware vendor expect it to.

This has been abused by google/android to prevent/limit people from installing applications outside of the google play store, its been uses to force people to only use google-approved os' (no cfw, no grapheneos). The same technology is a requirement for windows 11 (TPM).

Now, if FIDO agreed to not include attestation as part of the metadata - this would not be a discussion: everyone would love and use passkey, as you (the user) get to decide how to store/backup and (optionally) share this key.

But that's not what FIDO did, the attestation flag is included in the metadata. And the author speculates that once people accept passkey, Big Tech will turn the screws and then start to force how you store your passkeys.

So, in an apocalyptic future "coming soon", when you try to log onto your bank, you'll be greeted with an error:

"We detected that your passkey is stored in the cloud. Your security is important to us. Please, install your new passkey onto your local device using your manufacturers approved Google Android Operating System and Google Approved passkey application."

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

    Really there is no way big tech can force me to use their app? Ok so you know how the open standard for TOTP is a six digit code computed from the time and shared secret? Well every student at the university of California and every employee at many companies across the US has to use an Authenticator app called duo which uses a 3 digit code generated by the app at the moment you attempt to log in. How does it do that? No idea it’s closed source. Is it even a formula like the TOTP open standard? Probably not I’d guess duos servers just send a code to both sides when you attempt a login. And would you look at that suddenly we have TOTP that I can’t write myself and I’m forced to use some shitty app.

    Now I do recognize the point you’re making but I want to emphasize it’s not about attestation being in the metadata or not. It’s about open standard compliance. As the open standard is written even if you have to have hardware attestation you can build the passkeys yourself (because this is functionality all password managers are quickly starting to have) and frankly having each passkey being device locked is good security practice to protect you from credential stealers and related malware. You’d still be in control and you could still sign in to as many devices as you want. You’d just need to make a new passkey for each one if you don’t wanna sign in the old fashioned way with a password and dual factor and such.

    The abuse scenario you describe would require a departure from the open standard. Is this possible? Of course. As I said some companies already do this with TOTP. But I don’t see that as a structural fault of passkeys that TOTP somehow doesn’t have like the article tries to imply. Both only work well for the consumer if the open standard is adhered to.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 4 weeks ago

    And would you look at that suddenly we have TOTP that I can’t write myself and I’m forced to use some shitty app.

    I think our definition of what TOTP is, differs. When I say TOTP, I mean TOTP as defined as a standard in RFC 6238.

    The behaviour you're describing with duo is something else, something proprietary. In my mind, duo would be an One Time Password (OTP).

    sidenote: TOTP is a specific/narrow implementation of the larger umbrella OTP.

    It’s about open standard compliance.

    Maybe I'm getting hung-up on semantics, but attestation is an open standard, like gpg is. With gpg you can implement your own encryption/decryption according to the gpg specification and your encrypted data will still be safe because you're trusting the math behind the Asymmetrical Encryption.

    Attestation is identical, but at the hardware level. The public/private keys are created by the hardware manufacturer. The private key is (often) isolated and stored in the CPU (or in a dedicated chip). The public key is freely published, so OS/application vendors know how to validate that an attestation response wasn't faked. The private key is not exposed and even if it were, the public key could be revoked by the OS/application.

    Attestation is great for device level security, but makes it nearly impossible to create backups/clones. :(

  • permalink
  • fedilink
  • source
  • parent