Please, please, please stop using passkeys for encrypting user data
blog.timcappalli.me
Passkeys are the future of authentication, but using them for data encryption is a disaster waiting to happen. Overloading these credentials creates a dangerous blast radius that can lead to the irreversible loss of a user's most sacred memories and documents.

Comments

  • 9tr6gyp3@lemmy.worldEnglish
    9·
    9 days ago

    This wouldn’t be an issue if the world went with SQRL instead of passkeys. All SQRL credentials are deterministic based on your public/private key and the site/app you use. There are no passkeys to store, so you wouldn’t be able to delete them. You generate them on the fly.

    But i guess we’ll have to deal with passkeys since that is the standard that won this time.

    • LifeInMultipleChoice@lemmy.dbzer0.comEnglish
      4·
      9 days ago

      I am probably going to look into SQRL later do to this comment but i figure maybe it’s best I ask here as well because others may be unaware as well. How does SQRL work, or how is it built different?

      Like if you take a phone and send messages, something like iOS will use your passcode as a last tie to “encrypt” iMessage data or health data before it is uploaded to the cloud. Thus if you forget the passcode on your phone, if you factory reset it to bypass the passcode, you also can’t access that health data from iCloud standardly. (There may be exceptions to this, I’m not sure)

      How would SQRL work differently?

      • 9tr6gyp3@lemmy.worldEnglish
        2·
        6 days ago

        SQRL is not useful for encrypting data. What its useful for is management.

        When you want to encrypt data, you use a solid symmetrical encryption algorithm with a strong key. How do you store that key? You want it to be something long and you can’t memorize, and you want it to be unique per account/set of data.

        The key management is where SQRL comes in. Think of it as a password manager, but you don’t need to store it or sync it anywhere necessarily.

        Hypothetically, if iMessage had SQRL functionality built in, you would login to your SQRL identity (using a master password and a public/private key pair). Then iMessage would provide a SQRL login, which you simply click an icon or scan a QR code with your phone. From there, iMessage and SQRL would create a public/private key between themselves that is deterministic. Any device that you are able to login to SQRL from would be able to generate that exact same public/private key pair.

        Steve Gibson did a demonstration on how it functions:

        https://youtu.be/Yxa5fbl2GtM