The best thing is to use a salt that is a fact about the user that can’t reasonably change (like the user ID). So you can copy the password field, but if you copy the user id too then nothing happens (assuming there isn’t a unique constraint in the db), you are still logged in with the same user id.

However, user ids really only work for UUIDs as numbers are not random (and very easy to create rainbow tables for). If your users can’t change their user name or email address, you could use that as well.

It seems you'd need to include the same key as you'd log in with. If you hash a UUID primary key then the same attack just requires changing the username as well as the password hash. Like, if I change withinboredom to projektfu with projektfu's password hash, I could log in and mess around, then change everything back.

All assuming database access but for some reason reading the database doesn't get me what I want. Perhaps this system is used to get a bearer token or session cookie for another system I can't access.

The way it usually works for something like bcrypt is this: password comes in as input, you choose a work factor / cost, your bcrypt library takes both and returns a string that you store in a single hashed pw field. The string consists of the work factor followed by a random salt (that it generated and concatenated to the input on its own) followed by the hash, so each account has its unique salt, you're good. If your DB gets dumped, people can't generate rainbow tables to discover the passwords of multiple accounts at once. Devs do sometimes concatenate other data to the pw before passing it to the bcrypt library, basically a runtime salt not stored in the (same) DB, so that just having a DB dump actually isn't enough to find users using the password "password".

Sure, if someone swaps the stored fields of two accounts around, they can login as them, but I don't think I've ever seen attempts at preventing this with just hashing policy. Things are rather dire for you already if an attacker can swap the fields of two accounts. Is the attacker in this scenario an employee...? As you say, any additional data from the row that is used along with the main random salt can just be swapped around too. I guess it's possible that an attacker can only swap the hash field, but not anything else, or especially not something like the primary key they would need. Some older schema designs store the per account salt in a separate column from the hashed password, if only one field can be altered then I guess that would stop the given threat scenario too. (Edit: I guess another scenario the GP might be thinking of is that all other data is gated behind queries that filter on a user id, so an attacker partially modifying just the user login row to login "as them" doesn't actually help get access to anything else if they had to modify the user id.)

I think it's better here to focus on the broader scenario of "unauthorized access" which includes concerns like: attacker actually knows the user's password (from keylogger or whatever) and thus doesn't even need to alter anything in the DB or care about the hashing policy. It might seem like it's over in such a case, but many systems out there still manage to prevent many cases of such unauthorized access. e.g. with 2FA, or pseudo-2FA with things like "we don't recognize this device fingerprint/IP, so re-verify the account's email and/or phone and/or trusted recovery email" -- and even after that sometimes the service (Google) still might not let you in.

Thanks, very useful info.