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.
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.
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.
“I argue this is actually more convenient, but some people (esp. young people?) have an aversion to email which i don't understand.”
Uhaul does this and it’s maybe the only good I can say about Uhaul. I think the catch is that some people don’t use email (or much of anything) on their mobile phones. Most will get sms immediately wherever they are at. Not everyone uses email that way.
Emailing backup codes doesn't sound like a good idea. You give the keys to the kingdom to email provider or anyone who would be able to access your mailbox.
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.
Maybe for some irrelevant social media site I can understand doing password-only auth because who cares, but this has your DNA on it. Even if the person who has all their personal information leak doesn't care, they fucked over their entire family. I guess that's not 23andMe's fault though because they were just satisfying a rational user aversion!
Not only that, but the aversion to using methods of logon other than passwords are less rooted in passwords being easy, and more in passwords being STANDARD. Passkeys for instance are faster to use than passwords. The ONLY thing that makes passwords "Easy" is peoples refusal to start using something better because of one-time switching costs and inertia.
Plastic cups and discarded napkins also have DNA on them, and yet most people are willing to leave those lying on the table in an airport food court. If an entire family gets "fucked over" by this leak, they're going to get...medically invasive spam?
Which is bad, obviously, but I think everyone is catastrophising it.
Google can do a lot that no one else can. Think of user conversion rates if you require that they install an app and set up some TOTP stuff some never heard about just to access your platform.
Google’s standpoint likely saved many from identity theft given how getting access to the average person’s Google account can compromise half the services they have or more if they’re using gmail.
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.
> 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.
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
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.
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.
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.
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.
... 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.
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.
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.
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.
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.
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
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... but I don't really feel like doing that.