NaCl

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.

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.

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)

That’d basically how these hash tables work, they have the account and hash and known password so you can do rapid lookups

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)

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.

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.

Accounts can be deactivated without being deleted.

fuck plex for plenty of other reasons, but you can disable authentication on your local network.

If you just changed your password and now you don’t have access… Directly connect to the server http://<serverip>:32400/web and you’ll get the setup prompt to connect it back to your account.

If that doesn’t work you can restart the server and try again (should catch up that it’s unauth’d). Or run a tool like https://github.com/ChuckPa/UserCredentialReset to reset it so you can reauth it.

But they are responsible for the unsecured / gruyere cheese product they ship.

Jellyfinn has a lot of holes and it is easy to deploy it in a insecure way by not techie people. Last time I checked they even didn’t have a recommended practices for hardening it

Good to read you know how to implement some protection layers around your jellyfinn :)

But most of the people (specially the plex ones) don’t have the technical background to deploy something like you have, and convince those people to do the switch without knowing how to protect themselves is not a wise thing to do. Specially when this time, plex response was perfectly fine :)

???

This is not about enshitification. The best user friendly app can be a security nightmare and an utterly crap can be rock solid.

It is not about that, not even development models or just rock star programmers.

It is about who has a performing security team and who doesn’t.

Which is the exact mindset that enables Jellyfin devs to not fix those issues, congratulations

You’re right, I’m sorry. I was misremembering.

Well, if it said “The attacker gained access to systems in October 2023 and we patched out the vulnerability during March 2025,” you’d be asking why it took so long to discover the intrusion and why they didn’t let us know for six months?

Yeah, even if it is the law, companies do tend to fall short of adhering to said law. For example, a lab that does cancer screening got hacked and pretty much messed up their entire response.