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

Plex Security Incident

links.plex.tv

Post reply on HN
Print view View original

31–40 of 94 posts

Re: Plex Security Incident

#31

Post by hamdingers »

johnbellone wrote: post #7
BowBun wrote: post #3

Not necessarily related, but I'll take the opportunity to share my dislike of this company. Like others, they built a loyal following around a set of features provided, no questions asked, to stream your content to your own devices. Over the last couple of years, Plex has continued to strip functionality, add paywalls, make deals with publishing companies, and take other actions that firmly put them in the 'enshittif…

I have a “lifetime pass”. I’ve noticed some of these “features” creeping into the ecosystem (bloat), but I haven’t actually seen any stripped functionality. For the most part, it works as advertised. That being said, a lot of my mates are moving to Jellyfin. Nothing but good things from them.

> but I haven’t actually seen any stripped functionality

Plugins, the watch later list, the up next/playback queue, Plex Cloud/Cloud Sync, photo backup (this one hurt), privacy preferences were badly nerfed.

Those are just the ones I miss, I'm sure there are more (like the short lived arcade thing).

Re: Plex Security Incident

#32

Post by smallerize »

Dedime wrote: post #21
Someone1234 wrote: post #9

> 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. I am glad they were hashed, but that's a misleading statement. The point of hashing is to slow an attacker down, even with full best security practices (e.g. salt + pepper + argon2 w/high factors) they can still be reverse engineered. It is a matter of when , not i…

Maybe this is naive, but in a good crypto system, I would hope "when" is measured in millions or billions of years given current hardware capabilities.

If you have a long enough and random enough password, you're probably good. The trouble with short passwords is that there just aren't that many of them. An attacker can just compute the hash of all of them.

Re: Plex Security Incident

#33

Post by imglorp »

> An unauthorized third party accessed a limited subset of customer data from one of our databases

How could only a subset be affected? Any architecture other than a "users" db table wouldn't make sense.

Re: Plex Security Incident

#34

Post by kstrauser »

mr90210 wrote: post #17
Someone1234 wrote: post #9

> 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. I am glad they were hashed, but that's a misleading statement. The point of hashing is to slow an attacker down, even with full best security practices (e.g. salt + pepper + argon2 w/high factors) they can still be reverse engineered. It is a matter of when , not i…

> (e.g. salt + pepper + argon2 w/high factors) they can still be reverse engineered. It is a matter of when, not if How much compute/gpu and hard dollars would hackers need in order to reverse engineers those stollen passwords?

Approximately “infinite”.

Re: Plex Security Incident

#35

Post by reactordev »

imglorp wrote: post #33

> An unauthorized third party accessed a limited subset of customer data from one of our databases How could only a subset be affected? Any architecture other than a "users" db table wouldn't make sense.

Rows 1-200,000 instead of 1-1,000,000 I would presume.

Re: Plex Security Incident

#36

Post by Urist-Green »

Someone1234 wrote: post #9

> 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. I am glad they were hashed, but that's a misleading statement. The point of hashing is to slow an attacker down, even with full best security practices (e.g. salt + pepper + argon2 w/high factors) they can still be reverse engineered. It is a matter of when , not i…

One of the aspects of MtGox's database leak that I found most fascinating to watch was the public effort to figure out users' passwords from the hashes. Checking common passwords, patterns, and people's public interests on Twitter was all shockingly effective.

Re: Plex Security Incident

#37

Post by vachina »

magicalhippo wrote: post #16
BowBun wrote: post #3

Not necessarily related, but I'll take the opportunity to share my dislike of this company. Like others, they built a loyal following around a set of features provided, no questions asked, to stream your content to your own devices. Over the last couple of years, Plex has continued to strip functionality, add paywalls, make deals with publishing companies, and take other actions that firmly put them in the 'enshittif…

I like Jellyfin, but I keep using Plex for two reasons. First is subtitle support is quite limited in comparison. It fails more often than it works for me. Second is the lack of skipping. This is with the Android TV client, haven't really tried the others.

Some Plex clients will fail to direct stream DTS + PGS.

Jellyfin somehow just works on all my devices.

Re: Plex Security Incident

#38

Post by supportengineer »

imglorp wrote: post #33

> An unauthorized third party accessed a limited subset of customer data from one of our databases How could only a subset be affected? Any architecture other than a "users" db table wouldn't make sense.

Sharding the data across DB's, separate credentials for each DB.

Re: Plex Security Incident

#39

Post by reassess_blind »

imglorp wrote: post #33

> An unauthorized third party accessed a limited subset of customer data from one of our databases How could only a subset be affected? Any architecture other than a "users" db table wouldn't make sense.

Could be technically true in that they didn’t access every last bit of “user data” like support chat logs or whatever stored elsewhere, but they have phrased it that way to make it seem like less of a big deal. Just a guess.

Re: Plex Security Incident

#40

Post by kingnothing »

imglorp wrote: post #33

> An unauthorized third party accessed a limited subset of customer data from one of our databases How could only a subset be affected? Any architecture other than a "users" db table wouldn't make sense.

It's easy to imagine Plex has some db sharding going on at their scale, or that they host in multiple geographic regions for regional compliance, or on multiple cloud providers.
Post reply on HN