wp_kc

It is very simple to do, and it has nothing to do with the Better WP Security plugin.

If you have an account with administrator privileges you can create a new user, with any name you want, and set the new account as an administrator.

Then if you also want to get rid of the old administrator account, that is simple too. Login with the new administrator account you created and delete the old administrator account. It will ask you what you want to do with the posts that belong to the old account. You can select to assign them to the new administrator account.

Very simple. No database knowledge needed.

Technical background:
The only thing the rename administrator account feature of BWPS does is change the name and the database id number of the administrator account. That is all. You can do the same thing yourself using the technique above. The BWPS plugin just makes it faster to do.

Always remember… if you have FTP access to your web site you can temporarily rename the folder of any plugin to disable it. I usually rename the folder to have a dot as the first character of the file name. This trick effectively hides the folder from WordPress.

In the case of the Better WP Security plugin you can rename the folder from better-wp-security to .better-wp-security

You will then be able to log-in to the WordPress admin area the usual way.

Then, after you have logged in to WordPress, keep your web browser opened on the WP admin area and rename the plug-in folder back to it’s original name using your FTP program.

Next, go to the plugins menu in WordPress, if WordPress did not already re-enable Better WP Security, you can do it now. Since you are already logged in, you don’t have to worry about the plug-in booting you out because of the “Hide Backend” settings.

Now you will be able to generate a new secret key.

Update: This issue has been fixed in Version 3.5.3

Sorry I did not get back to you sooner. The BWPS section of the .htaccess file should start at or near the top of that file with this…

# BEGIN Better WP Security

…and it ends with this…

# END Better WP Security

Any line that starts with # is just a comment to help document the file. In between those two comments is the section that denies access to IP addresses. It start with something like this…

# Abuse bot blocking rule end
# End HackRepair.com Blacklist
Order allow,deny
Allow from all

(note: If you do not have the HackRepair.com blacklist option enabled, those first two lines wont’ be there, just the last two)

These lines are followed by all the IP address banning directives. For example…

Deny from 118.1.70.142
Deny from 118.101.93.229
Deny from 118.108.100.22

When you don’t see any more “Deny from” lines, that is the end of that section and the start of something else.

I’ve rethought my original advice. It looks like it is a bad idea to add your own stuff in between the “# BEGIN Better WP Security” and “# END Better WP Security” comments. So, just add your stuff after the “# END Better WP Security” comment.

For example, let’s say you are seeing IP address 123.123.123.123 still accessing your web site even though it is in the ban list. The end of the BWPS section of the file should look like this…

# END Better WP Security
SetEnvIf X-Forwarded-For 123.123.123.123 denyclient
deny from env=denyclient

You can add as many of the “SetEnvIf X-Forwarded-For” lines as you want. Just replace the IP address with a different one and make sure you have the “denyclient” part after it. Make sure you always keep “deny from env=denyclient” as the last line.

Here is what this is doing: “SetEnvIf” (Set Environment variable If true) will set a temporary value if the test condition following it is true. “X-Forwarded-For” is a bit of text that is sent by proxy servers that gives the actual IP address that is making the request for a web page. The “denyclient” can be anything, it’s just the name of the temporary value being created if the test was true. The “deny from env=denyclient” tells the web server to deny access if any of the previous tests came back as true. (It is checking to see if an environment variable named “denyclient” exits. if it does, it means one of the IP tests was true, so it denies the connection.)

I hope that helps.

No. It is not IP spoofing. It is just an attacker using a proxy server. Read this instead…

https://en.wikipedia.org/wiki/X-Forwarded-For

BWPS is simply not adding the correct commands to the .htaccess file to stop the attacker.

Handoko, try reading my posts above. This is happening because the attacker is using a proxy server and BWPS is not using the correct directive in the .htaccess file to stop it. BWPS needs some redesign to fix this problem.

Also, banning an IP address forever might not be the best policy either. If someone is attacking with a dynamically allocated IP address, as soon as that address is recycled and used by someone else, they are banned even if they are a legitimate user.

It might be better to turn off the ban permanently feature and just use a really long ban period (like 24 hours). Since BWPS seems to actually work when it is managing the lockout (as opposed to a .htaccess directive) you should get a good compromise.