Is it good or bad practice to allow a user to change their username?

Question

I have looked all over online as well as this site to try to find out more information regarding the security of this, but haven't found anything. In my particular case, the product is a website, but I think this question applies for any software that hosts a large number of users.

I know there are numerous websites out there that allow you to change your username, but at the same time there are many that do not allow it. I'm sure some that do not allow it may be just for simplicity, but possibly for security as well.

My question is just like the title asks:

From a security standpoint, would you say it is good or bad practice to allow individuals to change their username?

I currently cannot think of any reason not to allow it, given it is done properly (ie make it impossible for duplicate usernames, require inputting current password to make sure password requirements are still met regarding not containing username, etc), but I can't help but think there's something I'm missing.

I know there are advantages from the user's perspective to allow them to change their username. An example would be if they set their username to their email address and decide to use a different email address later. Instead, I'm curious of the benefits vs risks regarding the security of the application and login process if you allow them to change their username.

EDIT:

Some of the answers bring up good points regarding publicly-displayed names, but to clarify, the question is not regarding any public display name, but instead the unique username used to log in.

Answer 1

Many people have looked at the reasons not to allow name changes from both a security and a community standpoint. However, there are plenty of legitimate reasons to allow username changes, even if the username is separate from the display name, for example:

• Someone has changed their real life name or the name by which they'd prefer to be called, due to marriage, family situations, escaping stalking/harassment/etc., and so on

  Even in the case of it being simply a username, having to use an old name which carries trauma can further the trauma. Also, it is quite possible for a stalker/harasser to know their target's login credentials, and being able to change both parts of the credential lowers the attack surface; further, monitoring attempts at logging in to an abandoned username allows for building a legal case against a bad agent.

• People have decided to move forward on a gender transition

  Being forced to use one's "dead name," even in the context of a private username, is also very traumatic. (I can speak to personal experience on this one.)

• People have a username that they no longer feel suits them for whatever reason

  This has less of an implication for internal usernames but it's still better to err on the side of kindness, in my opinion.

These are all important for user comfort, and in many cases people would likely just create a new account with the new name anyway, so might as well support it.

Avoiding social engineering certainly is important but there are approaches that help to mitigate this, such as various forms of verification (as seen on several social networks), public-key cryptography, and profile indicators ("name last changed N months ago; name changed K times"). And, since this question has been edited to be regarding internal user names and not public display names, those concerns aren't even germane to the discussion.

Also, keep in mind that many attack surfaces provided by someone changing their username is also present for someone simply creating a new account, and if a username change option is not available then the user will likely create a new account - possibly using the same password as the old one and otherwise doing things that might lead to compromised security.

It is a good idea to maintain an audit trail of username changes and disallow the creation of new accounts that use a previously-used username (at least if the username was last used within the past, say, year), but there is no reason that the username should ever be the primary key used to associate data with the user account in the first place, because there are legitimate purposes for a username change and all account records should be normalized to an abstract internal-only ID in the first place.

Answer 2

I would say as long as they are not able to change their unique identifier. I.e. they can change the name they show up as, but that name is tied back to an unchanging user ID number (this will make your DBAs happier too). I'd also make sure user's couldn't change their name to an old name of another user (to help mitigate the scam potential Anders is talking about). So you would be looking at storing all names a user went by at one point.

Might be better to have a request for username change, to handle legitimate cases (like the email case), and not have a user-automatable method of doing it.

Answer 3

As mentioned, allowing users to easily change usernames (let's call it "display name" to disambiguate) makes it easier for users to dodge the consequences of harassing or scamming other users. If your site has a social aspect, maybe consider whether bans, blocks, reports, chat histories, etc will carry through a username switch (ie will a user be aware that they are talking to the same account, even though the name has changed?).

Another point to consider is anonymity or privacy concerns. It's fairly frequent that someone makes an account with their real name and then for whatever reason regrets attaching their real identity to it. Sometimes this is because they were caught bullying, but is often for legitimate reasons as well like over-sharing personal details of their life, or they become the victim of bullying. This recent question comes to mind as a different example:

I accidentally entered password for a website as a username for another website

In this case, submitting a service ticket to be reviewed by a human or allowing a limited number of account name changes sound like reasonable approaches.

Answer 4

We currently use your suggestion regarding individuals that reach out to us requesting a change, but it isn't as scalable due to the manual work and requires us to ask for answers to their security questions for verification.

That's definitely wrong. Not only you have to do it manually, but you're force to give security answer responses to everyone processing such requests.

If you want to keep control, then semi-automate it: Let the user do all the preparatory work, i.e., fill in the new name, write their reason (if you care) and answer the security question. Now, the help desk guys only have to grant or refuse the request.

---

Many reasons for and against allowing username changes have been given in the other answers. Just note that you may go the middle way: Allow a single automated change, e.g., once per year. This is generous enough to handle 99% of requests yet limiting enough to prevent most abuses.

Answer 5

I'm a little surprised that this hasn't been brought up. But I would assume that the reason many sites do not allow you to change your username is because it presents an issue if a user's account information is stolen as the attacker can now completely change everything on the account.

It is no doubt more complex to attempt to recover an account for an individual where their details have been stolen and everything has been changed entirely. Having the common piece of information that will never change makes it easier for a user to refer back to their account should they happen to lose access to it.

I think some of the other answers here have provided better solutions, but I'm not sure many of them touched on what you were actually asking which was regarding the security implications of allowing a username change.

Answer 6

I would argue that you're better off not allowing users to change their usernames, but it really depends upon your threat model. Here are the pros & cons to allowing it:

Pros:

• If a user's credentials are compromised on another site, allowing users to change their user name can make it more difficult to match up the credentials from the compromised site to your site, making it more difficult to perform a credential stuffing attack. Note that the user changing his or her password accomplishes the same goal.

Cons:

• As mentioned above, it makes it easier for users to perform social engineering attacks against one another on your site.
• You've added complexity to your site, which in turn increases the number of potential security bugs. For example, if you check for duplicates, now you've got a user enumeration vulnerability.

Answer 7

You're essentially balancing two competing issues, with a third factor chiming in. The first is security for the users on your site, changing a username is an easy way to trick other people in order to scam them. The second is that changing a username is an easy way to trick other people in order to get away from them.

People getting harassed would rather like to change their username as it's an immediate reprieve. People harassing others would like to change it as you can get by initial defenses. And the other factor is that more moving parts means more things to hit means less secure.

Your first course of action should be to decide which way you lean on here. Are you focusing on preventing scammers or are you trying to make the environment as safe as possible? Keeping in mind that making a safe environment could mean not automating a change, and there are other reasons for changing a username, both good and bad. That's for you to figure out based on what you know of your site. The second step would be to ascertain whether or not you can make a secure implantation for this.

At this point it's a flowchart. Would rather automate it, but can't do it securely? Don't do it. Having an issue with scammers and other social engineering attacks? Don't do it. Want to make it easier to change, and can implement it securely? Do it.

I would note that, as others have suggested, keeping track of usernames is a good idea even if hidden and available only to you (ideally hidden if changes are for security reasons) and increasing the username availability check to last three or so usernames across the site would be useful (and something else to make secure).

Lastly you mentioned scalability. As you scale up it becomes easier (read cheaper) to automate things you may not do for security reasons and defend against attacks another way, see Twitter for an example of that. If you hit that point then automate away, the sooner the better.

Answer 8

In my experience, allowing a change of usernames where it wasn't originally planned for makes auditing/logging slightly harder, especially in the inevitable circumstance where a dev from years ago decided to append the username but not the primary key to each log entry.

It happens, especially when you hire amateur/outsourced devs-- your logs will become garbage that you'll have to forensically reconstruct by manually cross-referencing dates if your log entries don't map the username to the original primary key at the time of the activity.

So, before you enable this, I would recommend you look over any logging solutions you might have and make sure they're recording the pk alongside/instead of the username so you can keep track of identity across username changes.

Answer 9

In my opinion, this is more a matter of strategy or architecture than one of security… As long as you make sure to keep an internally unique identifier for each user (eg. a DB unique ID, that will never change, but that doesn't need to be displayed anywhere), and a modifications history per user, users should be able to modify their logins or usernames. If you want to display the modifications history on user's page depends on the purpose and the usage of your piece of software.

I personally always find very annoying those services that impose that kind of arbitrary restrictions ("you cannot change your username", "you cannot change your login", "you cannot re-use passwords you already used in the past", etc.).

Though, we can make a difference between 3 cases (plus the general one):

1. offline software

2. intranet service

3. internet service

4. summary

1 - offline software

In the case of a totally offline piece of software, users should always be able to change their login. Everything is local here so there is no reason for prohibiting any change.

2 - intranet service

In the case of an intranet service, we most likely expect that users have an easy way to contact directly an administrator.

Maybe the safest way for changing login might be a manual procedure then. It's also probably possible to ensure a safe way to automatize the procedure though.

But, still, IMHO, users should be able to modify their login, and login should be totally independent from the user's unique ID.

3 - internet service

In the case of an online service, I think the login should always be the user's email address (or, maybe, in some cases, a mobile phone number, though, as soon as it's an Internet service, I'd expect my user's to have an email address and wouldn't recommend the use of a phone number).

In that case, sure, users should be able to modify their email address whenever they want, and, therefore, their login (that is, their email address).

Of course in that case, you should make sure to have a proper procedure, to make sure that when the modification request happens, there is a mechanism that allows to confirm that the requester is the account owner (verification email with confirmation link that has an expiration date, let's say 24h but, this depends on your case).

4 - summary

• users should always be able to modify their login
• user's unique ID should always be independent from login
• in the case of an Internet service, avoid "username login", prefer "email address login", with a validation/confirmation procedure
• in any case, it might be a good idea to keep track of the modifications history… whether you display it on a "user profile" or not depends on your specific use case

Answer 10

I don't see any answer checking the most important question:

Is the username a secret at your site, or not?

If the username is shown on a user profile page, or as the author on forum postings or is searchable in a members list, it carries no security features. Therefore, changing it or not has no meaning for security.

If the username is a secret, e.g. you have a different display name, or show the full name of the user but use a shortname or alias for login purposes - if the username is a secret than it impacts security as an attacker needs to know both username and password to access an account.

However, as users tend to re-use usernames and generally don't consider usernames as secret in the same way they do with passwords, the username is a weak secret. It also doesn't matter one bit in many attacks (MtM, keyloggers, phishing, DB hacks, etc. etc.)

So even if your username is a secret, the usability advantages (outlined in other good answers) far outweigh the security considerations.

Answer 11

If you permit users to use email addresses as login names you must allow them to change their login:

• If someone leaves an organisation they may well lose access to that address immediately and the new address may be assigned to someone else just as quickly. (I had to change ISP with no notice when they realised they couldn't connect my new house after all; the email addresses became available to others the same day). Even if you only use the address as a login name and never as for actual emails this is a significant and unnecessary vector for social engineering attacks.
• If you allow them to change the email address you use for emailing while still logging with the old address that's confusing, bad UX, and will lead to support calls.

Answer 12

There are quite a few points for and against it.

For example, a user may want to change the name to avoid being recognized because he noticed that googling his username from site A shows his profile on site B.

On the other hand, there is a point about not allowing to change it, so people can recognize him again on your site. Think of a forum with a well-known troll. People know how to handle him and don't give him attention. Until he changes his nickname. Of course, this is no real protection as he can register another username, but it avoids abuse by changing the name for every post.

If the nickname is some kind of a primary key, you cannot allow to change it. Think of an e-mail address or a jabber id. Some sites still allow you to change the name and you need to be careful doing so. If you consider changing your twitter nickname, you better register the old name afterward to avoid being associated with the new user. That's a point for locking the username for future use after account deletion as well.

A username is part of the login process, so changing it may stop a brute-force attack. Depending on the site even without the attacker knowing if the password is wrong or if the whole user does not exist.

In the end, I would think that the username should be unique and probably not changeable and locked after account deletion but you should provide a way to define a display name that is more prominently displayed than the account handle.

Have a look at SO, which uses IDs or good old ICQ which uses some numbering scheme. People need to use the display name in their contact list, because who remembers all the UINs of his friends?

Finally, your decision does not need to be ultimate. You can always change to the other model. Making fixed usernames changeable should be no big deal, fixing usernames which were changeable will probably need some explanation for your users.

Answer 13

We need to look at some of the possible options:

Why would the user want to change their username?
-personalization
-they have a stalker

Why would you want the user to change their username?
-versatility/personalization brings on loyal customers

Why would the user not want other users to change their username?
-the OG hipster excuse "i was the first soccerkid96 there can be no others"
-i really cant think of any other reason

Why would you not want the user to change their username?
-some sort of identity fraud? multiple phishing accounts named after xXP0rn$L@yerXx, highest score world record holder
-could be used as a backdoor for information or possibly a vulnerability for database overload or DDoSing

To avoid most unwanted issues, i'd recommend a unique static identifier for all accounts (unrelated to public account name), pay for username change, 1 username change per 5000 years, etc