8 ms·

I guess one question is: should > did not have 2fa enabled be allowed to coexist with > pretty extensive and personal data

ApolloFortyNine 3y ago
It's the user's data, its not on 23andme to baby the user. If the user wants to trade ease of login with risk of getting hacked, that's not 23andme's fault.
- wilg 3y ago
  Passkeys, baby!
  - keep_reading 3y ago
    Try convincing all the anti-passkey folks first
  - rkagerer 3y ago
    Give me an implementation I can self-host, without Google, Apple, etc. having effective control (including claws in my relevant software supply chain) and with an easy user experience, where I can maintain secure backups (on my own infrastructure, thank you) and smooth transition to future devices, and ideally, if needed, securely export root keys (cause if I don't control them then someone else owns them), and maybe I'll be interested. In the meantime plain old high-entropy passwords with a good manager gives me all those features and a simplicity that's hard to beat. In my 30+ years of computing I've suffered more harm from failures of other companies than I have from any failure of my own diligence. The whole lesson learned is to reduce trust in them and, maybe I'm wrong, but everything I've read about passkeys and the like seems to put me at liberty of the companies developing and pushing the implementations of them down my throat. It will take a lot of trust before I give up my ability to copy/paste my credentials.
    - elabajaba 3y ago
      Keepassxc and bitwarden should both be getting support for passkeys soon. Bitwarden sometime in October (vaultwarden already has support for storing them), keepassxc there's been an open PR for it that's been tested and iterated on for awhile, but I'm not 100% sure how close it is to landing.
      - rkagerer 3y ago
        Thanks! Last time I checked it out the top hit said "Closed as Not Planned". Could you point me to some good details or any article on how it's being implementef (e.g. does it act as a third-party store or something to avoid being locked behind a TPM or whatnot?). Genuinely interested.
        elabajaba 3y ago
        I'm not sure about any specifics beyond that both are getting support for them (for the keepass ecosystem I'm sure about other mobile clients, but I don't think the feature request to support passkeys has been acknowledged by the keepass2android dev sadly). Here's the keepassxc PR with some details about the implementation, and what should be done in future work on passkey support: https://github.com/keepassxreboot/keepassxc/pull/8825 https://github.com/keepassxreboot/keepassxc/pull/8825 Bitwarden has a few blogs if you search for bitwarden passkeys, but from skimming one it didn't seem to go into technical details (though I didn't watch the videos). I guess you could look through the PRs: https://github.com/bitwarden/clients/pulls?q=is%3Apr+passkey+is%3Aclosed https://github.com/bitwarden/clients/pulls?q=is%3Apr+passkey... but I don't really feel like doing that.
- jonny_eh 3y ago
  > that's not 23andme's fault Yes it is. It's their fault for giving the user a choice. Google requires (some) users to enable 2FA, why can't 23andme? https://www.tomsguide.com/news/google-forcing-2fa-users https://www.tomsguide.com/news/google-forcing-2fa-users
  - strken 3y ago
    Because user aversion to 2FA is often rational. The expected cost of learning how to use 2FA plus risking losing access to your account and not being able to get it back through support is often higher than the cost of having your account compromised.
    - coding123 3y ago
      But that's only because companies, like google, offer no human support for lost accounts. Somehow I wonder if 100 years from now personal data will be handled by something like a bank. If you lose your password you call your personal data bank - which can get you back online or something like that. Maybe that's the next big thing - local, personal companies that are your "online power of attorney" that have the right to reset your shit, make claims about your identity. I have no idea. But the current state of things is just a mess.
      - 2devnull 3y ago
        It won’t be your bank, it will be google. To some extent it already is.
    - syndicatedjelly 3y ago
      I really hope this is not the prevailing attitude in software security.can someone from that field please chime in?
    - chii 3y ago
      > user aversion to 2FA is often rational. The account recovery process should be setup at the start of the 2FA setup - e.g., you get emailed a bunch of backup codes (easiest way imho). The site should not be using their own 2FA app, but use a standard OTP implementation, and let the user use their own OTP app (most people default to google's authy, but there's a couple out there that are common too). Or, as an alternative, delegate the login to email and use a password-less login mechanism (effectively delegating the account security to the email's security). I argue this is actually more convenient, but some people (esp. young people?) have an aversion to email which i don't understand.
- toofy 3y ago
  if they’re hosting sensitive data, it isn’t “babying” the user to take some responsibility for the data your company exists on. if they can’t take responsibility for it, then they’re too irresponsible to make money it. it would be entirely reasonable for them to say “we don’t want anything to do with this data, we don’t want to profit from it, we don’t want to use it in anyway, therefor we will not retain it at all.” babying the user by taking responsibility for the very data they profit from? unreal.
  - ipaddr 3y ago
    Checkout the data in the screenshot. This is not sensitive data. Pretty useful data.
    - toofy 3y ago
      > The information that has been exposed from this incident includes full names, usernames, profile photos, sex, date of birth, genetic ancestry results, and geographical location. i would absolutely argue that having my 1) genetic ancestry, 2) full name, 3) date of birth, etc… is sensitive information. even removing genetic information, if a company is too irresponsible to catch millions of users info being stolen, then they’re too irresponsible to have that data. again, either it’s important to your business or it isn’t. if it isn’t important, then refuse to store it.
      - ipaddr 3y ago
        Birthdate/name is not sensitive data nor is a public profile photo. Facebook will display this in a public profile. And you are not getting genetic data. This info is public in other dna sites even if it's private on 23andme
- jchw 3y ago
  It's not always that clear cut, though; after all, wouldn't this argument apply to e.g. laws requiring seatbelts? One could argue that in this early-ish stage of electronic data, vendors that hold very sensitive data are being irresponsible. Not just about not requiring more secure authentication, but also for pushing less secure authentication like SMS-based authentication factors.
  - KRAKRISMOTT 3y ago
    The car makes an annoying beep beep sound, but it doesn't force the user to use a seatbelt. The onus and responsibility is ultimately on the end user.
    - jchw 3y ago
      The inability of the car to safely enforce this is probably the main reason why this works this way. The responsibility is split, though: cars are required to be designed in ways that discourage or prohibit some unsafe behaviors entirely. Not too different from services requiring 2FA: doesn't mean the TOTP secret is necessarily stored safely.
      - ImPostingOnHN 3y ago
        A friend of mine rented a larger, newer Jeep SUV when in town. It would not go into gear unless seatbelts were buckled. It was awful - not a future I want to live in. I'd rather have the choice than have it made for me in the name of safety. > Not too different from services requiring 2FA That is another practice I find awful for the above reason.
        serf 3y ago
        Another underlying problem with that kind of gatekeeping are the dangerous scenarios that can happen when the Jeep decides erroneously not to start due to a sensor anomaly. It's a virtue that a car continues to operate when all the warning signs and buzzers are going off; this means that the human in charge is left in ultimate control of the situation and there doesn't need to be any complex umbrella structuring of liability -- this allows a driver to safely drive away from a dangerous tidal wave/assault/lava flow/whatever even if their seat belt sensor is broken ; this is very important for numerous reasons.
- Clamchop 3y ago
  This stance is reckless and negligent. Pragmatically, you can be found liable. Ethically, it's cut and dried.
  - ApolloFortyNine 3y ago
    ... Do you really believe this? There's countless services out there that don't require 2fa by default. Honestly it's probably easier to list the ones that do. If you think that means the company can be held liable, I'd honestly start leaking my information on the internet if I were you. You have millions of dollars of lawsuits to go win apparently.
    - Clamchop 3y ago
      I absolutely believe this. If you think your service shall perform no due diligence that it is correct, accurate, and safe, then you have no business providing it to the user, who has little or no knowledge of the domain, which you are selling to them. That is your job, to sell a sophisticated service to someone who would enjoy the benefits but cannot begin to do it for themselves. If you don't think so, then I think you're beyond reprehensible, and so will the courts. There is no disclaimer that can protect you. Good gravy, this is the easy part.

ApolloFortyNine 3y ago

It's the user's data, its not on 23andme to baby the user. If the user wants to trade ease of login with risk of getting hacked, that's not 23andme's fault.

wilg 3y ago
Passkeys, baby!
- keep_reading 3y ago
  Try convincing all the anti-passkey folks first
- rkagerer 3y ago
  Give me an implementation I can self-host, without Google, Apple, etc. having effective control (including claws in my relevant software supply chain) and with an easy user experience, where I can maintain secure backups (on my own infrastructure, thank you) and smooth transition to future devices, and ideally, if needed, securely export root keys (cause if I don't control them then someone else owns them), and maybe I'll be interested. In the meantime plain old high-entropy passwords with a good manager gives me all those features and a simplicity that's hard to beat. In my 30+ years of computing I've suffered more harm from failures of other companies than I have from any failure of my own diligence. The whole lesson learned is to reduce trust in them and, maybe I'm wrong, but everything I've read about passkeys and the like seems to put me at liberty of the companies developing and pushing the implementations of them down my throat. It will take a lot of trust before I give up my ability to copy/paste my credentials.
  - elabajaba 3y ago
    Keepassxc and bitwarden should both be getting support for passkeys soon. Bitwarden sometime in October (vaultwarden already has support for storing them), keepassxc there's been an open PR for it that's been tested and iterated on for awhile, but I'm not 100% sure how close it is to landing.
    - rkagerer 3y ago
      Thanks! Last time I checked it out the top hit said "Closed as Not Planned". Could you point me to some good details or any article on how it's being implementef (e.g. does it act as a third-party store or something to avoid being locked behind a TPM or whatnot?). Genuinely interested.
      - elabajaba 3y ago
        I'm not sure about any specifics beyond that both are getting support for them (for the keepass ecosystem I'm sure about other mobile clients, but I don't think the feature request to support passkeys has been acknowledged by the keepass2android dev sadly). Here's the keepassxc PR with some details about the implementation, and what should be done in future work on passkey support: https://github.com/keepassxreboot/keepassxc/pull/8825 https://github.com/keepassxreboot/keepassxc/pull/8825 Bitwarden has a few blogs if you search for bitwarden passkeys, but from skimming one it didn't seem to go into technical details (though I didn't watch the videos). I guess you could look through the PRs: https://github.com/bitwarden/clients/pulls?q=is%3Apr+passkey+is%3Aclosed https://github.com/bitwarden/clients/pulls?q=is%3Apr+passkey... but I don't really feel like doing that.
jonny_eh 3y ago
> that's not 23andme's fault Yes it is. It's their fault for giving the user a choice. Google requires (some) users to enable 2FA, why can't 23andme? https://www.tomsguide.com/news/google-forcing-2fa-users https://www.tomsguide.com/news/google-forcing-2fa-users
- strken 3y ago
  Because user aversion to 2FA is often rational. The expected cost of learning how to use 2FA plus risking losing access to your account and not being able to get it back through support is often higher than the cost of having your account compromised.
  - coding123 3y ago
    But that's only because companies, like google, offer no human support for lost accounts. Somehow I wonder if 100 years from now personal data will be handled by something like a bank. If you lose your password you call your personal data bank - which can get you back online or something like that. Maybe that's the next big thing - local, personal companies that are your "online power of attorney" that have the right to reset your shit, make claims about your identity. I have no idea. But the current state of things is just a mess.
    - 2devnull 3y ago
      It won’t be your bank, it will be google. To some extent it already is.
  - syndicatedjelly 3y ago
    I really hope this is not the prevailing attitude in software security.can someone from that field please chime in?
  - chii 3y ago
    > user aversion to 2FA is often rational. The account recovery process should be setup at the start of the 2FA setup - e.g., you get emailed a bunch of backup codes (easiest way imho). The site should not be using their own 2FA app, but use a standard OTP implementation, and let the user use their own OTP app (most people default to google's authy, but there's a couple out there that are common too). Or, as an alternative, delegate the login to email and use a password-less login mechanism (effectively delegating the account security to the email's security). I argue this is actually more convenient, but some people (esp. young people?) have an aversion to email which i don't understand.
toofy 3y ago
if they’re hosting sensitive data, it isn’t “babying” the user to take some responsibility for the data your company exists on. if they can’t take responsibility for it, then they’re too irresponsible to make money it. it would be entirely reasonable for them to say “we don’t want anything to do with this data, we don’t want to profit from it, we don’t want to use it in anyway, therefor we will not retain it at all.” babying the user by taking responsibility for the very data they profit from? unreal.
- ipaddr 3y ago
  Checkout the data in the screenshot. This is not sensitive data. Pretty useful data.
  - toofy 3y ago
    > The information that has been exposed from this incident includes full names, usernames, profile photos, sex, date of birth, genetic ancestry results, and geographical location. i would absolutely argue that having my 1) genetic ancestry, 2) full name, 3) date of birth, etc… is sensitive information. even removing genetic information, if a company is too irresponsible to catch millions of users info being stolen, then they’re too irresponsible to have that data. again, either it’s important to your business or it isn’t. if it isn’t important, then refuse to store it.
    - ipaddr 3y ago
      Birthdate/name is not sensitive data nor is a public profile photo. Facebook will display this in a public profile. And you are not getting genetic data. This info is public in other dna sites even if it's private on 23andme
jchw 3y ago
It's not always that clear cut, though; after all, wouldn't this argument apply to e.g. laws requiring seatbelts? One could argue that in this early-ish stage of electronic data, vendors that hold very sensitive data are being irresponsible. Not just about not requiring more secure authentication, but also for pushing less secure authentication like SMS-based authentication factors.
- KRAKRISMOTT 3y ago
  The car makes an annoying beep beep sound, but it doesn't force the user to use a seatbelt. The onus and responsibility is ultimately on the end user.
  - jchw 3y ago
    The inability of the car to safely enforce this is probably the main reason why this works this way. The responsibility is split, though: cars are required to be designed in ways that discourage or prohibit some unsafe behaviors entirely. Not too different from services requiring 2FA: doesn't mean the TOTP secret is necessarily stored safely.
    - ImPostingOnHN 3y ago
      A friend of mine rented a larger, newer Jeep SUV when in town. It would not go into gear unless seatbelts were buckled. It was awful - not a future I want to live in. I'd rather have the choice than have it made for me in the name of safety. > Not too different from services requiring 2FA That is another practice I find awful for the above reason.
      - serf 3y ago
        Another underlying problem with that kind of gatekeeping are the dangerous scenarios that can happen when the Jeep decides erroneously not to start due to a sensor anomaly. It's a virtue that a car continues to operate when all the warning signs and buzzers are going off; this means that the human in charge is left in ultimate control of the situation and there doesn't need to be any complex umbrella structuring of liability -- this allows a driver to safely drive away from a dangerous tidal wave/assault/lava flow/whatever even if their seat belt sensor is broken ; this is very important for numerous reasons.
Clamchop 3y ago
This stance is reckless and negligent. Pragmatically, you can be found liable. Ethically, it's cut and dried.
- ApolloFortyNine 3y ago
  ... Do you really believe this? There's countless services out there that don't require 2fa by default. Honestly it's probably easier to list the ones that do. If you think that means the company can be held liable, I'd honestly start leaking my information on the internet if I were you. You have millions of dollars of lawsuits to go win apparently.
  - Clamchop 3y ago
    I absolutely believe this. If you think your service shall perform no due diligence that it is correct, accurate, and safe, then you have no business providing it to the user, who has little or no knowledge of the domain, which you are selling to them. That is your job, to sell a sophisticated service to someone who would enjoy the benefits but cannot begin to do it for themselves. If you don't think so, then I think you're beyond reprehensible, and so will the courts. There is no disclaimer that can protect you. Good gravy, this is the easy part.