1. mike finley

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


  2. Jeffro

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


  3. DrewAPicture

    FYI: The default username on new installs is blank as of 3.7. See #24078.


  4. Jeffro

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


  5. Cam

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


  6. Melson

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


  7. mike finley

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


  8. tony

    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.


  9. SDU

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


  10. SDU

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


  11. SDU


    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.


  12. mike finley

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


Comments are closed.

%d bloggers like this: