Plex: Important notice of a potential data breach
We want you to be aware of an incident involving your Plex account information yesterday. While we believe the actual impact of this incident is limited, we want to ensure you have the right information and tools to keep your account secure.
What happened
Yesterday, we discovered suspicious activity on one of our databases. We immediately began an investigation and it does appear that a third-party was able to access a limited subset of data that includes emails, usernames, and encrypted passwords. Even though all account passwords that could have been accessed were hashed and secured in accordance with best practices, out of an abundance of caution we are requiring all Plex accounts to have their password reset. Rest assured that credit card and other payment data are not stored on our servers at all and were not vulnerable in this incident.
What we're doing
We've already addressed the method that this third-party employed to gain access to the system, and we're doing additional reviews to ensure that the security of all of our systems is further hardened to prevent future incursions. While the account passwords were secured in accordance with best practices, we're requiring all Plex users to reset their password.
What you can do
Long story short, we kindly request that you reset your Plex account password immediately. When doing so, there's a checkbox to "Sign out connected devices after password change." This will additionally sign out all of your devices (including any Plex Media Server you own) and require you to sign back in with your new password. This is a headache, but we recommend doing so for increased security. We have created a support article with step-by-step instructions on how to reset your password [here](https://support.plex.tv/articles/account-requires-password-reset/?utm_source=Plex&utm_medium=email&utm_content=reset_password&utm_campaign=sql_db_password_reset).
We'd also like to remind you that no one at Plex will ever reach out to you to ask for a password or credit card number over email. For further account protection, we also recommend enabling [two-factor authentication](https://support.plex.tv/articles/two-factor-authentication/?utm_source=Plex&utm_medium=email&utm_content=reset_password&utm_campaign=sql_db_password_reset) on your Plex account if you haven't already done so.
Lastly, we sincerely apologize to you for any inconvenience this situation may cause. We take pride in our security system and want to assure you that we are doing everything we can to swiftly remedy this incident and prevent future incidents from occurring. We are all too aware that third-parties will continue to attempt to infiltrate IT infrastructures around the world, and rest assured we at Plex will never be complacent in hardening our security and defenses.
For step-by-step instructions on how to reset your password, visit: https://support.plex.tv/articles/account-requires-password-reset Thank you,
The Plex Security Team
193 comments
[ 3.2 ms ] story [ 219 ms ] threadAs of Aug 23 11:24PM PST, Password change page is sort of working, at times displaying error message "Internal Server Error. Something went wrong on our end". I was able to get my request through. Shortly after, a server instance started showing unclaimed status and reassociating it resulted in "Plex is down for maintenance \ Don't worry, it will be back soon \ status.plex.tv".
[1] https://twitter.com/troyhunt/status/1562329358282285057
I'm going to give it some time. I also even went through these steps (https://support.plex.tv/articles/204281528-why-am-i-locked-o...) without success.
After removing the attribute entirely it was able to successfully reclaim the server.
I believe they're doing that. I double-checked and got no email from them.
Security is about layers. Simply because a hacker “could” do something, does not mean it’s a bad idea. Getting the encryption key when it’s not stored in the database requires the hacker to now have access not to just the database but to another system as well.
But the hackers would have to know what algorithm was used :) That's a layer, right?
I think that depends on where you work. Process. Code reviews before allowing merge/pull requests can help.
This seems like an acceptable solution for email and a lot of other PII. However, if you were to propose the same thing for passwords, with the same argument, I'd be dead against it -- even beyond the total lack of need for the system to ever have the actual password. I'm not quite sure how to explain this, though.
Now an attacker cannot get a hold of email addresses easily.
3rd party mail sending services could support this by generating a keypair on their systems, and only giving you the public half. When you make an API request to send an email, you provide only the encrypted version of the address.
Edit: The hashing is an issue. It's too easy to build a wordlist of possible addresses, to crack the hash. I think this can only work if you drop the hash column, and instead require users to log in using a username.
The alternative is to handle everything by a username and password resets also use the username (which would be fine, worst case you get spammed by PW reset mails).
Though of course you can also combat this by making the hash particularly expensive and salt it. Simply take a SHA3-512 of the email address a few thousand times, take the first 12 bits and use that to identify a set of 4096 records. Now the full email is simply an application of Blake2sp, which you calculate in parallel for all 4000 records.
Adjust the 12-bit barrier so that it represents a decent sized chunk of users, lower would mean less load on the login service, higher would mean better anonymity. Instead of SHA3-512 you could also use a bloom filter to find out if a set of records contains the email or not, with the added bonus of being probabilistic.
You could also ditch Blake2sp for a simple round of salted SHA3-512. The fact that you salted it makes dictionary search insanely annoying already.
Hardcoding a key would be a bad idea. You would need some way to rotate keys. Maybe also encrypt the actual data encryption keys under another key encrypting key.
But this only defends against attacks which can't get that key (e.g. a SQL injection attack that just dumps table contents).
Having said that, you only need to decrypt if you want to send an email, for logging in you could just store a one way salted hash.
More importantly, this is a lot of effort to protect data that isn't usually regarded as that sensitive (unlike the passwords). If I had the security budget to do that, I'd almost certainly spend it on something else.
Some of those practices may be generally applied for non-healthcare settings as well.
They serve different purposes. For eg: When a disk drive is faulty and thrown away, you may not want data to be recoverable from it. So, the filesystem level encryption helps there. A db/table/column level encryption helps when there are different applications (eg: transaction processing and analytics) accessing a shared database. Reporting queries may not need access to the sensitive fields whereas certain transaction processes may need it. In this case, db/table/column level encryption helps. When you want separation of concerns, you can add application level encryption (on top of the other two). Example: Your data is stored on the cloud and you don't want the cloud service provider to know the data or if they replace a disk drive as part of normal servicing, you don't want your data to leak.
This depends on the threat model.
The relevant parts of HIPAA are the duty to not disclose PHI to unauthorized recipients and breach notification requirements if you do incorrectly disclose PHI (the HIPAA breach notification rule).
The magic of encryption is that HIPAA provides safe harbor if the data stolen/lost/intercepted was encrypted to certain standards. So if you lose an encrypted hard drive full of PHI, or someone breaks into your servers and steals encrypted data but not the decryption capability, then it's not considered a breach under HIPAA and you do not need to notify anyone.
Tons of PHI isn't stored encrypted at rest. Physical theft of the hard drive from the practice's back-end EHR database server hasn't generally been high priority on the HIPAA breach potential risk assessment list. But nearly all data in transit, on employee laptops, etc. will be encrypted, because that's where you want the safety net of the safe harbor provision.
From the HHS site: https://www.hhs.gov/hipaa/for-professionals/faq/2001/is-the-...
> Is the use of encryption mandatory in the Security Rule?
> Answer:
> No. The final Security Rule made the use of encryption an addressable implementation specification. See 45 CFR § 164.312(a)(2)(iv) and (e)(2)(ii). The encryption implementation specification is addressable, and must therefore be implemented if, after a risk assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its risk management of the confidentiality, integrity and availability of e-PHI. If the entity decides that the addressable implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate. If the standard can otherwise be met, the covered entity may choose to not implement the implementation specification or any equivalent alternative measure and document the rationale for this decision.
https://support.apple.com/guide/icloud/what-you-can-do-with-...
If anyone is curious, then alternatives like Jellyfin exist. It's a bit different and may not have all the features you need, but it works quite well in my experience.
1: https://github.com/jellyfin/jellyfin/issues/5415
That would mean running a publicly accessible instance would be ill advised if you can about the privacy of what you host. Plex on the other hand somewhat encourages publicly accessible instances, so you can listen/watch while not at home.
(The caveat being, certain plugins disclose media to Plex but arguably that's a first or second party not some rando on the internet scraping stuff)
It might not be in a great place now, but I'm not sure that's necessarily a reflection of the product
One of the things I remember making it real difficult was that the UI of Samsung's dev tools app assumes you have the default light theme in GTK (or whatever widget toolkit they're using), and since I had a different dark theme, I couldn't see any of the icons.
So then I switched to one of my devices that were running Ubuntu 20.04 with Gnome, where the app would not launch due to something about "pixbuf". Side note - I'd had that particular error so many times in Ubuntu with various apps that it's the sole reason I eventually learned Arch (and tiling window managers), and haven't looked back since.
I finally managed to get it to launch and work correctly on Xubuntu running on my girlfriend's very, very old laptop that takes about 8 minutes to boot to full speed. So save yourself the headache, and run the Samsung dev tools app on an unmolested Linux installation, with no special theming, that is not vanilla Ubuntu.
Thanks for the feedback.
Jellyfin may not be perfect but surely it's good enough for most use cases.
But otherwise I've switched to Infuse[2] since then, it indexes sources reliably on its own (no manual editing though) and saves the entire need for a server if you use it with some cloud storage. Basically replaced my Plex server, with the added bonus of out-of-home streaming without needing high upload. The major disadvantage is that it's Apple-only.
1: https://support.plex.tv/articles/207538527-do-i-need-a-plex-... 2: https://firecore.com/infuse
I tried Plex years ago, and it wasn't to my liking because it was philosophically like Windows (Load the filename up with show information and constantly ping the internet for matches) instead of macOS (Metadata where it belongs — with the file).
I'm considering adding a Sony phone to my household, so now that Plex is in the news, this reminded me to check it out again.
If you're purchasing everything through iTunes (do people still purchase stuff through whatever is "iTunes" now? I guess I don't know that either) I assume its handling transcoding/different device playback and delivering all the metadata for you.
Also once Plex pulls metadata down you're right that it doesn't store it with the file but AFAIK its not constantly hitting the net to pull that info down - it keeps a local cache.
I will say at this point - I wouldn't bother switching to Plex and look for an alternative like Infuse. The company is clearly under pressure to monetize beyond the Plexpass subscription you can buy. They've been steadily adding crap no one wants and automatically jamming it into the home screen of the app where you then have to go turn it off. Its just a matter of time before they cross a line somewhere and people jump ship. When that happens I imagine some of the open source alternatives (Jellyfin) will see a huge influx of development. I haven't switched just because I don't want to be hassled with figuring out a new system.
To some extent, it's self-reinforcing. Once the FireTV gets a lead, all it has to do to maintain/extend that lead is reasonably support playback of whatever new format/source and Plex works great on it. If FireTV supported TV as well as TiVo does, it might end up with 100% of the living room display share.
(I also have Plex sharing to devices outside the house, but that's a <1% use case, mostly when it's us traveling somewhere and the kids wanting to watch something that's on Plex.)
I'm not in the US or mainland Europe so Fire and TiVo devices aren't really available or working well here, half their apps would just be blank.
Ironically I like Plex & Infuse for the reason you hate them, I just give them files whose metadata is just their filename and they can match them to what they really are. No need to keep all the data in media container tags, and a thumbnail/poster that will be pixelated in a few years because something will scale it wrong.
Sony is a valid option given their love for DLNA but I just never really liked the tech. Hell, I have statically-reserved IPs & DNS-registered names for everything in my home.
EDIT: Oh, I forgot -- the main reason I moved off Plex (and would hate iTunes Home Sharing) is I don't leave my PC on. I switch it off daily and don't like to treat it like a server, and to keep using Plex would require setting up a NAS or something (I had my collection on a local SSD for a while).
For this infuriating reason, moving off of Plex is on my to-do list.
edit:
You can also do this: https://support.plex.tv/articles/200890058-authentication-fo...
Being hard of hearing, subtitles are a big deal. I wonder if this is an ADA violation?
What if you change the global accessibility settings to prefer subtitles? (Or just set SDH/CC somewhere in system settings) I know on Google/Android TV and Apple TV it default-enables subtitles in some apps.
* Kodi only works on my local network. It requires exposing my file shares on whatever VLAN my Kodi devices are on.
* Kodi is a pain to configure. To point it at the aforementioned file shares, I need to copy an XML configuration file, and getting this onto every device is a chicken and egg problem.
* Kodi requires each client to scan and sync the entire library at its CPU and bandwidth limits. My Plex server automatically scans and indexes my media.
* Plex allows me to access my content at the office, while travelling, and to share with friends
* Kodi doesn't transcode, requiring all of my client devices to have enough power and bandwidth to do so locally. Plex makes it much simpler to (for instance) stream a 4k video to a low power device
I know enough to have ran Kodi for years and intentionally switched to Plex full time
Bold of you to trust an opaque corporation with access to your network and the data they can log through that. I wouldn't even trust Synology with their account quick access thing, as seamless as they claim it to be.
I don't really see remote access being secure without it being a self hosted VPN.
If they asked, I'd show them exactly what's up. They haven't, so they don't seem to mind.
It's not full access to my network, it's access to a carefully curated set of media files transcoded through a service. There are no tax returns, no resumes, no porn. Just FLAC, MP3, and MKV.
Kodi can do all those things but you wouldn't as it has much better options to achieve the same result.
I've tried using Plex before and while the UI is nice, they don't seem to be able to write a video transcoder that doesn't have massive stuttering in it.
Normal people also want to have features like remote streaming, subtitles fetching, familly sharing, etc which are hard to do without centralized accounts. Not even mentionning securing your paid features which you have to do to survive. And that customer doesn't care about the login as long as it is up.
I don't anything plex could do to please this particular demand would ever be enough so for me they do well to ignore it since removing that would effectively kill their business.
I did pay for Plex prior to the cloud auth change, so for me it's a bait and switch, but my concerns are much more about privacy.
One day Plex will be bought by a large media company, and my (and my kids') viewing data and library catalogue data will be owned by MGM, Disney, Fox, etc...
Jellyfin's DVR service is horrible compared to Plex. Practically unusable. And DVR is the reason I pay for Plex.
Edit: Not sure why I would be getting down-voted for this. Security breaches are a big deal, but if the only result of this for the users is that we need to change our passwords that's a fairly good outcome, no? :-) The biggest hurdle ahead for Plex is to figure out exactly what these attackers did, if they were directly targeted and for how long they were in their network. A lot of the times a incident is discovered it's discovered a long time after the first breach (based on my own personal experience)
Understand that sending emails that are not SPAM, to potentially millions of people is NOT a trivial exercise.
It sounds like payment data was stored in a separate database that had a different set of credentials (for this I am grateful).
Thanks to The Plex Security Team for providing details quickly.
> Rest assured that credit card and other payment data are not stored on our servers at all and were not vulnerable in this incident.
They also have clients for all major platforms and for web browsers, and can be accessed from outside of your home. I'm currently in Portugal, watching TV shows off my home machine in Germany via my phone or my Amazon Fire TV or my laptop.
It's much like having your own self-hosted Netflix.
EDIT: Figured it out. Need to access the server from the same network (or tunnel to it). You won't see server settings from external network.
A delete account option would be nice in this case. I'd rather just have my data deleted even if it has already been compromised just to tie off this loose end.
http://www.spamcop.net/w3m?action=checkblock&ip=192.254.122....
> System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop)
Sounds like their spam trap is broken.
I hope that Plex learns from this and implements LAN-only logins (or LAN-only access) again.
1: https://news.ycombinator.com/item?id=9817160
Which is of course, a bold-faced lie, otherwise they would never have forced users to open Plex accounts, or removed the ability to conduct authentication locally.