Just a few days ago I was thinking about the fact that on wp.org and here on the administration panel of the plugin directory the username cannot be changed. Just like in any other blog based on Classicpress or Wordpress for that matter.
I’ve always wondered what the reason is. Sometimes I proceeded to change my username directly through direct intervention in the database and nothing happened: the world did not end. So I have never found a valid reason (that was unassailable) for not allowing this modification, so much so that several years ago, I allowed my users to modify it via a plugin I created. With a reasonable boundary: if you changed your username the old one could no longer be used by anyone.
Yet this limitation persists. Give me, if you can, a valid and reasonable reason for this limit, which is also extended to the site administrator. Otherwise, I personally would remove it.
Furthermore, there is also a security issue to take into consideration, which has nothing to do with the issue of modification: the username is displayed in the slug that points to the author or administrator’s page, and is public. This allows an attacker to know at least the login username. And in the past, I have logged login attempts with my username on my blog. Precisely for this reason, I use a plugin that rewrites that slug, replacing the username with the nickname or with the display name or with a fictional one. This way, no one knows exactly what the connection nickname is when viewing the URL of the author page.
On this last point, it would be appropriate for the username to be used solely and exclusively for the connection and never be public, not even by mistake. And in any case, it was modifiable at least by the administrator.
I’m not 100% sure why this is the case and certainly on smaller sites it is unlikely to cause issued.
But, on larger sites it could be problematic. First, when changing login names the code would need to change and make sure that the new username added by the user was available, and therein lies a race condition problem on massive sites. How do you handle 2 users trying to change their usernames at the same time to the same thing? It could result in users being locked out or privileges escalated.
What you say could be true, but then the problem would also arise if two users register at the same time.
Furthermore, on social media which has millions and millions of users registered, changing the account name does not seem to be a problem. Sure, you could say that they have teams of developers who work to avoid critical issues, but I think in the end the danger is less than you think.
But let’s suppose that it exists anyway and that for this reason the username change is prevented, why is this also prevented for the site administrator? A scale of privileges could be established for this possibility. Or in any case, the administrator should be given the power to decide whether it is possible or not.
Now someone here might tell me: sure, but there are plugins that do it. It’s not a core problem.
Okay. Gotcha! You win, you who put me in a corner by putting on the table the plugin that saves the situation. However, the security problem that I mentioned remains: let’s assume that the username cannot be changed and that the reason is the one you illustrated (or someone else that I don’t know), why use the username in the slug of the link that points to the user page ? It is a username for login, and CP provides nickname and display name. Why use the username that should instead remain secret?
In my opinion, core developers should consider this possibility of modification: the username remains unchangeable. Okay. But at least let’s make sure it’s not public. However, this is not the case. Do you agree?
…in a db you can select as many primary keys you want. For users it’s the username and the progressive numeric ID. That is because two primary keys identify without a doubt a specific user (two dots can only be connected by a single line).
The other data can be changed because it was not set to be primary keys when db was designed and planned.
The use of the primary keys is also to connect the user table with all the other tables (in the pages list for example the user primary keys are used as author field) - and that reinforces the need for two primary keys to identify them (again the geometry principle stated above). That is why you can’t change numeric ID and username.
However your argument on safety/privacy is valid, and certainly things could be set in a way that the primary keys are not exposed to the public on the front end.
And BTW the one with the key identifies the index key and is the numeric ID. That is an index key and primary key.
The username is only primary key and is used in other tables as external key (and cross references to the users table).
I haven’t looked deeply at the code, but I think it’s not a core problem to make the username editable.
But it’s a breaking change because plugins can rely on username instead of ID, so it’s something not actionable until version 3 of classicPress.
About leaking of informations, the username is not considered as something that must be secured. Security is achieved through passwords (and as I do on some of my sites 2FA).
it is since it can’t be changed, in the db structure it might not be marked as such but it is used as such. and this might be a remainder of the previous times when wp wasn’t even born and there was the parent cms that originated it called b2 cafelog, then renamed to b2 evolution. It was tructured that way to supply a univoque identifying system. you can’t delete the username or the numeric ID for that reason. If you delete one of them basically you make the user profile broken. for same reason it was meant not to be changed. These are the real only two information needed to create a profile basically.
In reality, relying on the username is not a good way to design, precisely because it can be changed. The ID is the only data you should rely on when writing a plugin.
The fact that the username is not “sensitive” data for security purposes may be true up to a certain point. Not everyone adopts the 2FA approach, and brute force attacks on sites without adequate protection (absence of a limit on incorrect logins, xmlrpc active) and with part of the login known, can easily overcome the bland defense of a password.
My philosophical approach is that CP should do everything to protect the user’s account, eliminating any even minimal and remote security problems.
Then, of course, if one intends to create an impassable wall, he equips himself with a robust plugin that does that protection job.
1 Agree with you, but we can’t break plugins because those are poorly coded. They can do that, if you want to change we must first deprecate that usage and then remove in a major release.
2 I prefer to harden my sites using lower level tools, for example fail2ban. If it’s a security bug we can fix it in any version, but if it’s a security enhancement that can break plugins, we must follow SemVer timings.
As far as I know, none. I believe that the inability to change the username is a legacy inherited from B2/Cafelog or the first versions of WP. Probably, at the time it could have caused problems to change the username.
But assuming you create problems that I don’t know about, let’s make sure that the account name is confidential and not in the public domain. Also because, what’s the point of having a nickname available other than the account name and then also the display name?
Consistency would require you to have a nickname and an account name: the first acts as a public name and the second as a reserved login name.
Then, of course this does not make our site invincible to hacker attacks, but at least it is an extra spoke in their wheels.
It seems that the issue here is not really whether the username should be changeable, but that it’s typically the same as the user_nicename that’s used in URLs. (It’s very slightly different if the user uses an email address as their username.)
The solution to that seems to me to use the pre_user_nicename filter, so that when a user is created or updated, the nicename is assigned to be very different from the username.
This solution has the added benefit that it won’t break anything because it’s used immediately someone registers on the site. Reading reviews of plugins that offer the ability to change the username confirms my suspicion that that is fraught with problems because it confuses some other plugins (even though they probably shouldn’t be relying on the username).
You win, you who put me in a corner by putting on the table the plugin that saves the situation. However, the security problem that I mentioned remains: let’s assume that the username cannot be changed and that the reason is the one you illustrated (or someone else that I don’t know), why use the username in the slug of the link that points to the user page ? It is a username for login, and CP provides nickname and display name. Why use the username that should instead remain secret?
