DNA companies should receive the death penalty for getting hacked

[-] Darkassassin07@lemmy.ca 67 points 6 months ago* (last edited 6 months ago)

Maybe you shouldn't use the same user+pass across dozens of different services then.

The data from 23 and Me was stolen using the legitimate login credentials of users acquired from an entirely different services data breach. Not via their own lax security policies.

You can't expect a corporation to protect you from yourself. And they certainly shouldn't be punished for your ineptitude.

Don't get me wrong, these corporations are not your friends, and shouldn't be trusted implicitly; but you have some responsibilities too.

/edit:

But when the chips are down and our data is leaked, they hide behind the old “we were not hacked; it was the users’ old passwords” excuse.

This logic is equivalent to a bank saying, “It’s not our fault your money got stolen; you should have had a better lock on your front door.” It’s unacceptable and a gross abdication of responsibility.

I completely disagree with this point. The service obviously has to provide you with access to your information/account. If you give out your login credentials for that access to a third party (another service), that third party loses your information, and it's then used to access stuff posing as you. That's your fault. You should not have shared (re-used) those same login credentials with others.

[-] bandario@lemmy.dbzer0.com 22 points 6 months ago

You nailed it. Users cannot be trusted to not re-use login credentials.

I know we all hate it, but proper 2-factor authentication via authenticator apps must be the default position for everything.

[-] chatokun@lemmy.dbzer0.com 1 points 6 months ago

I work in IT and don't want to have to use annoying long passwords, so I've been team mfa for at least a decade now. I had physical code devices for SWOTR and FFXIV until I got a software one for the latter. I don't play the former much but I still have a working physical key somewhere.

In fact, I'm more annoyed when a service still uses texting your phone and no option to use a mfa app.

[-] Rinox@feddit.it 21 points 6 months ago

Well they should have 2fa, but yes, if that's the case I agree with you.

Use Bitwarden or KeePass

[-] Darkassassin07@lemmy.ca 12 points 6 months ago* (last edited 6 months ago)

Unfortunately, even that's not enough. That's often a user choice to enable, and otp itself is a flawed system. (be that email, sms, or timed)

Really, services should be transitioning to Passkeys, however adoption of a new standard always takes time. There are not a huge number of services that have implemented them yet. Here's a list

[-] YoorWeb@lemmy.world 13 points 6 months ago

While a one-time passcode can be lost or stolen, nobody can steal your face.

[-] Appoxo@lemmy.dbzer0.com 9 points 6 months ago

TOTP is better than no TOTP/2FA.

[-] Darkassassin07@lemmy.ca 1 points 6 months ago

It sure is. My point is that users often don't enable 2fa even when available, while those that do are still at risk anyway.

Id rather see a much less flawed system implemented, particularly for important services like ones that store your genetic code.

[-] PowerCore7@lemm.ee 4 points 6 months ago

The first link is basically an "advertisment hidden in a normal, professional-looking article". All they're saying is how these ways are not secure, but most importanly, how their solution is more secure, published under their own site.

When you take this into account, their claims start to break down: while yes, email and SMS MFA might be inherently less secure since the code could be transmitted via an insecure channel, saying TOTP is not not secure because "you device can be hacked" is a kinda bad take: if your device is already hacked, you'd have a much bigger problem: even if you are using security keys, the hacker would already have access to whatever service you might be trying to protect. As for the lost/stolen case mentioned in the article, if you put TOTP code in a password manager (as most would probably do if they're doing this), that shouldn't be a problem. The only way this would be a problem is that the TOTP secret is stored in plain text, which would be the same for any authentication methods.

[-] Rinox@feddit.it 3 points 6 months ago

Thanks for the link, I wanted to read up on passkeys since the other day, as GitHub asked me to set one up with Bitwarden

[-] starman2112@sh.itjust.works 1 points 6 months ago* (last edited 6 months ago)

I don't like passkeys. There's the old thing about good security being the thing you have, the thing you know, and the thing you are–a key, a password, and biometrics. I don't like keys or biometrics for anything online. Mainly because of 5th amendment issues (police can hold your finger to your phone to unlock it, but they cannot compell you to say what your password is), but also because either it's more secure than using a password (if you lose the thing you have, you're fucked) or it's the same as using a password (if you lose the thing you have, you can enter a password to get it back).

Why can't we just normalize memorizing complex passwords? It isn't that hard if you dedicate some effort to it instead of lazily making it Currentmonth123!$

[-] Rinox@feddit.it 6 points 6 months ago

Why can't we just normalize memorizing complex passwords? It isn't that hard if you dedicate some effort to it instead of lazily making it Currentmonth123!$

This is just a stupid take. I bet you either reuse your passwords regularly or you don't really use the internet that much. I just looked it up and I have 270 unique logins, with as many 20 characters long passwords, with letters numbers and special characters.

Now tell me with a straight face that you think everyone can memorize that.

load more comments (1 replies)

[-] Darkassassin07@lemmy.ca 4 points 6 months ago* (last edited 6 months ago)

I currently have 75 different accounts stored, each with a unique 16 character randomized password. My memory cannot handle remembering each one alongside their username and which service they are used for. I don't think it's reasonable to expect anyone to.

You are not required to secure passkeys with biometrics, you can just use a password to encrypt them if you want, removing the possibility of forced unlock.

With that many logins, I use a password manager anyway. Regardless of whether I use passwords or passkeys; that is always going to be target. With passkeys, that manager+my device are only possible targets to gain access to my accounts. With passwords every service is also a target, along with every connection I make to that service.

A random example: If I login to twitter with a password using a work computer, that password is more than likely now sitting in a log file on the corporate firewall that performs https inspection. That could be used to gain access to my account later.

Replace that password with a passkey, and now there's no ability to harvest and use login info from those logs. All they saw was the passkey challenge and response sent back/fourth with no ability to replicate it later.

While yes, you can usually recover you passkeys with a password and the appropriate access to the systems where they are backed up; the difference is very rarely using a password as a recovery code, vs using a password regularly giving much more opportunity for it to be intercepted or mishandled. The systems my password manager backs up to are also my own and not publicly accessible. (you don't have to use google/apples managers)

Also the passwords used for account auth are stored in my password manager, where as my password managers password is only stored in my mind. One is easy to remember, 75 is a bit much...

[-] Saik0Shinigami@lemmy.saik0.com -1 points 6 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 1 points 6 months ago* (last edited 6 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.

[-] Saik0Shinigami@lemmy.saik0.com 3 points 6 months ago* (last edited 6 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 2 points 6 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.

[-] Saik0Shinigami@lemmy.saik0.com -1 points 6 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 0 points 6 months ago* (last edited 6 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-" } ]

[-] Saik0Shinigami@lemmy.saik0.com 0 points 6 months ago* (last edited 6 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 0 points 6 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)

[-] Saik0Shinigami@lemmy.saik0.com 0 points 6 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 0 points 6 months ago

A new tech has not yet been adopted everywhere yet so we should abandon it entirely? That's quite the take.

Patience my friend. Good things come in time.

Yes, TLS/SSL is flawed. Again: no, this is not an implementation of TLS/SSL.

No, I've not implied passwords are sent over open channels. I've said their transmission -at all- is a bad thing (which they have to be to be used), regardless of being wrapped in TLS/SSL.

Copy/paste from another conversation:

A random example: If I login to twitter with a password using a work computer, that password is more than likely now sitting in a log file on the corporate firewall that performs https inspection. That could be used to gain access to my account later.

Replace that password with a passkey, and now there's no ability to harvest and use login info from those logs. All they saw was the passkey challenge and response sent back/fourth with no ability to replicate it later.

(How I got the passkey onto a work computer is separate discussion, point is the example of collecting your password via a malicious network connection. This can happen in more than just a work environment)

[-] Saik0Shinigami@lemmy.saik0.com 0 points 6 months ago

A new tech has not yet been adopted everywhere yet so we should abandon it entirely? That’s quite the take.

No, it offers nothing that cannot be done with current implementations of passwords/password managers. That's the take. You're just obtuse and unable to answer how your precious passkeys is actually better in any form.

Again: no, this is not an implementation of TLS/SSL.

It's literally what it is... It's what industry experts directly call it. Public/Private keys... That's all this is... that's literally how TLS/SSL works.

I’ve said their transmission -at all- is a bad thing (which they have to be to be used)

They don't... because well implemented passwords should only send hashes... Which we've already established that passkey implementation is also problematic. You can't compare the worst implementation of passwords to best implementation of passkeys. That is disingenuous. Nothing about passkeys forces a website to implement things "properly", just like they don't have to for passwords.

A random example: If I login to twitter with a password using a work computer, that password is more than likely now sitting in a log file on the corporate firewall that performs https inspection. That could be used to gain access to my account later.

Doesn't stop MitM, doesn't stop corporate firewall from capturing the session cookie and utilizing that to replay access to your account. Assumes that the challenge and response are implemented so that it's not guessable nor repeated... Keep in mind, we can hash/salt passwords in a multitude of ways, which can be used to vary the "response" of a password as well.

How I got the passkey onto a work computer is separate discussion, point is the example of collecting your password via a malicious network connection.

But it's not. If I want to login on a work computer with a password. I can just type the damn thing in. Passkeys are simply LESS mobile... and carry more risk as you're now authorizing a specific machine to have permissions indefinitely rather than having sessions that defacto expire and that's it.

But let's actually reign this in a bit... What are the actual beneficial claims here?

Do you agree that something like https://b-compservices.com/switching-from-passwords-to-passkeys/ encompasses all of it?

It’s a bit more tricky to attack than a password

Can accomplish the same thing with passwords that they claim passkey can do. Whether someone implements it that way is a different problem. But it's possible.

Improves cybersecurity strategy

Also makes it significantly harder for companies to support users. I cannot set a passkey to a known value to let someone into their account after they lock themselves out (likely forgetting their own password).

Smooth user experience

I've had this with password managers for a decade... if not longer at this point. And it works on all my devices, so it's even more smooth!

Every passkey is strong by default

See above...

Future-proof

Anyone who says this in the context of computer security is lying from the get-go.

Convenient to use

Same as "Smooth user experience".

Lower long-term costs

Their logic here is moronic. "This includes the time IT spends dealing with the constantly changing legal requirements for password storage and password resets." Except now people will just be locked out and fucked completely. Unless they happen to use a flawed passkey implementation that allows them to recover their shit no?

[-] Darkassassin07@lemmy.ca 0 points 6 months ago

Public Key Auth =/= TLS/SSL =/= Passkeys.

TLS/SSL is one implementation of public key authentication.

Passkeys is a different implementation of public key authentication.

That fact that there are flaws in the TLS/SSL implementation of public key authentication does not equate to those flaws being present in the Passkey implementation of public key authentication.

Just because a tool was used poorly once, doesn't mean it's always used poorly.

Passwords MUST be transmitted to the service in a form that the server accepts as valid, every time authentication is requested. This can be captured and re-sent in exactly the same form it was originally sent to the server. Be that plaintext, or a hash. Hashing a password is almost always done on the server side before storage, or before comparing to the stored hash. If it was done by the client, an attacker would never need to get the plaintext password, they could just resend the hash. A passwords security in transit is entirely dependent on the security of the SSL/TLS connection, which we've already discussed is flawed.

A passkey is never transmitted and thus cannot be stolen from that transmission. They are not dependent on the security of a known to be flawed network protocol.

Yes, there are other attack vectors which are present with both forms of authentication. Not really relevant to choosing one or the other being they are present regardless of password vs passkey.

Which we've already established that passkey implementation is also problematic.

The only problem we've established with passkeys is managing their storage and distribution between your devices. That's a problem that's entirely up to you as a user and which managers you choose to use. I like having detailed control over my data, so I used a self-hosted password/passkey manager. Others don't care to go into that kind of detail and just stick with google/apple. To each their own.

I'm actually doing the opposite: Compairing the best password implementations with the worst passkey implementations. (regarding how the service implements auth, not how the user manages their auth info. Ie; what the user has no control over)

Even with the user and the service they are using doing all the right things to secure their password auth as much as possible: that password can still be stolen in a usable form either from the service itself or from the connection between the service and the user.

Where as a service could fuck up astronomically; http only, with public access to their user+passkey table. As long as the users own systems have not been compromised, those passkeys cannot be stolen in any useable way as the service doesn't have them and are never sent them in any form. All you'll get is a public key which is about as useful as a random number.

Passkeys move all the risk+responsibility of keeping them secure away from the service and puts it entirely in the hands of the user and the decisions they make. You no longer have to hope or even care that the service you're connecting to is actually utilizing the best practices.

And yes, Passkeys are more inconvenient than a password. Using private key auth has always been more inconvenient. Doesn't stop it being the go-to form of auth for ssh. Again, that was just an example of your password being stolen by the network you are connected to. I'm not here to discuss how to or if you should be using personal accounts on work equipment.

I'm also not going to discuss the merits of someone elses talking points. I didn't even open that link.

[-] Saik0Shinigami@lemmy.saik0.com 0 points 6 months ago

That fact that there are flaws in the TLS/SSL implementation of public key authentication does not equate to those flaws being present in the Passkey implementation of public key authentication.

So the fact that LITERALLY EVERY public key auth up to this point in history except for a very very limited few has been broken/updated isn't a sign to you? Why are you so willfully ignorant here? NO encryption method is perfect... NO Authentication method is perfect.

TLS/SSL is one implementation of public key authentication.

Good thing everything I've talked about has been about Public Key Authentication and the traits that those have! Almost like being such a thing would have common traits between them that would not change!

Passwords MUST be transmitted to the service in a form that the server accepts as valid

Just like the challenge/response must be transmitted in a way that the server accepts it as a valid answer... Platitudes like this mean nothing and show that you do not understand any of the fundamentals happening here. Public Key Encryption is fundamentally 2 entangled passwords and a challenge (random generated known) on session start. There's 0 reason that the passwords couldn't just be an actual password for the private side, and the hash the public key. You need to read up on implementation of these things.

A passkey is never transmitted and thus cannot be stolen from that transmission. They are not dependent on the security of a known to be flawed network protocol.

I literally said this so many time already it's getting sad that you are arguing so disingenuously. You don't HAVE to transport the password at all in password-based authentication. You can transport a hash(password+challenge) just like what passkeys would be doing.

I’m actually doing the opposite: Compairing the best password implementations with the worst passkey implementations. (regarding how the service implements auth, not how the user manages their auth info. Ie; what the user has no control over)

No you're not, and now I'm walking away from this discussion. I can't have discussions with people who outright lie.

The best password implementations would do what I've outlined several times now... The worst passkey implementation could simply challenge with the same or no value at all which would allow replay (gasp! like bad implementations of passwords! almost like they are basically the same!). Like YOU admitted, you can't control the site implementation. I've said it repeatedly that the best possible passkey implementation is WORSE than the best possible Password implementation. However, the worst passkey implementation is likely better than that worse password implementation. Kneecapping those of us who actually implement properly... That's dirty.

I’m also not going to discuss the merits of someone elses talking points. I didn’t even open that link.

And you've outlined none of your own. What productive communication this has been. It's literally the same parroted talking lines that every fucking one of you "passkey" fanboys spout without any functional knowledge of what happening.

Go look at how all Public Key Encryption works. TLS is sufficient to understand it. https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

Nothing stops step 4 from being the hash of a password, step 5 being you applying your password. Literally nothing. Passkeys are not significantly different than passwords from a best implementation standpoint, and actually introduce a number of problems that passwords do not have. It's all about implementation and everyone who is lazy in implementing strong password authentication code WILL be lazy implementing PassKeys.

Others don’t care to go into that kind of detail and just stick with google/apple. To each their own.

Yeah you've already admitted that phone user's don't have a choice... and the vast majority of people's only significant interaction with the internet in a day is their phone. So where's the options for those people? Right... I've asked that like 3 times now and you've failed to answer.

[-] Darkassassin07@lemmy.ca 0 points 6 months ago

I'm tired of you putting words on my mouth and needlessly insulting me in a genuine conversation. It's just sad.

For example: I never said users dont have a choice on Android. You did.

I said my chosen Passkey manager has not yet implemented Passkey support. Nordpass, Enpass, 1password, and Dashlane are all examples of non-google passkey managers you can use right now on Android. You just couldn't be bothered to look for anything but what was stuffed in your face for you.

Enjoy your rambling, I'm done here.

[-] Darkassassin07@lemmy.ca 1 points 6 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.

[-] Doxatek@mander.xyz 54 points 6 months ago* (last edited 6 months ago)

I worked at McDonald's to be able to afford to go to college and they sold my fingerprint data. I got like 50 dollars in the mail for compensation. Always thought that was fucked. They probably made more selling it all than the settlement was. I should've gotten a lot

[-] tiny_electron@sh.itjust.works 25 points 6 months ago

I am honestly surprised you got anything at all

[-] Doxatek@mander.xyz 5 points 6 months ago

Honestly same as well

[-] sramder@lemmy.world 48 points 6 months ago

I swear this headline was just a comment the last time this got posted...

[-] Garbanzo@lemmy.world 44 points 6 months ago

This logic is equivalent to a bank saying, “It’s not our fault your money got stolen; you should have had a better lock on your front door.”

Isn't that exactly what the bank would tell you if someone stole your personal info from your home and used it to empty your account?

This author is a dumbass.

[-] starman2112@sh.itjust.works 23 points 6 months ago

It seems to me like the biggest problem was that in accessing just 14,000 accounts, they got some amount of personal information of nearly 7 million people. Less "you should have had a better lock on your front door" and more "your neighbor's cousin should have had a better lock on his front door."

[-] totallynotarobot@lemmy.world 7 points 6 months ago* (last edited 6 months ago)

And a little of the old "it's really your fault for listening to us when we said you didn't need a better lock because wE tAkE cUsToMeR pRiVaCy VeRy SeRiOuSlY."

[-] homesweethomeMrL@lemmy.world 24 points 6 months ago

The 23andMe breach saw hackers gaining access to a whopping 6.9 million users’ personal information, including family trees, birth years and geographic locations. It brings to the fore a few significant questions: Are companies really doing enough to protect our data? Should we trust them with our most intimate information?

Well . . . NO. But that has never not been the case. These fucking cheese-brained twits who pour out every scrap of personal - and genetic! - info to the tatty basket of whatever Zuckerberg their moron friends are using has been a problem from day one.

Nothing has changed. Google is evil, Twitter went fascist, facepals is an arm of the FSB, and All Your Genes Are Belong To Us. No fucking shit.

Using computers for everything requires understanding them and most. People. Don’t.

[-] peopleproblems@lemmy.world 2 points 6 months ago

I like entertaining the idea that purchasing technology should require some form of license like a firearm.

The only problem with the idea is that I would probably be out of a job pretty quick, given no one would be able to use computers.

[-] Appoxo@lemmy.dbzer0.com 4 points 6 months ago

I had to explain where the windows key is.
That says enough.

[-] BearOfaTime@lemm.ee -3 points 6 months ago

Twitter has always been a cesspool. Thanks for noticing finally.

[-] WashedOver@lemmy.ca 10 points 6 months ago

Many of my friends and family sent their DNA away to these outfits. Early on I just ruled it out as I heard they were able to link cold cases to people in these databases. Combine that with the grave miscarriages of justice when they railroad people into convictions my "I haven't done anything to worry about" still did not want to be a part of that machine.

I didn't even think of this reality which is pretty bad. I'm glad I didn't sign up despite some interest in knowing more about my fractured family connections.

[-] Mamertine@lemmy.world 16 points 6 months ago

They don't need your DNA to connect you to solve a cold case. They determine we shares tiny chunks of DNA with a sample from a crime. With that, they find the family tree of the known person and can often determine who the guilty party is.

As in they know the suspect shares a paternal great grandfather with this person and a maternal great great grandmother with that person so we know it's one of these people. Then the police collect trash to find who from the limited pool the crime DNA belongs to.

[-] PopcornPrincess@lemmy.world 0 points 6 months ago

That’s some Minority Report type shit, scary stuff.

[-] abbotsbury@lemmy.world 8 points 6 months ago

Collecting evidence after a crime is the opposite of Minority Report.

[-] autotldr@lemmings.world 5 points 6 months ago

This is the best summary I could come up with:

The recent 23andMe data breach is a stark reminder of a chilling reality – our most intimate, personal information might not be as secure as we think.

The 23andMe breach saw hackers gaining access to a whopping 6.9 million users’ personal information, including family trees, birth years and geographic locations.

Government overreach is certainly a possibility, as the FBI and every policing agency in the world is probably salivating at the thought of getting access to such a huge data set of DNA sequences.

This logic is equivalent to a bank saying, “It’s not our fault your money got stolen; you should have had a better lock on your front door.” It’s unacceptable and a gross abdication of responsibility.

The fact that the stolen data was advertised as a list of people with ancestries that have, in the past, been victims of systemic discrimination, adds another disturbing layer to this debacle.

I’ve long argued that after the Equifax breach, the company should have received the corporate equivalent of the death penalty.

The original article contains 734 words, the summary contains 171 words. Saved 77%. I'm a bot and I'm open source!

[+] BustinJiber@lemmy.world 1 points 6 months ago

[deleted]

[-] alienanimals@lemmy.world 0 points 6 months ago

Life in prison for the executives.

[-] douglasg14b@lemmy.world 8 points 6 months ago

Because users used bad passwords and had their accounts logged into by with these legitimate passwords...?

Seems like misinformed outrage to me.

[-] Appoxo@lemmy.dbzer0.com -1 points 6 months ago

Read DNS and wondered why those are supposed for that to happen lol.

In regards to the headline: Just don't use that service and discourage anyone in the family?
Seems more like a gimmick to me.
If I'd need something like that, I'd go to a professional lab.

Technology

Our Rules

Approved Bots