Live data from Hacker News

Plex Security Incident

links.plex.tv

41–50 of 94 posts

Re: Plex Security Incident

#41
post #17

> 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?

They borrow unsecured k8s clusters on AWS. That’s not redis running…

Re: Plex Security Incident

#42

I am a faithful Plex lifetime user and have never had problems. That said, I shouldn't be blinded by convenience. I hear jellyfin is a good alternative. Can someone share - how easy is it to administer for clients outside of my network or possibly even outside my country? - how good is the app support? I transcode all of my media to AAC and h264 for compatibility -what about for streaming music? I really like Plex am…

- just like any web service, reverse proxy with SSL, it has internal user management

- there are a variety of apps to choose from on ios/android, smart TVs might be limited or nonexistent (LG has a good one though)

- consider a separate dedicated tool for music, like Navidrome

- it's open source, its developers respect me and my users and do not abuse their access to them using dark patterns to extract revenue

- features that they have removed anyway (plugins, photo sync, plex cloud)

Re: Plex Security Incident

#43
post #21

Earlier quoted context omitted.

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.

As long as the salt is secret from the attackers (which is not a given, of course), the length of the passwords shouldn't matter all too much; the input to the hash (i.e. password + hash) would still have enough entropy to not be brute-force-able.

Re: Plex Security Incident

#44
I have been using Jellyfin for two years now. I am yet another happy user with no issues. I am happy that all my data is secure and there is nothing shady to happen.

It was not surprising when Plex had a huge investment coming from VCs who might as well just be connected to the movie industry and Hollywood as a whole, when they committed the act of banning Hetzner and all of their data centers.

They also had slowly become just another low quality streaming service like Tubi or IMDb with really low quality content being pushed down onto the homepage and actually keeping your own media hidden somewhere in the submenus. With their updates they threw the entire UX upside down.

Plex has the most mature platform to be frank. But I am happy I jumped ship as soon as I saw their predatory practices. They are not going to stop.

Re: Plex Security Incident

#45
post #26

I am a faithful Plex lifetime user and have never had problems. That said, I shouldn't be blinded by convenience. I hear jellyfin is a good alternative. Can someone share - how easy is it to administer for clients outside of my network or possibly even outside my country? - how good is the app support? I transcode all of my media to AAC and h264 for compatibility -what about for streaming music? I really like Plex am…

Not sure about jellyfin, but I really dig Emby. Just as convenient as Plex. I can't even remember why I switched to Emby over Plex, but I never looked back.

I've been a paid user of Emby for years and it's been well worth it.

I think the final straw was Plex artificially blocking transcoding on Raspberry PI, even though it would work with a ton of work arounds.

Re: Plex Security Incident

#46

I am a faithful Plex lifetime user and have never had problems. That said, I shouldn't be blinded by convenience. I hear jellyfin is a good alternative. Can someone share - how easy is it to administer for clients outside of my network or possibly even outside my country? - how good is the app support? I transcode all of my media to AAC and h264 for compatibility -what about for streaming music? I really like Plex am…

> how easy is it to administer for clients outside of my network or possibly even outside my country?

You can run Jellyfin in any docker container. If you want to run it on a NAS in your home office and put it on the internet through ngrok or tailscale, you totally can. But you can host it pretty much wherever.

> how good is the app support? I transcode all of my media to AAC and h264 for compatibility

The official clients are just ok. They'll support all the file types you'd expect, but they're fairly slow and not great at streaming 4K. I pay for a client (Infuse Pro) that addresses a lot of those pain points, but it's been relatively poor at auto-detecting tv show metadata, so I'm still in the market for an app I'm happy with. Ideally an open source one.

> - what about for streaming music?

Technically works, but whether it's a good experience depends on the client you're using.

> - what do you like the most about jellyfin

Easy to set up. Great plugins for finding subtitles/artwork/metadata. Open source with good docs. Works with lots of clients. Easy to create and share accounts, and has fun features like synced remote viewing parties.

- what do you miss most about Plex?

The ads. jk never used it.

Re: Plex Security Incident

#47
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.

I have no idea how Plex runs their servers, but I've worked at companies where new systems are rolled out for new users/accounts, but old users/accounts are left on the "legacy" system (usually with the plan to migrate once the new system has been deployed and there is bandwidth available to handle the complexity of migrating users between systems). In particular, if you have a long-running service where some very old accounts might have special billing/pricing logic that you want to continue honoring but is difficult to implement in the new system, such a setup might make sense to continue long-term for a small subset of accounts.

Alternatively, maybe they mean that the limited subset of data was specifically the "email" and "password_hash" columns of the database ;P

Re: Plex Security Incident

#48

I am a faithful Plex lifetime user and have never had problems. That said, I shouldn't be blinded by convenience. I hear jellyfin is a good alternative. Can someone share - how easy is it to administer for clients outside of my network or possibly even outside my country? - how good is the app support? I transcode all of my media to AAC and h264 for compatibility -what about for streaming music? I really like Plex am…

Plex works on chromecast etc, not for jellyfin

Re: Plex Security Incident

#49
post #43

Earlier quoted context omitted.

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.

As long as the salt is secret from the attackers (which is not a given, of course), the length of the passwords shouldn't matter all too much; the input to the hash (i.e. password + hash) would still have enough entropy to not be brute-force-able.

If you have the hashed password, in most systems you have the salt. Salt+hash is for preventing the attackers from getting to try all your passwords in parallel.

Re: Plex Security Incident

#50
post #43

Earlier quoted context omitted.

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.

As long as the salt is secret from the attackers (which is not a given, of course), the length of the passwords shouldn't matter all too much; the input to the hash (i.e. password + hash) would still have enough entropy to not be brute-force-able.

[deleted]
Post reply on HN