Not downvoter. It does prevent impersonation wherein someone is able to copy & paste their own salt/hash combination into other users entries, impersonate the user then revert the data changes, but someone with such powers probably has more direct means to act maliciously.

@Damien_The_Unbeliever Hashes can't be copied and pasted like that. Hashes are stored purely server-side. Furthermore, websites do not do authentication by taking hashes. They do the hashing themselves. There is no "input hash directly" option. I'm not sure how this attack vector makes sense.

I have two problems with your answer: first, your representation of a password is wrong from the application point of view: a password is NOT considered unique (that why you need a distinct salt with every password).

Second problem: this isn't "security theater", at least not taken in isolation. The addition of the user name to the hashed key doesn't help with security but it doesn't hurt either. As long as the salt is correctly generated, the algo is pretty much correct (athough, of course, it isn't sufficient for ensuring security of the password, but that's something else).

I very much agree with @Stephane but I will also say; even if the salt is a username addition so what? it is not the best, but is better than $salt + $password. as people have said it reduces comparison if someone got access to the salts. you would have to crack each password individually even if they were the same. Also your argument of not secret is obsolete; you know the a lot of hashes for systems have the salt next to the hashes, ask your self why.

Nitpick: a salt does not have to be randomly generated to be secure. The only requirement for it is to be unique, so it won't be used for a password hash elsewhere. And although using a generating the salt using a CSPRNG is certainly the easiest way to ensure that requirement is met, you could achieve it using other means, e.g. by using the username+site name as the salt.

@TheHidden "... it is not the best, but is better than $salt + $password." - No, it's not better; it doesn't add anything. That's pretty much the point of this answer.

@Stephane You say it isn't security theater, then you say "the addition of the user name to the hashed key doesn't help with security". Something that appears to be a security feature yet doesn't actually help with security is literally the definition of security theater.

@SeanBurton It really depends on the context (which we don't have). For instance, if there is no way to obtain a globally unique salt but we're sure there the username is blobally unique, the using username+salt is a valid way to make sure the salt is unique (you can simply use a counter inside the user's record). It's just a technical quirk that cannot be explained with the very limited facts we have at our disposal.

@Stephane Security theater, as I understand it, is defined as something that neither helps nor harms security. It just looks good, but does nothing.

That isn't how I understand it. For me security theater is when there are measures in place that are designed to make the public/user/management feel secure while not actually implementing effective security. That isn't the case here: as far as we can tell, using the username along with salt isn't strictly necessary for the security of the password but it doesn't make the system insecure or even make it feel more secure: it just adds some properties to it (some of which might be desirable but out of scope of the question)

@marcelm as Stephane points out, we have no context to the OPs salt, what if the salt is 12345? are you really telling me that adding the username would do nothing? Yes the answer mentions a randomly generated salt, but the OP does not. You need to consider the likelihood that it is not a unique salt. In which case, yes, it does add to it. although I appreciate that it is still a ridiculous position to be in that this question/debate needs to have arisen.

@TheHidden Technically, in that case, it wouldn't be a salt by most definitions, and the username would be acting as the unique (but non-random) salt. So we would be comparing H(non-random-salt + global-pepper + password) with H(global-pepper + password), at which point the answer would be "username as salt is better than no salt at all". Which is pretty much what Steffen Ullrich's answer says.

@IMSoP Yes I agree with that, pretty much what I was trying to get across as to why I disagree, some what, with this answer. You got to the point a lot better than I.

@TheHidden A salt must be random (or at least unique). If it is 12345, then there is a different, unrelated problem with the password hashing scheme. As OP didn't mention anything about that, I will assume the salt is an actual proper salt.

@forest I assume by "12345" they mean that their "salt" might be constant across all rows... though it's somewhat questionable if it could be still considered a salt at this point, because that'd make it susceptible to exactly the kind of atttacks salting is supposed to prevent (or at least inconvenience) in the first place.

@Cubic Indeed it would not be a salt in that case. It's a bit strange to say that the problem with the answer is that OP might be talking about a contrived scenario where the salt is not a real salt, and the only unique thing in the entire database is the username.

^ yes, this is what I was trying to say. I have seen people use salts with the only uniqueness being the username added to it. the username creating the uniqueness that is required for the salt to then be defined as a salt :) if you get me

@TheHidden In that case, why not just use a real salt? This scenario is so contrived that I can't imagine why it is relevant. Sure, if it's literally impossible to use a real salt, then a username would be better than nothing, but there is virtually (literally?) no overlap between those who have too little control to start using a salt, but enough control to mix in the username.

@forest well if someone is asking a question about a poor security practice, would you not presume other poor security practices? I mean in the field of security feed on how people can perform the worst practices (penetration tester, it feeds me)

@TheHidden Because I am answering the question at hand, not another hypothetical question. It is for the same reason that I do not describe why you shouldn't be using MD4, or why TLS is important. I only added a brief passage at the bottom regarding good practices. Sure, it's possible that someone who has a poor security practice is also using MD4 for hashing or generating the salt using an LCG, but why should I assume that? Same with assuming that they do not use a real salt (despite OP saying it is a salt).

@forest yes I do see your point, I suppose the lack of detail in the question only leads me to more questions and assumptions. I have changed my vote with the modifications made :)

@Stephane I provided a footnote explaining the definition of security theater which I am using. Looking it up, it appears there is no formal definition as it was just coined by Schneier in one of his books. I have also edited my answer to clarify that a password is not necessarily unique.

+1 for hunter2 reference. All these years later I still occasionally share that for the lols; was starting to think I was the only one.