Again, this is currently not possible.
And even with a system in place that limits log-in attempts, it can still be forced in (guessed). All one needs is to try from multiple sources. An automated system or even a collective attack could generate millions of locations.
If you suggest that the account be locked to prevent from any and all sources after failed log-in, then you have just given the attacker an exploit; away to keep you out.
It is not easy with user locks (impossible unless you are willing to wait several years / use easily brute forced passwords for the admin account... in which case you are asking for it). User locks are already available in the ACP area, the Super Admin account is locked regardless of the location for 15 minutes (try the wrong password 5 times, the admin account is the locked for 15 minutes)... This is core functionality, and it's quite a long lock (it would be a tedious exploit to lock this every 15 minutes continuously, but a simple lock of 30 seconds would still significantly reduce the chances of successful brute force and be more human friendly)
However, there a no locks on the front end, so if you don't use CAPTCHA or use QA,
it's then possible to brute force the admin account, gain the password and use this password to gain access to the ACP.
Even with CAPTCHA, since most common ones are programatically solved, it's still fairly easy to brute for the admin account.
Hiding or obscuring the Super Administrator username is not really going to stop a malicious user (it does nothing to stop malicious users from figuring it out).
By cycling through the member users (listed on the forum) it possible to use these names as a hit list, progmatically attempting on the ACP area each until the response "incorrect password" is achieved.
Since the Admin area gives a different response when using a non admin account:
The requested user 'testuser' could not be found.
compared to using an incorrect password (with the correct admin account):
Incorrect password. Please try again.
Once you have this response, you know the admin username... you can then use the username to brute force the front end (since there are no user locks here)
If a CAPTCHA is used, the CAPTCHA appears after 5 attempts, if this CAPTCHA is a QA, the user only needs to log the QA Questions and Answers, then the bruteforce can commence without issue
If no CAPTCHA is used, it's possible to brute force without issue.
This I would recommend:
3) Password Protect AdminCP ( admin.php )
It wont stop the Admin account being brute forced, but it will stop anyone using the ACP area.. you could do that, or simply take out the superadmin account from the config.php file once you have finished with the ACP area
I would also strongly recommend user locks (they only need to be small user lockers) on the front end to, particually if you use no CAPTCHA or simple QA CAPTCHA (For the sake of all XF forums, I hope this is applied to the core soon)