# How secure is a 24 character mysql password?

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.

• Potential duplicate: security.stackexchange.com/questions/12114/… Commented Apr 27, 2020 at 10:06
• @schroeder Does mysql use AES? Commented Apr 27, 2020 at 10:15
• By the way, there is no such thing as "Wordpress SQL". It's MySQL. Commented Apr 27, 2020 at 11:28
• If you are worried about the password length, why not make it 99 chars? 500? etc. Commented Apr 27, 2020 at 15:21
• @SakibArifin not at all, since you should generate/save them with a password manager Commented Apr 27, 2020 at 23:59

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.

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

• It's not necessary to increase sid_length if you use 6 bits per character. 6 bits * 32 = 192 bits. Even if you had (an impossible) 2^64 active sessions at one time, the probability of guessing one of those session IDs would be 2^-128. ~ Also, hash_bits_per_character was removed. sid_bits_per_character appears to be its replacement. Commented Apr 28, 2020 at 21:53