Title: Feature request Last modified: August 30, 2016 --- # Feature request * Resolved [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/) * Since months i’m wondering how hackers guess my user’s names. I gave all my users nicknames which are different from their real usernames but hackers still are“ guessing” the right usernames and try to log in with them. * Today i found the problem: * if you enter the following URL: [http://mydomain.com/?author=2](http://mydomain.com/?author=2) you get redirected to: [http://mydomain.com/author/REALUSERNAME](http://mydomain.com/author/REALUSERNAME)( you can then replace the “2” by any number and get all usernames in the system) * REALUSERNAME is then the username to log into wordpress. * I suggest the following feature for your really great iThemes Security plugin: * Invent a checkbox “hide author pages” which doesn’t allow users to visit the author pages. So the real usernames are kept secret. Something the plugin [https://wordpress.org/plugins/remove-author-pages/](https://wordpress.org/plugins/remove-author-pages/) does. * Another solution would be to rewrite the URLs of the author pages, where the REALUSERNAME gets replaced by it’s nickname. * I really don’t know, why wordpress isn’t removing such a security risk in their core, but even if i write to the wordpress support, they don’t bother. * Best regards, Andreas * [https://wordpress.org/plugins/better-wp-security/](https://wordpress.org/plugins/better-wp-security/) Viewing 15 replies - 1 through 15 (of 16 total) 1 [2](https://wordpress.org/support/topic/feature-request-337/page/2/?output_format=md) [→](https://wordpress.org/support/topic/feature-request-337/page/2/?output_format=md) * [dwinden](https://wordpress.org/support/users/dwinden/) * (@dwinden) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255318) * Andreas, * [http://mydomain.com/?author=2](http://mydomain.com/?author=2) * should normally redirect to: * [http://mydomain.com/NICKNAME](http://mydomain.com/NICKNAME) * Assuming there is a Nickname specified (that is not equal to the username) for the user profile with ID 2. If author pages redirect correctly there really is no need for your feature request. * Also the iTSec plugin already offers 2 settings in the WordPress Tweaks section of the Settings page that more or less deals with this topic. These settings are “Force Unique Nickname” and “Disable Extra User Archives”. * dwinden * Thread Starter [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255379) * hi dwinden, i double checked it: sadly wordpress does not redirect to /author/ nickname (if provided), it redirects to the real username * so “Force Unique Nickname” does not help * and “Disable Extra User Archives” only kicks in, if an author did not write any posts. * “Disable Extra User Archives” would be the right option for eliminating this security risk, but it would be necessary to add a “disable archive even if author did write posts” checkbox. * or easier and better: “disable user archive if the url is called with user id”. meaning: author urls with ids (like ?author=1) would get blocked, author urls with (nick)names like /author/nickname would pass. * would it be possible, that this feature gets into iThemes security? * best regards * [dwinden](https://wordpress.org/support/users/dwinden/) * (@dwinden) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255398) * Ok let’s dig a little bit deeper … * Do you have permalinks enabled ? * Did you test in a standard WP 4.2.2 env using a default theme (like Twentyfifteen) and no plugins ? (I did). * I guess your result comes from your website which is using theme x and probably several plugins … Oh, did you buy your theme or was it a free download from somewhere on the internet ? * Could be your theme or a plugin is messing with the author URL using the author_link filter … * Have a look at the WP core code of the get_author_posts_url() method in the includes/ author_template.php file. * The get_author_posts_url() method returns the author URL … after the author_link filter is applied … * Find out why your author URL redirects to REALUSERNAME, fix that and then forget about this feature request. * dwinden * Thread Starter [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255403) * – i installed a fresh copy of wordpress 4.2.2 – i did not install any plugin– i did not change or install a theme (it’s the preselected Twentyfifteen) – i changed the permalinks to /%postname%/ – i created a new user “testuser” – after saving i changed the nickname and public name of “testuser” to “testuser-nick”– i logged in with the testuser – i created a new article – in the frontend i browsed to the new article. – in the meta data, i see “testuser-nick” as the author = > that’s ok – BUT: it links to /author/testuser (should be /author/testuser-nick)– Additionally if i visit /?author=2 i get redirected to /author/testuser (should be /author/testuser-nick) * did you try to create a new user? does it really work for you in a plain/clean wp install? * Thread Starter [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255404) * i checked the database and the problem seems to be, that the urls /author/username are generated through the field value of the wp_users table field “user_nicename”!!! and this is wrong, because you can’t change the user_nicename filed, only the display_name field. * so it’s a wordpress problem! * Thread Starter [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255407) * the user_nicename must be regenerated every time the nickname changes. but wp is missing this. i’ll write a plugin and report the issue * Thread Starter [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255413) * … or maybe this could be the new feature added to iThemes Security? 🙂 * [dwinden](https://wordpress.org/support/users/dwinden/) * (@dwinden) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255425) * I think the “Force Unique Nickname” setting of the iTSec plugin is already taking care of this … So this setting actually does more than what one would expect based on just its name … (Rechecking my testing env also revealed I was not testing in a clean WP env as I thought. iTSec plugin was installed and activated … apologies for the confusion). * Check the code behind the “Force Unique Nickname” setting in the force_unique_nicename() function of the class-itsec-tweaks.php file. Also notice the name of the function: * > force_unique_**nicename**() * So in a nutshell: * Author page redirect is using user_nicename field value from wp_user table. WordPress is not updating the user_nicename field in the wp_user table when updating a user profile (not in sync with nickname). However the iTSec “Force Unique Nickname” setting seems to take care of this … again apologies for the confusion. * dwinden * [dwinden](https://wordpress.org/support/users/dwinden/) * (@dwinden) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255434) * One last important detail (actually 2): * wp_user.user_nicename = sanitize_title(wp_usermeta.nickname) * So this is not (always) true: * wp_user.user_nicename = wp_usermeta.nickname * Example: * nickname = ‘bla bla’ user_nicename = ‘bla-bla’ * Also note that as there is no nickname input field in the create new user form the iTSec plugin “Force Unique Nickname” setting makes the Firstname and Lastname fields **REQUIRED**. The values of these 2 fields are then used to create a nickname( and user_nicename). * dwinden * Thread Starter [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255436) * hi dwinden, thanks for the info. and that’s great news, that iTSec is fixing the wordpress security hole in this case and nearly a perfect solution. * however: i’ll try to contact wordpress. i can’t believe they leave such a great security risk open to hackers for easy username gathering. * best regards, andreas * [dwinden](https://wordpress.org/support/users/dwinden/) * (@dwinden) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255440) * I totally agree with you that such security issue should be fixed in WP core. * BUT … take the WP Dashboard login screen as an example … There are (and have been for quite some time) some serious security issues there … which still are not addressed by WP core code. * The thing is WP core code is so flexible that all these issues can be solved using plugins and extend\correct\improve the WP core code. * So allthough I totally agree with you I doubt whether you should put any time or energy into this … just my thoughts * Anyway I think we can wrap this topic up. If you agree please mark the topic as ‘resolved’. * dwinden * Thread Starter [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255442) * i wrote an email to the wp security team. because this issue appears to be present and known since years, like you i don’t think that they will change anything. but i wanted to give them a chance to respond and fix this issue before i’ll spread it in the net and call attention to it by all wordpress users who don’t know about it. * surely plugins can be used for this. but i can’t believe wordpress is shipping with security holes and propagating the use of plugins to fix them. * each plugin itself could be a security risk, each plugin makes the site slower and harder to maintain. each plugin could have side effects. * i see we both agree with each other, but i have to try getting this one fixed at least 🙂 * Thread Starter [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255466) * [@dwinden](https://wordpress.org/support/users/dwinden/), i must add this one to this topic: * today i received the answer to my email to wordpress.com. please sit down before reading: * “ WordPress does not consider usernames to be secret, and as you’ve pointed out, actively uses them in URL slugs such as `/author/realusername`. For this reason we do not consider username enumeration via `/?author=1`, `/?author=2`, etc to be a security vulnerability. If you would like to change this behaviour, plugins are available in the repository to block such requests. “ * it’s unbelievable. wordpress is responsible for about 60% of all open CMS in the world. and they are shipping security holes with the intention to be fixed by third party plugins (which themselves could lead to other security holes). * i’m speechless…. * Thread Starter [ageibert](https://wordpress.org/support/users/ageibert/) * (@ageibert) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255467) * The complete opposite to wordpress’ point of view (ship with security holes, let users deal with it), seems to be the new drupal 8: * [https://www.drupal.org/drupal8-security-bounty](https://www.drupal.org/drupal8-security-bounty) * there the “User enumeration” is clearly on the list. A huge list and the involvement of the community. That’s how it should be … * [dwinden](https://wordpress.org/support/users/dwinden/) * (@dwinden) * [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/#post-6255479) * Indeed an uncommon point of view. * Basically what they are saying is that WP accounts are only protected by a password. So where generally speaking strong passwords are important for security, for WP it is even more important … And as the WP login screen allows endless login attempts no wonder the most popular attack vector for WP CMS is brute forcing… * If my bank told me there is only a password between internet criminals and my bank account (no matter how strong the password) I would go and switch to another bank immediately … 😉 * dwinden Viewing 15 replies - 1 through 15 (of 16 total) 1 [2](https://wordpress.org/support/topic/feature-request-337/page/2/?output_format=md) [→](https://wordpress.org/support/topic/feature-request-337/page/2/?output_format=md) The topic ‘Feature request’ is closed to new replies. * ![](https://ps.w.org/better-wp-security/assets/icon.svg?rev=3529351) * [Kadence Security – Password, Two Factor Authentication, and Brute Force Protection](https://wordpress.org/plugins/better-wp-security/) * [Frequently Asked Questions](https://wordpress.org/plugins/better-wp-security/#faq) * [Support Threads](https://wordpress.org/support/plugin/better-wp-security/) * [Active Topics](https://wordpress.org/support/plugin/better-wp-security/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/better-wp-security/unresolved/) * [Reviews](https://wordpress.org/support/plugin/better-wp-security/reviews/) * 16 replies * 2 participants * Last reply from: [ageibert](https://wordpress.org/support/users/ageibert/) * Last activity: [10 years, 11 months ago](https://wordpress.org/support/topic/feature-request-337/page/2/#post-6255480) * Status: resolved