- cross-posted to:
- selfhosted@lemmy.world
- plex@lemmy.ca
- cross-posted to:
- selfhosted@lemmy.world
- plex@lemmy.ca
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
So is this user specific salt word stored in a table somewhere, how does the company decrypt a salted password otherwise, and so if the salt is also stored somewhere alongside the encrypted password, couldn’t the hacker get his hands on both the salt and the password and use that to figure out the password?
Yes, the salt is stored right alongside the username and hashed password. The point of the salt isn’t to be unknown; It’s to make every single password unique before it gets hashed, which invalidates the hackers’ pre-generated rainbow tables. It forces them to re-generate their table for each user. Even identical passwords will create different hashes, because the salt is different for each user. Essentially requiring the hacker to brute force every single password, even after they have the database downloaded.
Basically, the hash algorithms are known. There are a few common ones, but they’re all reliable. A rainbow table is generated by running potential passwords through each hash, and saving the results. For a simplified example: maybe for a certain hashing algorithm, “password” generates the hash “12345”. I have a pre-generated table with millions of potential passwords that tells me as much. And I have repeated this for all of the most popular hashes. This gigantic database (literally hundreds of GB in size) of millions of potential passwords and resulting hashes for the most popular algorithms is my rainbow table. This took hours of cooking my CPU to generate.
So I hack an unsalted password database, and find a bunch of hashes that are listed as “12345”. I can now guess that they’re probably using that specific hash algorithm, and can immediately crack a bunch of passwords purely because I have already brute-forced them before I hacked anything. I can also crack the rest of the passwords much faster, because I’m only needing to brute force the one algorithm I know they used, instead of being forced to hash with all of them.
But now let’s say it’s a salted hash instead. When I hack the database, my pre-generated rainbow tables are useless. Because now “password” is not being hashed as “12345”. It’s being hashed as something entirely different, because the salt is added before it gets hashed. Even if multiple users use “password”, it still doesn’t help me because each of their salts is unique. So even if two different users use “password”, they’ll each return different hashes. So I need to recreate my rainbow table for every single user. Even if two users both used “password” I’ll still need to check each one individually, with their unique salts.
This doesn’t completely invalidate the breach, but it drastically slows down my ability to access individual accounts. The goal is simply to slow me down long enough for the company to be able to send out “hey, change your password” notifications, and for the users to do so. Without a salt, once I have the database, I instantly know which hash the company is using. And I can immediately access a bunch of accounts using my pre-generated rainbow table. But with the salt, I’m still forced to crack each user individually.
To be clear, weak passwords will still crack faster. A good password guessing attack doesn’t just brute force. It starts with known lists of common/popular/weak passwords, because that known list of weak passwords will often get you into an account extremely quickly.
the salt does not need to be encrypted. the point of it is that it makes a generic rainbow table useless, because the crackers need to compute hashes themselves for all passwords.
as they said, the purpose of hashing is to slow down the crackers, because they need to find the string that produces that hash. a rainbow table cancels that, it makes password lookup for an account almost instantaneous. but a rainbow table is only really useful for unsalted hashes, because for salted hashes a different rainbow table is needed that takes the salt into account.
If the hash is unique per person, hackers need to build a new table per person. It doesn’t matter if the hackers can get their hand on the salt; the point is that they cannot try the common passwords easily for all users; it takes N times as long where N is the number of users with a different salt (hopefully all of them)