Depending on the hash, brute force might be feasible: given a username with N letters (excluding numbers), the search space is only 2^N.

Allowing users to change their username clearly creates problems for your password management, and with most of the systems I work would cause other complications. Is it really all that important? IME the best security comes from simplicity.

@symcbean That's a fair question. I've seen systems that don't let users change their usernames, as well as systems that don't even let administrators change usernames. There are tradeoffs (often between usability and security) to these different approaches, but for this scenario let's say the ability to change usernames is a requirement.

@symcbean I agree that username changes are not ideal (that whole topic would probably warrant its own question), but if the username is linked to a real name, it may be necessary (people change names for all sorts of reasons - marriage or divorce are one example - , and keeping the old name for logins may not be desired).

Separate display and login names are OK.

When the username is changed, force a reset of the password.

@DeerHunter I also thought about that, but didn't but it in an answer, because it might also not be desired (the name is changed for a reason after all). For example, a divorced person may not want to type in the last name of their ex each time they log in. So if you do something like that, meaningless login ids would be better (but probably also not desired, as they are harder to remember).

store hash of lowercase pwd too. on username change, compare to hash of lowercase username

Why don't you just display some text in red that says "If your password is based on your username, there's a good chance somebody may guess it and steal your information."? I suspect this will take care of nearly every case. Programmatically enforced password complexity without attempts to educate users is this weird, ongoing nonproductive tradition. It's one of many reasons why nobody understands basic techniques for keeping their data safe, and why all these requirements and checks exist in the first place.

@JasonC the reason weird password entropy rules exist - "there's a good chance somebody may guess it and steal your information" is because in many cases it is not the user's information. If it was my information, then I would be legally and morally free to monetize it and I would protect the data out of self-interest. But a hospital worker can not sell patient records and perhaps needs some guidelines on minimal acceptable security.

@DeerHunter: that's true but if anything makes it harder. If the account has a separate display and login name, and you're implementing this kind of measure at all, then you'd want to ensure that the password doesn't match either of them. So even if the login name cannot change, the fact that the display name can change means we still have this problem to solve (or fail/refuse to solve, as the case may be).

@emory That justification only applies to cases where it isn't the users information. I'll spare you my thoughts on that in these comments.

Maybe just don't use usernames? Use emails instead.

Require a 'special symbol' to be used in the password and disallow special symbol for usernames. Problem solved.

@corsiKa This same problem exists whether you use an email address or a separate username for the ID.

@PwdRsch You have a problem with people using their email address as their password?

@corsiKa It's a common problem for a small percent of users. It tends to happen more on sites where people aren't as worried about the security of their account.

@PwdRsch Still not seeing the problem. If it's really a problem, disable the @ sign, say it's for technical reasons, and move on. Although personally, if someone wants to use their username as a password, let them. If you don't, they're just going to tape it on the keyboard anyway. Anything you do to make them smarter, they will find a way to outdumb the smart.

This isn't an answer (hence the comment), but if a user goes through all that trouble to make their password the same as their username, chances are they're going to choose an insecure password anyways, or just append a 1 to the end of their username, and set that to their password. Determined users who don't care about the security of their account will get around the rules

@corsiKa I would prefer to login by clicking on my own picture. Alternatively, the computer's camera can look at me and recognize my face and prompt me for my password. Or it could recognize my fingerprints. Why do we have userids anyway?

Related to @Jojodmo 's comment, this particular case involves a user pathologically trying to circumvent the security of their own account. Is password security just for security, or is it part of achieving compliance with some mandate? If its the mandate, you may have to explore some of the answers below. If its for security, at some point you have to accept that a user is actively trying to be insecure, and is willing to take extra effort to do so. There is nothing you can do to secure such a user.

Why would one want to change their username to correct-horse-battery-staple?

Since you probably hash your password using a salt (you should), you may or may not be able to do the same hashing function on the username to see if the username hash matches the password hash. Anyhow, for sensitive operations (changing pw, changing email address, changing username, etc.) you should always ask for password confirmation.

I'd also like to point out the elephant in the room which is you sending something sensitive over the network in plaintext form to begin with.

@CeilingGecko The availability of the information in plaintext to the server doesn't mean it was transmitted to the server in plaintext.