Change user slug - do not expose user name

could be a cryptic random string

Read-only archive:

Author: Ina

Vote count: 14

Status: open


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 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.


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.


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 -

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!

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.


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).

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

This topic was automatically closed after 3 days. New replies are no longer allowed.