Changing The WordPress Admin Username During Installation

One of the security tips you’ll come across often is immediately deleting the admin user after installation and creating a new user, then assigning that user the administrator role. This is something I wish the core team would address so that during the installation of WordPress, users would be able to choose their own username and select a strong password without having to go back and delete the initial admin account.

Something New Learned At My WordPress Meetup

While attending my local WordPress meetup, one of the new WordPress users in attendance mentioned the security tip of deleting the administrator account that is created during installation and creating a new user account that is then assigned the administrator role. The idea being that hackers try to login with admin as the username and then try multiple different passwords. I had mentioned that it would be great if WordPress enabled users to make this change during installation instead of having to do it after the fact.

Turns Out You Can

I discovered during a brand new WordPress 3.7 install that users were able to change the default username from admin, to something else. This is the first time I’ve installed WordPress in a long time which is why I didn’t know this change already took place. It also didn’t dawn on me because people are still sharing the security tip I mentioned above. This combination of the enhanced password strength meter and the ability to change the default admin user name during install saves new WordPress installation admins from having to go through a security step that has been preached about for years. As it turns out, users have been able to change the default username of admin for a number of versions. Based on research I conducted, this change has been in place since at least version 3.0.

WordPress 3 point 0

Why Are We Still Preaching This Security Tip?

With that being the case, why have so many fresh installs decided to use admin as the default username? Why do we continue to preach the security tip of immediately deleting admin and replacing it with a different username? One of the suggestions at my local meetup was to not auto fill the username field with admin and instead, force new installers to create their own unique username. This sounds like a good suggestion to me. When we tried to do a fresh install of WordPress 3.6.1 to see what would happen, admin was automatically filled in for the username. It seems to me that making this simple change would make WordPress installs that much more secure right out of the gate.

12 Comments


  1. wouldn’t leaving the admin account there, with a long ‘random’ string for a password, but with no permisions granted be more effective – the would be hacker finds ‘admin’ to attack, and isn’t going to get anywhere with it even if he strikes lucky with the password. (Coupled with the wordfence plugin to temporarily lock the ip out so it can’t mount a denial of service attack)
    (or does wordpress not give distinct responses for invalid password and invalid username?)

    Report


  2. @mike finley – I guess in a way, that would be like creating a honey pot. Effective but requires more steps. admin would still need to go through that process of creating a new user, assign administrator role to it, take away admin role from admin.

    This method just gets rid of admin in the first place. They’ll come up empty when trying to use the username of admin.

    Report


  3. @DrewAPicture – That’s interesting because the install we were using showed admin as being filled in already. Oh you know what, that was from 3.6.1, not 3.7.

    That is great news. I’ll add it to the post.

    Report


  4. @mike finley – While Wordfence is a great plugin, and one I wouldn’t be without, in the case of a Denial of Service attack it’s a lot less server-intensive if you can stop it via your .htaccess before it gets to your wp-login.php. For instance if you are the only one who ever needs to login then just whitelist your own IP(s) and send everyone else – bots included – to a static 401.html page.

    Report


  5. Creating a new Admin user and then deleting the first account also removes user ID=1 from the table, which is safer too.

    Report


  6. @cam unfortunately .htaccess rules are not really a useful tool for most of the sites – too many users who need access to wp-login and from more than one location (not to mention ISPs that randomly change IP addresses!). I use either cloudflare or incapsula to reduce the problem (which further complicates using .htaccess).

    Report


  7. I use fail2ban on my servers, along with WP Fail2ban plugin. After just 1 attempt to log in with admin, I place a permanent iptables ban on that source IP.

    None of my users have a legitimate reason to log in as admin, so 100% of those attempts are attackers, and this just removes the problem at source.

    Report


  8. @mike finley

    Mike, in many cases people will disable the “wordpress notifications” that specify an error with login attempts. This is done to prevent scripts from guessing usernames or passwords. Don’t forget a script can be programmed to loop through combinations pretty easily and then grab the code to self check if it gets a hit.

    Once it gets a “valid” username it will just keep looping passwords. Having a “non-privileged” admin does not truly gain you benefit over having none to find at all. Quite the opposite, in fact is that if they think “admin” is valid they may hit it with 10,000 hits trying passwords which can cause server load issues.

    If they get a 404 or username does not exist then they may stop entirely until a different username found to work.

    For string randomization I actually create a sentence, then pass it through a hash generator over at whatsmyip.org. the likely chance someone is gonna guess it is pretty slim. Then I store them using KeePass (free RoboForm)

    Report


  9. @mike finley

    Htaccess rules are still quite valid methods for restricting and controlling access to a website. What truly matters is the manner in which they are implemented and managed.

    Saying htaccess is not useful is like saying “having a lock on my house is not useful either”. Htaccess has been around for a while and will continue to be here for a long time. It is quite use for blocking spam and controlling site access.

    Show me a single WordPress security or caching plugin that does not implement htaccess files.

    BulletProof security is almost solely based upon htaccess rules, such as changing the htaccess file name, creating separate controls for regular sections and admin and much more.

    I use specialty htaccess code all teh time in order to implement specific functionality.

    Report


  10. @tony

    Banning after a single attempt could actually get you into trouble. I personally ban after more then 5 from the same IP address IF it is a foreign IP.

    The particular reason for this is the potential for legitimate traffic. If a user spoofs the IP Address from let’s say your hosting server (or they attack from your own hosted network), then you could risk banning actual customers.

    So even if %100 of hits going to /admin files are hackers that does not mean a hacker is not on the same IP address as real visitors.

    You might be better off to limit access to anything you can to your own specific IP addresses and “deny all” from wp-login and admin sections, then allow what you need.

    you can control your own access if you are the only one and give yourself a little leeway for hosts that change your IP address by dropping the last octet when you ad your IP range into htaccess.

    Report


  11. @SDU if I don’t (and can’t) know the IP adresses that valid users are going to be using tomorrow (because they (or I) may be away from their base location, and still need to login) then I don’t see how a .htaccess rule can determine who is a valid user. Having cloudflare or incapsula in between compounds this problem, as all ip addresses seen by htaccess are cloudflare/incapsula addresses not the originator addresses. (I know there is a module to get round this, but its not necessarily installed on all servers.)
    I have used .htaccess in the past where I did know in advance what addresses were valid.

    Report

Comments are closed.