"and my hash happens to match some other user" Since when are we worrying about these kinds of hash collisions? If the collision occurs, it is either because the hash function is bad or because the salt is too short, but both of these are fixable and do not invalidate the design as a whole.

@DreamConspiracy as a design pattern, it's horrifying. You are inferring that the username is the userID because the password hash matches.

Since the User is logged in as UserID, all activity will be logged as UserID. The Username is never used for anything after authentication.

@user227162 depending on the scenario, for a targeted attack the attacker might well know when their target is typically online and which username they likely use. If you have only a handful of users that increases the likelihood that they quickly know the right userid+username combination. Side-note: this also increases the value of knowing the user-id and protecting it becomes more important than "just" to prevent enumeration attacks.

@user227162 Also consider that the problem with the approach that schroeder points out is not only relevant regarding security but also regarding possible bugs. If a "normal" password check is buggy, the probability for a random bug to allow logging in as another user is smaller than with this approach as it already has a chance for this to happen by design (albeit with preventive measures that should avoid the case).

schroeder: feel free to incorporate any part of my comments into your answer if you agree and feel it may enhance the answer.

For the record, I have no intention of implementing this. I am only learning. I actually think leaving all the User fields (UserID, UserName, Salt, everything together and only pulling the password hash into a separate table with one field might be a somewhat better idea.

@schroeder Not advocating for this approach but the issue of hash collisions can be trivially solved at user creation by checking if there's a collision. If there is, generate a new salt.

@Rob yep, and Argon2 makes it difficult to create collisions, and there is lots of other scaffolding you could put in to try to make it work. However, authentication through inference is a horrible design pattern.

@DreamConspiracy Normally we don't worry about this collision because it does not matter because we tie username to a hash. Say for example there are two users, Bob and Mike. Bob's password is "hello" and Mike's password is "world". But somehow the hashing algorithm collides and both of them has a password hash of "1234". In a normal system Bob cannot log in to Mike's account because his username is "Bob" not "Mike". In this system Bob can accidentally log in to Mike's account

@DreamConspiracy Aside from the arguments that we normally do make sure hash collisions if they occur don't have a negative impact, like recompute or have mechanisms to handle multiple objects in the same hash bin, this would be a terrible bug to run into and a terrible pro con weighing. Sure it's rare, but like everything rare but bad, it will happen one day thanks to Murphy. And then you have a bug where likely sometimes a user ends up as a different user, but sometimes it works. If it's based on a typo in passwords, that's even harder to trace than two users that share the same hash.

@DreamConspiracy It's totally frightening to any user that runs into this and can easily make headlines and the only thing you can do is either change the approach or reset the user and hope it doesn't happen again. It would make ridiculous advertisement: I have secured this the best way possible: in case someone breaks in and steals all our data they might find it harder to get your passwords to log in with them afterwards. But as a minor side-issue there is a totally low chance now that someone accidentally logs into your bank account just by pure typo chance. Isn't that great security?!

@Frank Do we normally do that? Because Git doesn't and it turns out it has worked perfectly fine for many years for many, many projects (not if you maliciously induce the collision but that's a different scenario and caused by the choice of hash).

@schroeder So have you considered the effect of bits flipping due to solar rays and not being corrected by ECC (god forbid if you ever ran any of these programs on a server without ECC) in all your authentication designs? Because that's way more likely than an unintentional hash collision from a quick estimate so that would qualify as a "horrifying approach" as well then. Also how many bit flips do you consider an acceptable risk?

@I don't know where git uses hashes in a way that allows collisions and doesn't account for it, I typically consider the effect a collision has. If git does not print a warning if a commit hash you are about to cherry pick does cherry pick two commits I'd indeed consider that a bug, too. But sure there are cases where we look at the scenario and say, it's fine if a clash occurs, and we don't need special handling: To identify log entries, yeah fine a collision does limited harm if it turns up log entries from an additional operation. You can make that visible, too.

@Voo but we're not talking about low impact operations but security relevant ones and particular a choice made to improve security with an imho awful risk trade-off and that trade-off was my main point - but I'd consider any developer who'd not at least consider the risk of what happens on a hash clash when introducing hash based functionality into any security relevant (or otherwise "important" ) functionality not a good responsible developer. There are certainly cases where clashing is fine, but I'd assume someone at least made sure that isn't too terrible if it happens.

@voo you have neglected my comments which would have precluded your snide and unnecessary remark.

@Frank A git commit is simply a SHA-1/256 hash over some specific content and meta data. Having a collision between two unrelated commits would absolutely cause havoc. This is an intentional design decision and not a bug. So if you store your source code for the given authentication code in Git you're already accepting the fact that collisions are so infinitesimally unlikely that it's nothing to worry about. Given that both Linux and Microsoft are now using Git for storing their OS code, you're also implicitly trusting that assumption if you're using any of those OSes.

@Voo and I've finally found something bad about git if there indeed is no protection at all for such cases. (though if it is a inentional decision there at least was a weighing process)

@Frank As I said, the chance of a cosmic ray ruining the hash comparison is many orders of magnitudes larger than a collision happening. Why so upset about one problem while being perfectly content ignoring the much larger one? (are you using ECC RAM on your local desktop? If not you just magnified the problem another few order of magnitudes).

@Voo I'm not particular upset, that doesn't mean I have to find it good; git is a bit of a different scenario and the weighing is different than in this one, i.e. there is more benefit and it's arguably less crucial/counter to the intended goal. It would still seem to be prudent to at least warn at crucial operations that suddenly have to deal with unexpected input. Also it's something one can prevent easily in many cases whereas me being killed by a sun exploding is hard to prevent. And it's code in contrast to physics, code is always prone to bug risk, your numbers are just theory.