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

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

    I don’t think that’s how salts work. I might be wrong, but I think it works like this

    Password + Salt -> Hash

    • “p@ssword” + “hakf” -> “hifbskjf”
    • “p@ssword” + “jkjh” -> “gaidjshj”
    • “p@ssword” + “afgd” -> “afgdufj”

    Notice how those 3 users use the same password, but the different salts results in 3 different hashes. That doesn’t make it any harder to crack a single hash, but it means I have to crack the same password 3 times. It just slows down password cracking.

    Edit: my explanation isn’t wrong, but I didn’t understand the pepper part until now. So I understand the above now.

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

      You missed the part about pepper. Pepper is something that’s added, like salt, but that isn’t stored with the password. A low security version of this is an environment variable, but it could also be a secure hardware device on the machine.

      So it’s more like this:

      • “p@ssword” + “hakf” + “pepper” -> “hifbskjf”
      • “p@ssword” + “jkjh” + “pepper” -> “gaidjshj”

      If an attacker only has the salt, they’ll “crack” the password into something that’s not the original password: brute_force("higbskjf", "hakf") - > "kdrnskk". The idea is that it might take a few days for the attacker to recognize the error, and by then the security team has already responded and locked the backdoor.

      Even if the passwords are peppered, users should assume their password is compromised and change them. But peppering may prevent a cascade effect from reused passwords.

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

        I actually didn’t realize pepper was a thing. I mostly do frontend. But that’s really interesting!

    • Waraugh@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 hours ago

      That’s all you can do though, extend the time it takes to brute force, so I’m not sure what the distinction being made is.

      • ramjambamalam@lemmy.ca
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        5 hours ago

        Response time is critical. It’s the difference between immediately getting pwned vs. having time for the security team to identify the threat, notify their users, and users to assess the impact of the breach and change their passwords.

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

        even if someone brute forces an offline copy of the hashes they wouldn’t result in actual useable passwords

        I thought you were suggesting that salted hashed passwords were uncrackable but maybe I misunderstood this

        Edit: I understand the offline pepper part now. My bad

        • Waraugh@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          3
          ·
          9 hours ago

          Gotcha, no, I wasn’t trying to make that claim, it’s just a way to make it more difficult/time consuming