News for hackers. Stuff that matters.
Re:Plex Security Incident by jcgl on Monday September 08, 2025 @07:14PM (#45175382)
As long as the salt is secret from the attackers (which is not a given, of course), the length of the passwords shouldn't matter all too much; the input to the hash (i.e. password + hash) would still have enough entropy to not be brute-force-able.
Re:Plex Security Incident by OkayPhysicist on Monday September 08, 2025 @07:37PM (#45175532)
If you have the hashed password, in most systems you have the salt. Salt+hash is for preventing the attackers from getting to try all your passwords in parallel.
Re:Plex Security Incident by fluidcruft on Monday September 08, 2025 @08:33PM (#45175980)
You can also have a system salt(s) that are not stored with the database, so that if someone accesses the database they have to guess password and two salts, one of which they hopefully do not have via the same penetration.
Re:Plex Security Incident by solid_fuel on Monday September 08, 2025 @08:39PM (#45176024)
Maybe this is what you're saying, I'm not sure - my understanding was that the salt prevents reused passwords from resulting in the same hash. So, if I use 'password' and you use 'password' the salt+hash will be different. That way attackers can't just hash all the common passwords once and immediately associate them with different accounts.
Re:Plex Security Incident by OkayPhysicist on Tuesday September 09, 2025 @11:23AM (#45183248)
Yeah, exactly. Commonly, the salts are stored right next to the hashes in the DB, because they serve their purpose even if the attacker knows what the salts are. By using a different salt for every password, the attacker needs execute a full "guess, hash, compare, repeat" attack on each user, as opposed to "guess, hash, compare against all user passwords, repeat" on the entire database.