DNA companies should receive the death penalty for getting hacked | TechCrunch::Personal data is the new gold. The recent 23andMe data breach is a stark reminder of a chilling reality – our most intimate, personal information might

  • Saik0A
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    3
    ·
    7 months ago

    Passkeys are not better than a well implemented password. The fact that you cannot use 2fa on top of a passkey actually makes it a worse solution overall.

    Passkeys raise the minimum… but at the same time lower the maximum security a user can choose to utilize. I will not personally accept any solution that lowers the maximum level of security I can have.

    • Darkassassin07@lemmy.ca
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      7 months ago

      Several services do allow you to use MFA alongside passkeys, that’s up to the service, not the technology. Google, Github, Nvidia, and Microsoft to name a few.

      Passkeys are better than passwords as they cannot be stolen from the service you are logging into, or the network connection between you and the service as they are never transmitted. They can only be stolen directly from the users device (or their passkey/password manager). They are also encrypted and often stored behind biometric authentication locally making them extremely difficult to access even with physical access to the device.

      • Saik0A
        link
        fedilink
        English
        arrow-up
        5
        arrow-down
        2
        ·
        edit-2
        7 months ago

        Passkeys are better than passwords as they cannot be stolen from the service you are logging into

        A well implemented password also cannot be stolen. Only a hash of that password. Which would be equivalent to the public key, since it’s derived from the private key of the passkey. Much like the hash of a password is derived from the password.

        biometric authentication

        is bullshit. You must be able to revoke something in order for it to be effective as a password. Revoke your fingerprint… I’ll wait. Making it one factor is fine, making it the only factor is fucking moronic.

        making them extremely difficult to access even with physical access to the device.

        Which makes it the same “factor” as most MFA implementations. Something I have and something I have is not effective for adding security to something. Multi-factor isn’t having many of the same factor. It’s covering multiple factors.

        Edit:

        Google, Github, Nvidia, and Microsoft to name a few.

        Google!!! the company that automatically creates passkeys without your authorization. BTW… my google account IS MFA configured… The Passkey login on my phone SKIPS Mfa… So your list is already dead with the biggest and first item on your list.

        • Darkassassin07@lemmy.ca
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          2
          ·
          7 months ago

          A well implemented password also cannot be stolen. Only a hash of that password.

          Presuming it was hashed before transmission which it often is not. It can still be stolen during transit, directly from the user, or from poorly implemented processing/storage practices on part of the service which you have no control over and no ability to audit. You can have all the best practices as a user, and still be screwed over by a services poor practices.

          Passkeys guarantee to reduce this to a single possible target of theft: The users device.

          You as a user have no control or even insight into how a service implements password based auth. All you can do is use a unique complex password and hope they do the right things to keep it secure. Just by using a passkey though, you can know for sure that you are in control of it being kept secure as it never leaves your possession.

          Biometric auth is only used to secure the keys on the local device, ontop of the devices own auth.

          By MFA, I was refering to all the other factors you can apply just like typical password+2fa. Email, sms, timed, physical key, etc. You have all of the same additional options ontop of replacing passwords with a more secure option. I’m not saying bio+passkey is MFA. Bio is used to access the passkey then MFA is applied to the service itself through whatever other means you’ve enabled. Hell, you can use your password as the secondary MFA option if the service has enabled that.

          • Saik0A
            link
            fedilink
            English
            arrow-up
            2
            arrow-down
            3
            ·
            7 months ago

            It can still be stolen during transit, directly from the user, or from poorly implemented processing/storage practices on part of the service which you have no control over and no ability to audit.

            All of the same concerns exist with passkeys. Worse though is that with passkeys you cannot audit yourself them at all, they’re locked away and have no ability to be viewed at all. You actually can’t tell if the passkey you “Deleted” was actually removed… Nor if a new one that you create to take it’s place is actually different than that one you just “deleted”.

            Passkeys guarantee to reduce this to a single possible target of theft: The users device.

            Which you as a user, if you implement password properly (one unique password per service) also have the same quality. Except you don’t have to rely on now a single possible target! If you steal my device, you have no hope of getting access to my accounts. Period.

            You as a user have no control or even insight into how a service implements password based auth.

            You don’t have any control over passkeys either…

            All you can do is use a unique complex password and hope they do the right things to keep it secure.

            Same as passkeys. Except now your hope is that your system AND their system keeps the passkeys properly secure.

            Just by using a passkey though, you can know for sure that you are in control of it being kept secure as it never leaves your possession.

            You actually have no idea about this… since different standards can exist at the browser or implementation level that can do whatever they want with the keys. Case and point is that Apple allows you to migrate your passkeys through iCloud. Either they’re using your private to authorize a new private key, or they’re actually physically moving your private key to a new device. In either case, that already disproves that “it never leaves your possession” since a cloud service can move it for you.

            • Darkassassin07@lemmy.ca
              link
              fedilink
              English
              arrow-up
              3
              arrow-down
              3
              ·
              edit-2
              7 months ago

              All of these points only apply if you don’t pick a decent password/passkey manager and just stick with whatever google/apple gives you.

              Do better.

              I can see all my Passkeys in painstaking detail and know exactly what has or has not been deleted/modified. I use my own self-hosted services for managing them between devices, so they are never stored on anything but my own hardware in my control.

              The only part that leaves my possession is the public key portion of each passkey, which honestly could be published to a list on their homepage and still remain secure.

              Here’s an example of a stored passkey, but with values redacted:

              "fido2Credentials": [ { "credentialId": "-redacted-", "keyType": "public-key", "keyAlgorithm": "ECDSA", "keyCurve": "P-256", "keyValue": "-redacted-", "rpId": "amazon.ca", "userHandle": "-redacted-", "counter": "0", "rpName": "Amazon", "userDisplayName": "-redacted-", "discoverable": "true", "creationDate": "-redacted-" } ]

              • Saik0A
                link
                fedilink
                English
                arrow-up
                2
                arrow-down
                2
                ·
                edit-2
                7 months ago

                All of these points only apply if you don’t pick a decent password/passkey manager and just stick with whatever google/apple gives you.

                Oh yeah? So on Android… How do you get your password manager to work for your passkey storage? Because all I see on android is NFC, USB, and “This device” (which is literally google storage, not your own app). So how do you login to any apps that you’re using passkeys on your phone?

                Do better.

                LMFAO, you’ve addressed basically nothing and assume that your answers are sufficient you can fuck right off.

                Edit: This is effectively SSL/TLS… Right? So there’s never been a successful attack on that right? Boy do I have a bridge to sell you.

                • Darkassassin07@lemmy.ca
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  arrow-down
                  1
                  ·
                  7 months ago

                  Currently I only use passkeys on desktop while I patiently wait for my password/passkey manager of choice to finish implementing passkey support on Android, just as I’m waiting for most services themselves to implement passkey support in general. It’s a relatively new and emerging technology, adoption always takes time.

                  When you don’t put any thought into what you’re using and just stick with the defaults you’re given; you’re obviously not going to have an optimal experience. Hence: Do better.

                  No, this is not basically TLS/SSL. TLS/SSL convinces a client to use a key they’ve just been given, via a public chain of trust that can be manipulated in many ways. This is more akin to the public key authentication of an SSH connection; where the keys are known and trusted long before the connection where they are used is established. This is then also wrapped in TLS/SSL as an additional layer. But TBH as long as you don’t pass persistent login tokens back/fourth, it could be done over plain http. (it wouldn’t secure the data then ofc, but would still securely prove your identity across that connection)

                  • Saik0A
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    arrow-down
                    1
                    ·
                    7 months ago

                    When you don’t put any thought into what you’re using and just stick with the defaults you’re given; you’re obviously not going to have an optimal experience. Hence: Do better.

                    And yet here we are… you can’t use it the way you want even if you wanted to. And have no guarantee that that functionality will ever be supported on your platform. Yet you’re saying “do better” when better literally cannot be done.

                    via a public chain of trust

                    You do not understand TLS/SSL then. Public chain of trust is not a requirement. You can import and trust whatever cert you want. And there’s been a history of attacks SPECIFICALLY doing that.

                    This is then also wrapped in TLS/SSL as an additional layer.

                    Which password auth is at this point on the internet as well… yet in previous posts you made it out like passwords are sent over the clear and are sniffable by the whole world.

        • Darkassassin07@lemmy.ca
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          1
          ·
          7 months ago

          Saw your edit:

          It was an example list of companies that allow MFA alongside passkeys, not a list of people with perfect practices. You seemed to think MFA wasn’t even a possibility.

          Every company implements things differently. Google establishes ‘trust’ once you’ve signed into a device and doesn’t ask for 2fa after that. It’ll usually prompt you for it on any new-to-your-account device.

          Regardless, that’s issue with googles implementation of Passkeys, not Passkeys themselves.