Change user slug - do not expose user name

[discobot]

could be a cryptic random string

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: Ina

Vote count: 14

Status: open

---

Comments

Can you elaborate on the purpose of this - I’m thinking you’re thinking of security? If so, it would probably take less code to force users to login via email address rather than username, while still leaving the usernames reader-friendly on the frontend.

~ posted by Mike

Indeed, the purpose is security. I actually mean to change the user’s nickname (= user slug, which happens to be the user’s username by default) automatically to something else.
I am not happy with all author pages exposing the author’s username (= nickname = login name) in the frontend (or to bots).
Of course, the nickname is editable in the backend, but not for users who just sign up and/or have no access to the backend. Think about websites with lots of registered authors or membership sites.
Not everyone knows about changing their nickname in order to hide their username a.k.a. login name in the frontend. I myself did not know for quite a while what this nickname actually is used for.

Regarding the automation of setting the nickname: One could use the display_name instead of a cryptic string but that would require to have at least the first_name available. Which is not the case as long as it is not a required field and also included in the registration form. And you would have to check it against the username.
So I think it is best to make the nickname a unique cryptic string of some sort when a new user is registered. This is the easiest solution I came up with so far and have it included in all WP sites I build.

Your idea with using only the email address for signup is, of course, a quicker workaround but here an additional question must be asked:
How many people would acutally prefer this?
If it’s on me, for the login I would rather use a username that nobody knows instead of an email address that people might already know.

~ posted by Ina

Thanks for elaborating. I do believe using an email address to login is better practice than a username, but I don’t have any “proof” so we’ll just call it opinion. However, I’d never leave security decisions up to “what will people prefer”. What people prefer is never the most secure. Of course, there’s the UX aspect, as well; showing usernames is much better than obfuscating them, again, in my opinion.

~ posted by Mike

Actually, I would prefer it if the unique identifier was NOT the email address: I think there are many legitimate reasons to have more than one account for any user, like having on admin account and one as editor. Of course, for public accounts there should be some restriction. But admins (or others entitled to do so) should be able to create multiple accounts using the same email address.
So, for me, some kind of random initial “nick” would be okay, if it includes an explanation to the user why this is used and why they should not use their real names.
May be, the username should be (optionally) generated as random strings. With password safes like KeePass there should be no problem.

~ posted by Andreas

[tradesouthwest]

I too understand the “security” matters behind this request. If I am a hacker and I know your username, I now have 50% of what I need to get into wp-admin. BUT, I also feel this is plugin territory and that hardening, in general, is part of “Reason for Strong Passwords.”

This issue can also be resolved WITHOUT core updates. Urls are the most vulnerable to identifying login names example https://webpopulous.com/plugins/individual-profile/?profile_id=1 can be a valid replacement for the same uri that has the name publicly exposed.

Plugin authors would be the most lack-luster in making good decisions about DISPLAYING user nicknames or names that expose the administrator’s login name. So maybe education about using esc_html($user->display_name) esc_html($user->user_login) etc.; should be encouraged to use the least exposed object.

[maiki]

Is there prior art as an alternative? “Username as slug” is such a ubiquitous pattern for web apps, I’m having difficulty imagining how an alternative works.

[jssmith]

I simply force the use of “email address” to login. That way - it is at least hoped that the “display/user name” are not too similar to the email used to create the account.

Some may already use a plug-in for this, while I have coded a “drop-in” module - which is “hooked in” by htaccess mod_rewrite directive, and the module then “includes” wp-login.php after doing its checks.

For those curious, here is that project link: AFWS/WP-Login-Protector: A small, drop-in module to use with your WP-based site which does not require any coding changes or updates to your WP-installation. Just upload to your main "public" folder, and add a one-line .htaccess directive - pointing to it. - WP-Login-Protector - Codeberg.org

I believe there was a purpose for being able to use the “poster user-name” as a means to finding all other posts by that same user.

I also stay clear of themes and/or templates which cause to be displayed or even mentioned the author’s email-address, or edit out the offending code myself!

[jssmith]

It only takes a few well-written htaccess directives (if the hosting account is allowed such abilities) - to block those types of attempts. It depends on the CMS if these methods will work with it - or break it. However, for the “_press’s”, “pretty-links” (otherwise known as “Search-Engine Friendly” links) are the main mode. Therefore, such things as “?author=???” and other “dirty links” are no longer necessary: Requests for them can be filtered out and blocked.

Anyway,

MOST of the hack-attack types are tending more toward trying to exploit XML, JavaScript, CSS, and image loading weaknesses - as well as sending malformed headers and header fields (at least, according to many of my archived access logs).

[viktor]

This petition will be closed. There are solutions to do this already.