Genetic testing company 23andMe said Monday that hackers were able to access the data of about 6.9 million people, far more than the company previously acknowledged.

The finding is the result of an investigation 23andMe launched in October, after at least one list of people whom the site identified as having Ashkenazi Jewish ancestry was posted online.

    • Danny M@lemmy.escapebigtech.info
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      1 year ago

      that has nothing to do with it, you just give each user a private key, and in order to view the data you need the key, simple as that, in fact it’s even simpler for a user, no passwords to remember

      • atzanteol@sh.itjust.works
        link
        fedilink
        arrow-up
        4
        ·
        1 year ago

        that has nothing to do with it

        Wut? You mentioned “encryption” over and over (#encryptionplease) and now it “has nothing to do with that?”

        you just give each user a private key, and in order to view the data you need the key, simple as that

        You’re expecting people to download a GPG encrypted file, handle key maintenance, and offline decrypt it for viewing? And not store the decrypted data on their drives? Almost nobody would be willing to do that. And it’s not necessary.

        WebAuthn or MFA would have helped in this situation and are far easier for end-users to use properly.

        • Danny M@lemmy.escapebigtech.info
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          1 year ago

          Wut? You mentioned “encryption” over and over (#encryptionplease) and now it “has nothing to do with that?”

          I’m saying that the fact that they accessed the data through compromised accounts is irrelevant. If the data was properly encrypted and only decrypted on the user’s machine with the key.

          You’re expecting people to download a GPG encrypted file, handle key maintenance, and offline decrypt it for viewing? And not store the decrypted data on their drives? Almost nobody would be willing to do that. And it’s not necessary.

          You made a lot of assumptions there.

          I’m not really familiar with the entire process of how 23AndMe but based on what the service is I assume that they ship you a box with a vial or maybe a swab to collect saliva, then include a code, maybe a qr code or a redemption id that you can use to register on their website.

          The packaging could very easily include a QR code with an RSA or EDCSA key, then the website could ask you to scan that QR code to login.

          The website would then use that to calculate the public key based on that private key and make a request to the server for the data associated with that public key, then the user’s browser would decrypt that data and display it

          What exactly is the problem here? If anything it’s simpler than username/password from a user standpoint.

          And as for WebAuthn, yeah that would work and it’s definitely better than a password, and would perhaps solve part of the issue, but as a user I would feel much safer with my implementation

          • atzanteol@sh.itjust.works
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            I’m saying that the fact that they accessed the data through compromised accounts is irrelevant. If the data was properly encrypted and only decrypted on the user’s machine with the key.

            It was encrypted and only decrypted on the user’s machine. It’s called TLS.

            You made a lot of assumptions there.

            Well of course I did - all you said was “use encryption” like that meant anything specific.

            Your proposed solution has lots of problems and isn’t materially more secure than properly implementing WebAuthn or even requiring MFA. All you’ve added is a public/private key authentication which is what WebAuthn does.

            You also need a solution for lost keys, using multiple browsers, etc. or nobody will use it. This is also being provided by WebAuthn.

            The problem here is not “encryption” it’s “properly identifying who should have access to the data.” It’s an authentication problem. The data was encrypted from the servers to the browser in a secure manner. At issue here is account security and authentication.

            To be clear - you solution would “work” but without the above issues addressed nobody will use it because it will be a giant pain in the ass. It’s not like we don’t know how to share data securely, it’s that doing so is complicated and often relies on users to be sophisticated about security. They’re your weakest link so you need a system that:

            1. Is secure
            2. Users will use
            3. Can easily be used correctly by unsophisticated users and
            4. Is easy to automate (not manually generating and handing out keys, etc.)

            And this is what WebAuthn promises.

            And as for WebAuthn, yeah that would work and it’s definitely better than a password, and would perhaps solve part of the issue,

            It only has to solve part of the issue. The end-to-end encryption is covered with TLS.

            I don’t see what your solution would do that isn’t covered by existing tech. And it would require a lot of new protocols to be put in place, support by major browsers, good user interfaces, etc.

            • Danny M@lemmy.escapebigtech.info
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              1 year ago

              It was encrypted and only decrypted on the user’s machine. It’s called TLS.

              How is TLS relevant in this discussion? In this specific case TLS only solves MiTM, that’s it.

              Well of course I did - all you said was “use encryption” like that meant anything specific.

              It was an offhand comment in a lemmy post, of course I’m not gonna go into details… but fair enough

              […] isn’t materially more secure than properly implementing WebAuthn or even requiring MFA.

              This is a bit disingenuous, don’t you think? To be clear I like WebAuthn, I think it’s a great technology that I’ve been evangelizing about it to coworkers and friends for years, it’s definitely the future of authentication, but that’s only marginally relevant, in the case of sensitive data like this you want the data to be both encrypted at rest and during transmission, with a unique pre-generated key, otherwise a rogue employee or in general someone with access to the database can see everything, regardless of anything else.

              • atzanteol@sh.itjust.works
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                How is TLS relevant in this discussion? In this specific case TLS only solves MiTM, that’s it.

                “If the data was properly encrypted and only decrypted on the user’s machine with the key.”

                TLS is “encryption” that is “only decrypted on the user’s machine with [a] key”. I feel like I’m completely misunderstanding what sort of protocol you have in mind though.

                [re: WebAuthn] but that’s only marginally relevant,

                This breach was a failure of authentication via reused passwords. It’s the exact scenario WebAuthn is designed to mitigate. I have no idea how you could consider it to be “marginally relevant”.

                in the case of sensitive data like this you want the data to be both encrypted at rest and during transmission, with a unique pre-generated key, otherwise a rogue employee or in general someone with access to the database can see everything, regardless of anything else.

                I don’t know what you mean. Just that the database should be encrypted (I have no reason to believe it wasn’t) or that the company should encrypt the data such that the only person who can view it at all is the person whose account it is for?