- cross-posted to:
- selfhosted@lemmy.world
- homelab@lemmy.ml
- cross-posted to:
- selfhosted@lemmy.world
- homelab@lemmy.ml
We have recently experienced a security incident that may potentially involve your Plex account information. We believe the actual impact of this incident is limited; however, action is required from you to ensure your account remains secure.
What happened
An unauthorized third party accessed a limited subset of customer data from one of our databases. While we quickly contained the incident, information that was accessed included emails, usernames, securely hashed passwords and authentication data.
Any account passwords that may have been accessed were securely hashed, in accordance with best practices, meaning they cannot be read by a third party. Out of an abundance of caution, we recommend you take some additional steps to secure your account (see details below). Rest assured that we do not store credit card data on our servers, so this information was not compromised in this incident.
What we’re doing
We’ve already addressed the method that this third party used to gain access to the system, and we’re undergoing additional reviews to ensure that the security of all of our systems is further strengthened to prevent future attacks.
What you must do
If you use a password to sign into Plex: We kindly request that you reset your Plex account password immediately by visiting https://plex.tv/reset. When doing so, there’s a checkbox to “Sign out connected devices after password change,” which we recommend you enable. This will sign you out of all your devices (including any Plex Media Server you own) for your security, and you will then need to sign back in with your new password.
If you use SSO to sign into Plex: We kindly request that you log out of all active sessions by visiting https://plex.tv/security and clicking the button that says ”Sign out of all devices”. This will sign you out of all your devices (including any Plex Media Server you own) for your security, and you will then need to sign back in as normal.
Additional Security Measures You Can Take
We remind you that no one at Plex will ever reach out to you over email to ask for a password or credit card number for payments. For further account protection, we also recommend enabling two-factor authentication on your Plex account if you haven’t already done so.
Lastly, we sincerely apologize for any inconvenience this situation may cause you. We take pride in our security systems, which helped us quickly detect this incident, and we want to assure you that we are working swiftly to prevent potential future incidents from occurring.
For step-by-step instructions on how to reset your password, visit:https://support.plex.tv/articles/account-requires-password-reset
You must log in or # to comment.
Friendly reminder that Jellyfin is free, open source, and free.
Lol. Good.
I’m sure Plex has some great engineers, and Plex’s infrastructure is far more hardened and secure and reliable than my Jellyfin server.
But they are a way way more likely target, and Jellyfin still performs far better and doesn’t try to sell shit to my family members.
And in case someone hacks into your Jellyfin, what exactly would they do with it? Watch movies? :D
Hey, don’t make light of my stuff.
I have some sick tunes in there too! __
Plex is riskier just by having a cloud things phone home to. One target to hit that can affect multiple users.
Depending on your use case, jellyfin may actually be more secure.
I think you mean Plex got hacked AGAIN
lol
Glad I never gave Plex any payment details, don’t reuse passwords, and don’t plan on using it any more so I can just ignore this
The best solution would be to migrate to Jellyfin altogether
I bought a lifetime subscription years ago, and even if the payment method got decrypted, it’s well expired. Not to mention I haven’t had a Plex server running for ages.
Yep same here, I already got a brand new credit card with a brand new number because my renewal got stuck in a postal strike lmao
They say that passwords are hashed but we’re they salted?
Nevermind the credit cards, it’s the viewing habits they can sell that really make money.
End of the day does it even matter? They’ve gotten a ton of other information including authentication data which is probably just as, if not more, useful/lucrative to them.
From another source:
Server owners will also have to claim their server again and possibly update it, as Plex has also announced that it had “made adjustments” that will temporarily prevent “regular” users from connecting to any Plex server they have been granted access to.
The reason given is that too many Plex Media Server instances have yet to be updated to version 1.42.1, which contains a fix for a vulnerability (CVE-2025-34158CVE-2025-34158) that could be exploited remotely by authenticated users to gain access to the server and tamper with it and the data on it.
This part should have been a lot more visible and not just hidden as part of a generalized forum post. The error the individual users got doesn’t do anything to make it clear what the user or server owners need to do.
As an intentional change by Plex, presenting basic guidance as to what the error theyve caused means should be the absolute bare minimum. This is the piece that annoys me most.
This is why I barely trust any streaming platform… I mean I try to not use my ‘real’ email for anything (and I stupidly linked my other emails to it on my phone, so Google basically knows it even if they dont have direct access to the inboxes).
There is so much shit being hacked that the idea that rhat any information we put out there isn’t already available on the darkweb is stupid. Even some AI camera surveillance company has said that they built their database in part based on information they bought from the darkweb (I need to get the source again).
And I rarely hear about those same hackers getting caught. Its almost like they have it down to a T and it is simply too profitable and the chances of getting caught are too minimal to care. And this shit is continuing despite all the legislation being passed to monitor more and more internet activity, which makes me think if any of it will even work?
It is still rare that someone truly criminal is caught because of some internet searches. Most data is collected from confiscated computers and if they simply deleted their browsing history and used a basic file shredder to wipe their free space they would not be able to recover anything.
Word of warning. Resetting your password is causing lots of people to lose access to their server. I’ll be deleting config and reclaiming the server after work.
If you have Synology.
Uninstall(without delete) and reinstall Synology.
It will allow you to log back in.
I’m on Linux and the simplest solution I found was to use the browser to generate a claim code on plex.tv and then install that code in the server via curl.
Didn’t need to delete anything, just logged in directly via the servers IP and claimed it.
That’s awesome that you had a slightly easier path to recovery
If you have Synology using DSM style install
Here is how to “claim” your server that it logs you out of.
https://forums.plex.tv/t/synology-faq-questions-answers-and-how-tos/490215/39
Tldr; Uninstall but keep files. Reinstall using the existing files and a newly token.
Sure would’ve been nice to know this 2 hours ago.
I hate the tone companies always use with this
Some evil guys did something to us, it happened to us, and there was nothing we could have done to prevent it, but we were so quick to respond and stop it!
Aka, you fucked up with your security. Could you just once admit that?
No one is safe from hackers. Everyone and every company will get hacked, it’s unavailable. What matters is how they react to the inevitable because that’s how best practices are made.
Eh, sorry, no.
Yeah, it is extremely hard to make something impenetrable, but claiming blanket everyone will be hacked is nonsense too.
If a company does IT well it will very unlikely fall victim as they’ll be a very hard target and not worth the time and money.
When a company comes out with that they’ve been hacked you can bet dollars to donuts that they’ve neglected their IT department and infrastructure because the very vast majority of cases have shown that problem
i had to argue with some friends that when a breach happen and the company did not do everything in they’re power to prevent it, then it is the company’s fault.
They argued that bad actor should never do bad things, even it they are at hands reach.
If a company exposes an s3 bucket with clients data publicly, the company is 100% at fault if someone discovers it and sell the data. ofc the guy would be liable too.
That’s like arguing that if a bank takes my gold to put in a security deposit box but then puts that box open out in the street. Of course the bank would be responsible for the theft.
It was securedly hashed! We used ROT13! Twice! We’re fucking professionals!
It’s possible to use salts, peppers, and key stretching algorithms that repeatedly hash a password like 100,000 times. So yes, it’s possible to do so securely.
Ok, but what if it’s only hashed 80 000 times? Should I sue my provider?
I understand what you are saying, and what you want… but admitting fault publicly is a huge liability, as they have then stated it was their negligence that caused the issue. (bear with me and read this wall of text – or skip to the last paragraph)
I’ve worked in the Sec Ops space, and it’s an arms race all the time. There are tools to help identify issues and breaches quickly, but the attack surface is just not something that can be managed 100%. Even if you know there is a problem, you probably have to send an issue to a developer team to update their dependency and then they might need to change their code as well and get a code review approved and get a window to promote to production. A Zero-Day vulnerability is not something you can anticipate.
You’ve seen the XKCD of the software stack where a tiny peg is propping up the whole thing? The same idea applies to security, but the tiny peg is a supply chain attack where some dependency is either vulnerable, or attacked by malicious actors and through that gain access to your environment.
Maybe your developers leverage WidgetX1Z library for their app, and the WidgetX1Z library just updated with a change-log that looks reasonable, but the new code has a backdoor that allows an attacker to compromise your developers computer. They now have a foothold in your environment even with rigorous controls. I’ve yet to meet a developer who didn’t need, or at least want, full admin rights on their box. You now have an attacker with local admin inside your network. They might trip alarms, but by then the damage might be done and they were able to harvest the dev database of user accounts and send it back home. That dev database was probably a time-delayed copy of prod, so that the developer could be entirely sure there were no negative impacts of their changes.
I’m not saying this is what happened to Plex, but the idea that modern companies even CAN fully control the data they have is crazy. Unless you are doing full code reviews of all third-party libraries and changes or writing everything in-house (which would be insane), with infallible review, you cannot fully protect against a breach. And even then I’m not sure.
The real threat here is what data do companies collect about us? If all they have is a username, password and company-specific data, then the impact of a breach is not that big – you, as a consumer, should not re-use a password. When they collect tons of other information about us such as age, race, location, gender, sex, orientation, habits, preferences, contacts, partners, politics, etc, then those details become available for anyone willing to pay. We should use breach notifications like this to push for stronger data laws that prevent companies from collecting, storing, buying or selling personal data about their customers. It is literally impossible for a company to fully protect that information, so it should not be allowed.
A great place to start is data privacy laws. If they don’t collect unnecessary PII, it can’t be exposed.
But yes, companies need to face more liability. While it’s true that no one is inhackable - you’d need to be perfect everywhere all the time and the bad guys only need one break to succeed - there are best practices that make it a lot more unlikely. If you as a company have been hacked and you’re not taking good care of your customers data, you should be liable for carelessness. Admittedly following good data security practices can be expensive but that’s why there should be consequences for those who cut corners
I fully agree: Companies and their leadership should be held accountable when they cut corners and disregard customer data security. The ideal solution would be that a company is required to not store any information beyond what is required to provide the service, a la GDPR, but with a much stricter limit. I would put “marketing” outside that boundary. As a youtube user, you need literally nothing, maybe a username and password to retain history and inferred preferences, but trying to collect info about me should be punished. If your company can’t survive without targeted content, your company should not survive.
In bygone days, your car’s manufacturer didn’t know anything about you and we still bought cars. Not to start a whole new thread, but this ties in to right-to-repair and subscriptions for features as well. I did not buy a license to the car, I bought the fucking car; a license to use the car is called a lease.
I’m no lawyer, but wouldn’t that basically open them up to an instant win for anyone who files lawsuits against them?
Yes and no. hacking isn’t new. Everyone could get sued technically for security breaches for not taking enough interest in their own security.
But then it’s ridiculous if you could sue your own grandma cuz you once used her computer to print your resume and because she uses default passwords now someone has all your info you had from anything you left behind.
Ransom and hacking is pretty common unfortunately in the industry. And it is in part on the user to also take practices to protect themselves if they haven’t enabled 2F yet. And there’s way more you can do where you make email masks now and simply do not fill in with your accurate information like don’t use your real name.and use a VPN. Store stuff on ext drives and less on clouds that don’t use e2e encryption
I don’t know if it’s perfect but as a user just always have it back in your mind that your information can be obtained(if you ever used a web service to check your info on the dark web, this is pretty much going to be a given) . And it probably has. So maybe at least you can try to control what gets obtained.
In some ways 2fa is a weak spot even disregarding recovery processes being open to social engineering, now you’re giving a verified identifier uniquely tied to you
I generate unique email addresses and passwords for every account but can’t realistically do that with phone numbers
2fa by sms or voice isn’t especially secure anyway since you’re open to sim attacks and social engineering. I have a lot more hope for Passkeys but don’t really trust the practical advice arts of managing them yet
…second phone number…
Anyways… we are digressing here,
at this point it’s a lot like protecting anything in life: prevention and making yourself less tasty to a psycho.
If you’ve set it even two step You’re already doing way more than any user they are probably intending this warning to do more to protect themselves who set their password to “password” or phrases haven’t changed it in decades and would even prefer to publicly post their passwords on social willing to give up their entire savings rather than having to do anything further as if technology is too beyond and suddenly so super complex that they have to use different keys on their keyboard other than letters.
You don’t have to apply every threat like it’s calculus in a situation where there are people who are scared of even doing basic sums.
This situation was hashtags. And all they are asking is to rehash it. And here you are already disposing of the 2nd feature after that.
Do any of you receive a password reset mail? I don’t. So I fear somebody might have already changed /taken over my account? Even though i do use two factor auth?
- I did receive the initial notice
- I did not receive the reset mail i asked for. Not in spam either. I have checked that the emailadress is identical to the one i received the original notice for.
Try it again. I bet their password reset service was swamped after sending the notice.
I received it fine about an hour ago
For me that worked, about 9 hours ago. Maybe there is more load now that the Americas are awake?
I am not on Plex anymore, so I will not have to worry about this. :-)
I’m not a security expert, but password hashing is mostly to slow down someone from getting all the passwords. You can’t reverse the hash, but you can generate hashes until you find a match. When hashing, you can dial in how much compute it would take someone to try and solve all the hashes in your database. If you used a good password, it will be more difficult to solve your hashed password. But it’s best to change your password as Plex suggests.
So it depends on how secure a password is and how strong of hashing Plex used when storing the hashed passwords. I have no idea if this is like a “this will take a year” or “this will take a billion years” to solve all the hashes. More compute also means you can solve the hashes faster. Maybe someone with a security background could chime in.
Not entirely
Firstly you don’t “generate hashes until there is a match”. You can generate hashes until the end of the universe and you’ll still have only a fraction of all possible hashes.
What typically is used are large lookup tables with hashes from known passwords. You can then take that table, take a hash you got, and look it up.
So firstly, hashes should be salted, and if salted correctly, it’s already extremely much harder to use because these tables no longer work. There are few more things you can do but that pretty much is a hard wall already.
The problem is that many corporate systems out there have horrible security. They either use a hash that has been known to be broken since a long time ago (hello LinkedIn), don’t use salting (hello linkediiiiiinn), or don’t use hashing at all.
It’s because of idiots like these that there are so many accounts with password tables out there
What to do?
Use password managers. Now all your site’s have different, safe passwords and you only need to know one. Use 2FA where possible and supported
Can you also use a list of common passwords and a ruleset you apply to those common passwords, and then
hash(applyRule(commonPassword), salt) == compromised hash?That’d basically how these hash tables work, they have the account and hash and known password so you can do rapid lookups
I’m not entirely sure what you mean but my password manager alerts when the hash of one of my passwords matches one from a dark web data dump, and prompts me to replace it with a newly generated one.
I’m sure it’s not a unique feature
Admittedly I do have a few bad password, a combination of I don’t see how I could care (like a Reddit alt account) and sites that break the password change automation (yeah I’m lazy)
I wonder how that works. The point of password hashing is to uniquely scramble your password. So userOneHash(“password”) should give a different output than userTwoHash(“password”) even if they use the same password. So your password manager shouldn’t really be able to generate the same password hash since an infinite number of hashes can be generated from the same password.
You can’t reverse the hash, but you can generate hashes until you find a match.
That’s called a rainbow table attack, and that’s why you should salt your hash. This salt basically appends a unique string of characters to every password before it goes into the hash. Let’s say your users are dumb and use “password” for their password. If a hacker has pre-generated a rainbow table, (which is extremely time and resource intensive), then they’ll instantly crack that as soon as they get a match on those common passwords. Even if they haven’t generated a rainbow table, they can just look for identical hashes and guess that those users are using common passwords.
But if you salt it, it’ll slow the hackers down drastically by invalidating their pre-generated table. Each user has their own salt stored alongside the username and hash, so User 1’s hash actually saw “password19,jJ03pa5/-@“ while user 2’s hash saw “passwords)205JrGp02?@-“. Because each of their salts are unique, their resulting hashes are unique too. Even though they used the same password. Now the hackers need to crack the hash for each user, by incorporating the existing salts for each user. They’ll start with the weak and common passwords first, which is why it’s still best practice to use strong passwords. But they can’t actually start the rainbow table process until after they have hacked the info, and they’ll need to create fresh tables for every single user.
So is this user specific salt word stored in a table somewhere, how does the company decrypt a salted password otherwise, and so if the salt is also stored somewhere alongside the encrypted password, couldn’t the hacker get his hands on both the salt and the password and use that to figure out the password?
Yes, the salt is stored right alongside the username and hashed password. The point of the salt isn’t to be unknown; It’s to make every single password unique before it gets hashed, which invalidates the hackers’ pre-generated rainbow tables. It forces them to re-generate their table for each user. Even identical passwords will create different hashes, because the salt is different for each user. Essentially requiring the hacker to brute force every single password, even after they have the database downloaded.
Basically, the hash algorithms are known. There are a few common ones, but they’re all reliable. A rainbow table is generated by running potential passwords through each hash, and saving the results. For a simplified example: maybe for a certain hashing algorithm, “password” generates the hash “12345”. I have a pre-generated table with millions of potential passwords that tells me as much. And I have repeated this for all of the most popular hashes. This gigantic database (literally hundreds of GB in size) of millions of potential passwords and resulting hashes for the most popular algorithms is my rainbow table. This took hours of cooking my CPU to generate.
So I hack an unsalted password database, and find a bunch of hashes that are listed as “12345”. I can now guess that they’re probably using that specific hash algorithm, and can immediately crack a bunch of passwords purely because I have already brute-forced them before I hacked anything. I can also crack the rest of the passwords much faster, because I’m only needing to brute force the one algorithm I know they used, instead of being forced to hash with all of them.
But now let’s say it’s a salted hash instead. When I hack the database, my pre-generated rainbow tables are useless. Because now “password” is not being hashed as “12345”. It’s being hashed as something entirely different, because the salt is added before it gets hashed. Even if multiple users use “password”, it still doesn’t help me because each of their salts is unique. So even if two different users use “password”, they’ll each return different hashes. So I need to recreate my rainbow table for every single user. Even if two users both used “password” I’ll still need to check each one individually, with their unique salts.
This doesn’t completely invalidate the breach, but it drastically slows down my ability to access individual accounts. The goal is simply to slow me down long enough for the company to be able to send out “hey, change your password” notifications, and for the users to do so. Without a salt, once I have the database, I instantly know which hash the company is using. And I can immediately access a bunch of accounts using my pre-generated rainbow table. But with the salt, I’m still forced to crack each user individually.
To be clear, weak passwords will still crack faster. A good password guessing attack doesn’t just brute force. It starts with known lists of common/popular/weak passwords, because that known list of weak passwords will often get you into an account extremely quickly.
If the hash is unique per person, hackers need to build a new table per person. It doesn’t matter if the hackers can get their hand on the salt; the point is that they cannot try the common passwords easily for all users; it takes N times as long where N is the number of users with a different salt (hopefully all of them)
the salt does not need to be encrypted. the point of it is that it makes a generic rainbow table useless, because the crackers need to compute hashes themselves for all passwords.
as they said, the purpose of hashing is to slow down the crackers, because they need to find the string that produces that hash. a rainbow table cancels that, it makes password lookup for an account almost instantaneous. but a rainbow table is only really useful for unsalted hashes, because for salted hashes a different rainbow table is needed that takes the salt into account.
Best explanation of salt I’ve ever seen. Thanks!
NaCl
If they are following best practices then individual hashes should be salted and the database of hashes should be peppered so even if someone brute forces an offline copy of the hashes they wouldn’t result in actual useable passwords.
I don’t think that’s how salts work. I might be wrong, but I think it works like this
Password + Salt -> Hash
- “p@ssword” + “hakf” -> “hifbskjf”
- “p@ssword” + “jkjh” -> “gaidjshj”
- “p@ssword” + “afgd” -> “afgdufj”
Notice how those 3 users use the same password, but the different salts results in 3 different hashes. That doesn’t make it any harder to crack a single hash, but it means I have to crack the same password 3 times. It just slows down password cracking.
You missed the part about pepper. Pepper is something that’s added, like salt, but that isn’t stored with the password. A low security version of this is an environment variable, but it could also be a secure hardware device on the machine.
So it’s more like this:
- “p@ssword” + “hakf” + “pepper” -> “hifbskjf”
- “p@ssword” + “jkjh” + “pepper” -> “gaidjshj”
If an attacker only has the salt, they’ll “crack” the password into something that’s not the original password:
brute_force("higbskjf", "hakf") - > "kdrnskk". The idea is that it might take a few days for the attacker to recognize the error, and by then the security team has already responded and locked the backdoor.Even if the passwords are peppered, users should assume their password is compromised and change them. But peppering may prevent a cascade effect from reused passwords.
I actually didn’t realize pepper was a thing. I mostly do frontend. But that’s really interesting!
That’s all you can do though, extend the time it takes to brute force, so I’m not sure what the distinction being made is.
even if someone brute forces an offline copy of the hashes they wouldn’t result in actual useable passwords
I thought you were suggesting that salted hashed passwords were uncrackable but maybe I misunderstood this
Edit: I understand the offline pepper part now. My bad
Gotcha, no, I wasn’t trying to make that claim, it’s just a way to make it more difficult/time consuming
Jellyfin advertisement 🤷♂️
OK, coming from a Jellyfin user for years, its not like it’s impervious to any attacks.
Stuff like this can happen to any app, developers are only human, shit happens. A bigger company is a bigger target for hackers, so there is some saftey in an open source app that’s not as popular, but then again a bigger company also has more resources to monitor for security breaches and quickly address them and push out a hot fix, can’t say I know how this works for free open source apps
I think the point here is that Jellyfin doesn’t have a centralized login or website like Plex does. An attacker would have to know about your server and log into it directly to get access. If you run it in a container, there isn’t a lot they can do other than trashing your media library, which you should have protected with filesystem snapshots anyway.
Jellyfin doesn’t even have write access to my files. If they can get access into the container’s process then I guess they could add stuff to the web interface which could contain bad stuff.
I enjoy using Jellyfin and hope it continues to improve, but it has some problematic security of its own.
But if you just run it locally an a media server in your home, and you don’t expose the service to the internet, that doesn’t really matter? Though perhaps more people connect to their Jellyfin instances remotely than I realize.
It matters if someone manages to hide an exploit in jellyfin’s codebase, or more likely, a popular plugin. I imagine many folk have permissive outgoing firewall rules, in which case, an exploit could establish connectivity. Whether that eventually leads to privilege escalation on the jellyfin host would depend upon other variables.
Well. If you’re not streaming why have such a service in the first place? If I didn’t stream remotely with Plex (and share with my friends and family) I’d just go back to running Kodi on my htpc like I did ten years ago.
steam locally to multiple devices plus for remote streaming I just VPN into my home network
For example?
Thank you. These should get fixed.
But again, I can host behind a VPN and have zero risk here. I can work around my own shit, a Plex user can’t protect their data when Plex owns it.
Lack of built-in 2FA for one thing
🍮🇫🇮
Just installed that yesterday lol
Hope they did actually delete my data when I deleted my account, but I don’t think I use that password anywhere anymore anyway.
The hash was only exposed.
