Comment on Plex got hacked.
moseschrute@lemmy.world 1 day agoBut 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” using the salts sorted in my 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. It really only slows me down.
I’m not a security expert, can someone tell me if I got that right?
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.
The salt is part of the password hash
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.
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.
sugar_in_your_tea@sh.itjust.works 1 day 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.