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

  • Kissaki@feddit.org
    link
    fedilink
    English
    arrow-up
    4
    ·
    11 hours ago

    They say password were securely hashed, following best practices, which would include a salt, which is different elsewhere.

    • moseschrute@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      edit-2
      11 hours ago

      But if you can solve the hash by generating password guesses, hashing them, and comparing them to the hashed passwords in the database. Say I hash “p@ssword” and I use the salts sorted in the stolen database. I find that jon@example.com uses “p@ssword”. I then go to Amazon.com, login with Jon’s account, and order a bunch of stuff to my address.

      Salt just makes it so I can’t hash “p@ssword” once and find everyone with that password the database. Instead I have to hash “p@ssword” multiple times. It really only slows me down.

      I’m not a security expert, can someone tell me if I got that right?

      • Kissaki@feddit.org
        link
        fedilink
        English
        arrow-up
        2
        ·
        6 hours ago

        That assumes the salt was also compromised/extracted. Unfortunately, they don’t say. Which one could read as not compromised. But they’re not transparently explicit about it.

        I was surprised they didn’t recommend changing passwords elsewhere, too. I would also prefer them to be transparent about how they were vulnerable/attacked.

      • sugar_in_your_tea@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        4
        ·
        9 hours ago

        That’s correct. All salt does is force the attacker to compromise each password individually. Those passwords should still be considered compromised and users should change them everywhere they’re used.

        If you add pepper (random data stored separately from the passwords and salts, like an ENV var or ideally secure hardware device), an attacker would also need the pepper to crack the password correctly, which significantly raises the bar. However, even then it’s good practice to change that password everywhere even if compromise is unlikely, because again, someone could link your login to another compromised site and crack the easier site’s password hash.

        The only reason it’s okay to not recommend a password change is if the password hash database was provably not compromised, but in that case, I’d want details on how they kow that.

      • KubeRoot@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        2
        ·
        10 hours ago

        I’m not a security expert, but to my knowledge that’s the point - even a unique salt global to your site/service can help. Worth mentioning are rainbow tables, which are databases of hashes for known strings, so you can take a hash and look up the string, and very easily defeated by salts.

        • moseschrute@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          9 hours ago

          But if you use a salt that is global to your site/server, you still have this problem: If a hacker cracks “p@ssword” in your database, they immediately know all users that also use “p@ssword”. Imo the biggest benefit of using salts is two users with the same password get different hashes. Right?

          I’m not saying using a global salt isn’t better than no salt, but I do think you’re missing out on a huge benefit of using a per hash salt. Keep in mind I’m a frontend engineer not backend or security lol.

    • redjard@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      10 hours ago

      They also say

      meaning they cannot be read by a third party

      which equally isn’t true.

      If your password is guessable with trillions of attempts, and whatever information and time an attacker wants, then of course can they crack your hash, “read” your password, and try it on other services.

      Sadly the kind of password susceptible to being broken on account of not being strong enough is also the kind people use everywhere because they memorize it. A truly strong password will only be found in a password manager.

    • KubeRoot@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 hours ago

      If the password is securely hashed, and the attack only includes data exfiltration, then there’s theoretically no risk of breaking into users’ accounts anyways. However, the issue is that if somebody can log into your Plex account, that means they got your password somehow - and if they did get that password, they can use it elsewhere. So if there’s any reason to change your password on Plex, then there’s just as much reason to change that same password elsewhere.