Your DB name is not visible, but it might leak out of error messages.
So you need to review your PHP.INI settings to verify that under no circumstances are errors dumped to standard output, or logged in files reachable from the outside.
A cracker would normally need an (username, password) pair in order to login to WordPress. They might try for the username of
admin and just try to crack that password. So, using a random string is a very good choice.
And transmitting passwords to a WordPress installation is a thankless task; a GPU cracker would not help unless they somehow got their hands on the database with the hashes. Having one billion passwords per second ready is of little use if you can only transmit ten of them at most in that same second.
However, there are other possibilities. For example they could try to hijack the session. Once you login, the password is no longer sent on the wire; rather, a cookie is released to the client which will subsequently inject it in all requests. All requests including the cookie first established by the admin (or any other user) will be treated as coming from that user, with no further need for a password. Which is why security conscious sites will often ask you to re-authenticate before you do something important from a security standpoint, such as modifying the account details.
Guessing the cookie is normally hard as well, since it should contain 128 bits of entropy (making it at least as hard as guessing a MD5-hashed password, even if 2x to 10x faster). This means ~1040 attempts. On some setups, though, this content is considerably lower, or can be made lower by a knowledgeable attacker.
To reduce the chances of a successful session hijacking in PHP, you could:
- for older PHPs: set
session.hash_function to 1.
- 7.1+: increase
session.sid_bits_per_character to the maximum of 6
- 7.1+: increase
session.sid_length from the default of 32
- Set the inactivity timeout
session.gc_maxlifetime to a low enough value (but not too low to avoid harassing users!).
- On non-Debian-based distributions, ensure session.gc_probability is more than 0 and this probability, divided by
gc_divisor, is above 1-2%. For sites with less traffic, you will want higher probabilities.
- On Debian-based distros (e.g. Ubuntu), very important, verify that the cron job really cleans the session directory. To be sure, set both
gc_divisor to 1 and verify that the path indicated by
session.save_path is being cleaned.
- Ensure that
session.entropy_file is set to
/dev/random, which can be remotely depleted). This is actually more important than increasing the PHPSESSID length.
- There was a plugin that verified the authenticity of a cookie's provenance, but cannot say as its availability or possible replacements.
Whatever else you do, do not forget to periodically check the logs for anomalies (there are plugins for that too), and always keep full and adequate backups (ditto).