How secure is a 24 character mysql password?

Question

I recently set up my WordPress blog and I changed the password of its mysql database to a 24 character randomly generated password. I have a few questions about the database:

1. Is my database name visible?
2. Does a hacker need both the database name and the password to crack it?
3. How long would it take to brute force it?

I searched Security.SE but couldn't find any specific questions about wordpress sql security. This wordpress.org page explains how databases are created but nothing specific about its visibility.

Answer 1

Your question depends on your setup.

1. I don't know

2. If a potential attacker wants to login to your database, for sure he needs your name as well as your password.

3. If a potential attacker compromises your password hash (let's imagine with a weak hash algorithm, like MD5) he could test about 8-10 billion hashes/s with one Nvidia GTX Titan X (offline).

Let's say you use a 24-character password with A-Z, a-z, 0-9. Now the number of combinations can be calculated by Character-Set^length. In your case the equation is"

62^24 = 10^43 Combinations (Tredecillion).

If you divide this by 10 billion hashes/s you will get approximately a worst case of 33 septillion years to crack this password.

In other words: no one today is capable of bruteforcing a password with 24 characters hashed with a weak algorithm like MD5. If you use a hash like Sha512 you could reduce the Hashrate of the GPU down to million or thousand hashes/s.

Answer 2

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 ~10⁴⁰ 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_probability and 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/urandom (not /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).