eddyferns

I did a couple of times plugged the leak by delving and altering themes code.

Was wondering if there was one fix for this issue as all other attempts to hide usernames comes to a nought.

Just using Twenty Twenty-One for test purpose. There are other themes that provide hiding author names as an option. In themes that don’t there is work to do.

Thanks for your input.

It’s an Nginx server.

Where can we find the code in NFW library that redirects the mentioned urls?

Twenty Twenty-One.

Excellent!

No users revealed.

Well, the request is not for private support if you are able to recognize. But since you asked for the website it is not permissible for me to disclose it in a public forum for various reasons. It is not a demo or a test site.

Another very popular plugin’s support requested me to contact on their website support form due to the privacy requirement of the site. And they assisted from there on for free voluntarily.

Kindly recognize the difference.

As this is a client site I cannot reveal it in the forum. Perhaps in a private email.

Just to let you know I have seen that in the ‘From’ field the email address is [email protected] which actually does not exist.

• This reply was modified 4 years ago by eddyferns.

The reveal of a user name in itself it not a security risk. But the actions of looking for it is in it self an indication that someone may be up to no good, and their next actions MAY be a security risk.
As I mentioned revelation of a username is a security risk, and varying depending on the nature of the account. For instance, who would want their usernames that is associated with financial transactions publicly available. When in conjunction with weak, stolen or phished passwords it can be damaging. Exposed usernames is an open invitation for a brute-force attack.

One can say that revelation of a password is also not a security risk since we don’t know the username. Usernames and passwords are a security risk because of the threat that is associated with it.

Indeed RSS feeds have the Display name – which defaults to login – but isn’t login id
But the Display name is the login ID name when another Nickname is not created and the Display name is the default Nickname.

If you are worried about exposing login ids, then you also have to consider most themes also display the Display name.
The security risk is reduced when Display Name is the Nickname and the Nickname is not the login ID name. Some themes provide options to hide authors or display names. Those that don’t, slight modification in the theme code will remove the display name.

Again if that is a concern, then perhaps build a rule that stops the Display name being equal to the login name.
Not necessarily as this can be easily achieved in the WordPress Dashboard. But of course for sites like E-commerce with many registered users it makes sense from an admin perspective. Those who overlook this risk the Two-Factor authentication then becomes relevant.

• This reply was modified 4 years, 1 month ago by eddyferns.

If you would like a specific discussion on the plugin I think it is best is you take it to the plugin support page.
I just took to the plugin instead of working out the code for it was a quick way to learn how your code hides usernames.

In order to understand your perspective on “no security value” of hiding usernames read through the content of the page as your plugin name indicates otherwise.

So it was about the subject matter not the plugin.

I would be very interested to hear from you on the specifics of your testing specifically your testing with WP Scan.
As I had already mentioned about the three tests, WP Scan was able to obtain usernames by its RSS generator, which I think is the same as test 2. The plugin passed WPintel test on Google Chrome.

Thanks, yes I closed that plugin as it had only a few takers I will update the readme
You are welcome!

I heard that in case of a redirect the bot scanners do not follow the link but instead pick the author name which then doesn’t meet the security objective.

If that is the case wouldn’t it be better to return a blank page instead?

Appreciate your interest in the matter.

You have already addressed the password security issue and the purpose of your plugin on your plugin page:

“Stop User Enumeration is a security plugin designed to detect and prevent hackers scanning your site for user names.

User Enumeration is a type of attack where nefarious parties can probe your website to discover your login name. This is often a pre-cursor to brute-force password attacks. Stop User Enumeration helps block this attack….”

The plugin did not block WPScan. Even without a scanner the plugin did not prevent me from obtaining usernames.

Usernames with weak, stolen or phished passwords has always been a security concern.

If a hacker does not have a valid username brute-force password attack is pointless. And moreover it will keep much of the attacks away.

Non-Security reason? I am not sure how this is relevant given the nature of the discussion.

For the VPS, there are server logs of all the IPs targeting or visiting the server. Rate limiting is another measure that can be implemented.

For Shared Hosting, you will need to update your plugin page since Fullworks Firewall is permanently closed since 28 April 2020.

Since you say there is no value in hiding usernames then why the “stop-user-enumeration” plugin?

While reviewing your code I thought of trying out your stop-user-enumeration plugin.

I was still able to obtain the username and the display name though it passed the 1 & 3 tests.

For https://domain.com/?author=1, does NFW redirects to the home page?

The rewrite rules worked with Nginx as I tried it myself. But Nginx strongly recommends against it.

As long as NFW doesn’t involve the server I think that should be alright.

Thanks for the code.

Will try to see how it works.