- cross-posted to:
- selfhosted@lemmy.world
- cross-posted to:
- selfhosted@lemmy.world
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
I’m not a security expert, but password hashing is mostly to slow down someone from getting all the passwords. You can’t reverse the hash, but you can generate hashes until you find a match. When hashing, you can dial in how much compute it would take someone to try and solve all the hashes in your database. If you used a good password, it will be more difficult to solve your hashed password. But it’s best to change your password as Plex suggests.
So it depends on how secure a password is and how strong of hashing Plex used when storing the hashed passwords. I have no idea if this is like a “this will take a year” or “this will take a billion years” to solve all the hashes. More compute also means you can solve the hashes faster. Maybe someone with a security background could chime in.
That’s called a rainbow table attack, and that’s why you should salt your hash. This salt basically appends a unique string of characters to every password before it goes into the hash. Let’s say your users are dumb and use “password” for their password. If a hacker has pre-generated a rainbow table, (which is extremely time and resource intensive), then they’ll instantly crack that as soon as they get a match on those common passwords. Even if they haven’t generated a rainbow table, they can just look for identical hashes and guess that those users are using common passwords.
But if you salt it, it’ll slow the hackers down drastically by invalidating their pre-generated table. Each user has their own salt stored alongside the username and hash, so User 1’s hash actually saw “password19,jJ03pa5/-@“ while user 2’s hash saw “passwords)205JrGp02?@-“. Because each of their salts are unique, their resulting hashes are unique too. Even though they used the same password. Now the hackers need to crack the hash for each user, by incorporating the existing salts for each user. They’ll start with the weak and common passwords first, which is why it’s still best practice to use strong passwords. But they can’t actually start the rainbow table process until after they have hacked the info, and they’ll need to create fresh tables for every single user.
Best explanation of salt I’ve ever seen. Thanks!
NaCl
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)
Not entirely
Firstly you don’t “generate hashes until there is a match”. You can generate hashes until the end of the universe and you’ll still have only a fraction of all possible hashes.
What typically is used are large lookup tables with hashes from known passwords. You can then take that table, take a hash you got, and look it up.
So firstly, hashes should be salted, and if salted correctly, it’s already extremely much harder to use because these tables no longer work. There are few more things you can do but that pretty much is a hard wall already.
The problem is that many corporate systems out there have horrible security. They either use a hash that has been known to be broken since a long time ago (hello LinkedIn), don’t use salting (hello linkediiiiiinn), or don’t use hashing at all.
It’s because of idiots like these that there are so many accounts with password tables out there
What to do?
Use password managers. Now all your site’s have different, safe passwords and you only need to know one. Use 2FA where possible and supported
Can you also use a list of common passwords and a ruleset you apply to those common passwords, and then
hash(applyRule(commonPassword), salt) == compromised hash?I’m not entirely sure what you mean but my password manager alerts when the hash of one of my passwords matches one from a dark web data dump, and prompts me to replace it with a newly generated one.
I’m sure it’s not a unique feature
Admittedly I do have a few bad password, a combination of I don’t see how I could care (like a Reddit alt account) and sites that break the password change automation (yeah I’m lazy)
I wonder how that works. The point of password hashing is to uniquely scramble your password. So userOneHash(“password”) should give a different output than userTwoHash(“password”) even if they use the same password. So your password manager shouldn’t really be able to generate the same password hash since an infinite number of hashes can be generated from the same password.
If they are following best practices then individual hashes should be salted and the database of hashes should be peppered so even if someone brute forces an offline copy of the hashes they wouldn’t result in actual useable passwords.
I don’t think that’s how salts work. I might be wrong, but I think it works like this
Password + Salt -> Hash
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.
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:
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.
I actually didn’t realize pepper was a thing. I mostly do frontend. But that’s really interesting!
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.
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.
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
Gotcha, no, I wasn’t trying to make that claim, it’s just a way to make it more difficult/time consuming