Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Plex: Important notice of a potential data breach

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 194 posts

Re: Plex: Important notice of a potential data breach

#21

Post by rurban »

gkhartman wrote: post #19

Thanks for sharing this. I got the email, but found it here first. They let us know pretty fast, and gave clear instructions on how to secure our accounts moving forward. That can't be said for all companies that we trust with our info. 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…

No, not all.

> Rest assured that credit card and other payment data are not stored on our servers at all and were not vulnerable in this incident.

Re: Plex: Important notice of a potential data breach

#23

Post by MattPalmer1086 »

flexd wrote: post #15

I'm a long time Plex user, and I have not received this email. Not sure if I should be worried or if the breach has just affected a subset of users. I use random unique passwords for everything anyway, as long as no credit card details were taken it shouldn't be a big deal hopefully. I was able to log into the site now and no message was displayed at all. Edit: Not sure why I would be getting down-voted for this. Sec…

Likewise, I haven't got anything.

Re: Plex: Important notice of a potential data breach

#24

Post by vivegi »

KingOfCoders wrote: post #20
vivegi wrote: post #18

Earlier quoted context omitted.

In the healthcare industry in USA, Personal Identification Information (PII)/Personal Health Information (PHI) needs to be encrypted at rest and in transit and is mandated by law. So, they are required to encrypt PII/PHI data fields. Some of those practices may be generally applied for non-healthcare settings as well.

Does at-rest mean: encrypted on storage so noone can physically steal a drive or encrypted in the database so noone can get the information with SQL without the key (e.g. Postgres column encryption)?

Conceptually, yes. You can encrypt at the database/filesystem level (where the OS/DB engine manages the encryption keys and enforces access control), at a table level/column level (where the db engine enforces access control) or at the application level (where the application manages the encryption keys and they are separate from the database engine).

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.

Re: Plex: Important notice of a potential data breach

#25

Post by pxeger1 »

marcushill wrote: post #13
KingOfCoders wrote: post #9

I personally wish companies would encrypt email addresses in their database, this would at least help against SQL injection attacks and some others (e.g. attacker has only DB system access and not app server access), so it's more difficult for attackers to aggregate data on me. To me it feels very casual waving away the leak of email addresses and just give the usual "passwords were encrypted". But YMMV.

It seems to me that encrypting emails is either untenable or insufficient depending on how you do it. You could do a one-way operation like is used on passwords, but then you can't access the user's email address to send them emails. You could instead do a two-way encryption but that likely means using a hardcoded key to decrypt, and that key can't be considered secure if attackers have access to the system. There ma…

If that 2-way encryption key is stored separately to the database (e.g. only the web server has it, not the database server), it certainly helps reduce the risk that the emails are compromised.

Re: Plex: Important notice of a potential data breach

#26

Post by ResNet »

withinrafael wrote: post #2

This disclosure is no where to be found on their website or blog, and it provides no timeline, no details about the attack, and no details about what data was accessible beyond "a limited subset of data that includes emails, usernames, and encrypted passwords". Very very frustrating. As of Aug 23 11:24PM PST, Password change page is sort of working, at times displaying error message "Internal Server Error. Something…

It appears the password change works fine if you deselect the "Sign out connected devices" box. [1]

[1] https://twitter.com/troyhunt/status/1562329358282285057

Re: Plex: Important notice of a potential data breach

#27

Post by zexodus »

hddherman wrote: post #14

If true, then this will probably reignite discussions around Plex requiring that you authenticate with their servers when using the service to view content that you're hosting on your own hardware. 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.

Perhaps the most important thing about Jellyfin is that it's open source. I really wish the project received a little bit more love.

Re: Plex: Important notice of a potential data breach

#28

Post by TedDoesntTalk »

onionisafruit wrote: post #11
KingOfCoders wrote: post #9

I personally wish companies would encrypt email addresses in their database, this would at least help against SQL injection attacks and some others (e.g. attacker has only DB system access and not app server access), so it's more difficult for attackers to aggregate data on me. To me it feels very casual waving away the leak of email addresses and just give the usual "passwords were encrypted". But YMMV.

The difference between email and password is you can validate a password with a hash, but you can’t send an email to a hashed address. Their db may be encrypted at rest, but a hacker could still compromise a system that has the key in memory.

> a hacker could still compromise a system that has the key in memory.

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.

Re: Plex: Important notice of a potential data breach

#29

Post by input_sh »

kinduff wrote: post #6
TheGuyWhoCodes wrote: post #4

Forgot my password doesn't work nor the settings screen password change. If you gonna ask all your users to reset passwords you might want to actually scale up to allow them to do that

This. And also if you know what "limited subset" of accounts were compromised, you might want to notify only the users affected, and reset the passwords for them.

> you might want to notify only the users affected

I believe they're doing that. I double-checked and got no email from them.

Re: Plex: Important notice of a potential data breach

#30

Post by MattPalmer1086 »

marcushill wrote: post #13
KingOfCoders wrote: post #9

I personally wish companies would encrypt email addresses in their database, this would at least help against SQL injection attacks and some others (e.g. attacker has only DB system access and not app server access), so it's more difficult for attackers to aggregate data on me. To me it feels very casual waving away the leak of email addresses and just give the usual "passwords were encrypted". But YMMV.

It seems to me that encrypting emails is either untenable or insufficient depending on how you do it. You could do a one-way operation like is used on passwords, but then you can't access the user's email address to send them emails. You could instead do a two-way encryption but that likely means using a hardcoded key to decrypt, and that key can't be considered secure if attackers have access to the system. There ma…

You're mostly right.

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.

Post reply on HN