As I slide the needle from “strongly dislike” to “not a fan”.
Good on em
Comment on Plex got hacked.
ayyy@sh.itjust.works 1 day ago
I harbor a strong dislike for the profiteers at Plex but their security incident response is textbook correct. Good job security dudes! The rest of your stupid company should listen to you more often.
As I slide the needle from “strongly dislike” to “not a fan”.
Good on em
Overall I agree, but not requiring users to change password when the hashes were taken is a bit too soft IMO.
It will also be interesting to see if they make a public disclosure about the specifics of who and how. They also don’t specifically define if media watched data was included or excluded.
Either way, happy I migrated to Jellyfin.
I do think they missed a bit about password reuse, since they tell you to reset the password on their site, you should be changing the password on any other sites where you reused it. But yeah, not arguing about it being good otherwise.
They say password were securely hashed, following best practices, which would include a salt, which is different elsewhere.
They also say
meaning they cannot be read by a third party
which equally isn’t true.
If your password is guessable with trillions of attempts, and whatever information and time an attacker wants, then of course can they crack your hash, “read” your password, and try it on other services.
Sadly the kind of password susceptible to being broken on account of not being strong enough is also the kind people use everywhere because they memorize it. A truly strong password will only be found in a password manager.
But if you can solve the hash by generating password guesses, hashing them, and comparing them to the hashed passwords in the database. Say I hash “p@ssword” using the salts sorted in my database. I find that jon@example.com uses “p@ssword”. I then go to Amazon, com, login with Jon’s account, and order a bunch of stuff to my address.
Salt just makes it so I can’t hash “p@ssword” once and find everyone with that password the database. It really only slows me down.
I’m not a security expert, can someone tell me if I got that right?
That’s correct. All salt does is force the attacker to compromise each password individually. Those passwords should still be considered compromised and users should change them everywhere they’re used.
If you add pepper (random data stored separately from the passwords and salts, like an ENV var or ideally secure hardware device), an attacker would also need the pepper to crack the password correctly, which significantly raises the bar. However, even then it’s good practice to change that password everywhere even if compromise is unlikely, because again, someone could link your login to another compromised site and crack the easier site’s password hash.
The only reason it’s okay to not recommend a password change is if the password hash database was provably not compromised, but in that case, I’d want details on how they kow that.
That assumes the salt was also compromised/extracted. Unfortunately, they don’t say. Which one could read as not compromised. But they’re not transparently explicit about it.
I was surprised they didn’t recommend changing passwords elsewhere, too. I would also prefer them to be transparent about how they were vulnerable/attacked.
I’m not a security expert, but to my knowledge that’s the point - even a unique salt global to your site/service can help. Worth mentioning are rainbow tables, which are databases of hashes for known strings, so you can take a hash and look up the string, and very easily defeated by salts.
If the password is securely hashed, and the attack only includes data exfiltration, then there’s theoretically no risk of breaking into users’ accounts anyways. However, the issue is that if somebody can log into your Plex account, that means they got your password somehow - and if they did get that password, they can use it elsewhere. So if there’s any reason to change your password on Plex, then there’s just as much reason to change that same password elsewhere.
skisnow@lemmy.ca 1 day ago
It shows how low the bar is, that just bare bones complying with GDPR notification requirements so as not to risk a €20M fine, is enough to make people talk about how good a job you did.