Assume I have dumped MySQL user list using

SELECT user, host, password, ssl_type FROM mysql.user;

The result looks like this:

| user             | host      | password                                  | ssl_type |
| admin            | %         | *blablablablablablablablablablablablablaa | ANY      |

Should this information be considered sensitive? Can an attacker use the password information to access the MySQL database? It seems the password is hashed, therefore it is not directly usable, but perhaps it can be still exploited somehow, e.g. to help creating rainbow tables for my server, or something like this?

5 Answers 5


Yes, it's sensitive information. It's a password hash leak.

Attackers will supply this information to a bruteforce application (there are some tailored just for MySQL) and retrieve the password.

Not only this, but the % on the host field means that if your MySQL port (3306 by default) is not firewalled, the attacker can access it as admin from anywhere.

Consider locking the admin account just for localhost, and never disclose a password hash, no matter how confident you are on the difficulty of breaking such hash.

  • 1
    I'm not familiar with the finer points of MySQL password tables, but the most popular way to connect to a MySQL server is via a filesystem-level socket. This is entirely immune to firewall issues.
    – Mark
    Commented Aug 30, 2018 at 23:30
  • 1
    In the new versions, it's true. But older versions used to open a TCP socket on
    – ThoriumBR
    Commented Aug 31, 2018 at 1:20
  • 2
    The % is just mysql's hostname check, it has nothing to do with whether a firewall is present or not Commented Aug 31, 2018 at 6:49
  • 5
    It'd also be worth noting that MySQL passwords are not salted, and being basically SHA1 hashes, they can be brute forced.
    – jjmontes
    Commented Aug 31, 2018 at 6:57
  • 5
    @jjmontes both salted and unsalted SHA1 can also be brute forced. Unsalted password can be "rainbow-tabled"
    – xDaizu
    Commented Aug 31, 2018 at 10:43

Not only are the passwords themselves inherently sensitive (as the other answers rightly point out as the primary risk) ... but the information that they contain is often sensitive as well.

Once the hashes are cracked, many passwords contain birthdays, children's names, phone numbers, de-facto answers to security questions, street addresses ... even Social Security numbers!

We remember what matters to us - and what is personal to us. This makes for passwords with great UX ... but they're terrible from a security perspective.

This psychology of password selection should be held as a constraint. Since many users choose passwords this way, they should be handled and protected accordingly.

  • 1
    Not sure this applies since it's the actual MySQL users table (I missed that at first too). Commented Aug 30, 2018 at 16:02
  • 1
    Fair. Though passwords for MySQL users are selected by humans, too. Commented Aug 30, 2018 at 16:19
  • 4
    Good info about the secondary information from the password leak - not often thought about the contents of a password vs just having a string of chars that are a password.
    – Connor J
    Commented Aug 30, 2018 at 17:08
  • The primary risk of leaked passwords is Account Take Over (ATO) attacks on other sites. If I see your email is [email protected] and crack your password, I'll try logging in everywhere else using those credentials: Citibank, WellsFargo, Walmart, Amazon, etc. Commented Aug 31, 2018 at 22:09
  • I agree. I didn't mean to imply that my answer should be considered the primary risk. My answer was intended to help people also consider that allowing users to select their own passwords means that you will necessarily be storing personal information about those users within the passwords themselves - nothing more. I've literally seen real credit card numbers in people's passwords. Not widespread - but the data is there. It's just not something on the radar of most compliance and threat modeling that I've seen. Commented Sep 1, 2018 at 1:03

It is possible to obtain the original password from a hash using a password cracking tool, such as John the Ripper or hashcat. These tools simply try a lot of passwords in a brute-force attack. This could take a long time depending on the complexity of the password.


Yes it's sensitive. An attacker can attempt to "crack" the hash through bruteforce attempts or dictionary attacks. In all the cases I've seen MySQL passwords are salted, but if they aren't a pre-computed hash table or rainbow tables can be used to accelerate the process

Furthermore, if that hash was obtained through a SQL injection vulnerability (Highly probable) it may be possible for an attacker to attempt to insert or update data in the table, depending on how the query was made. If this is possible, the attacker can simply add a new user or change the admin password hash with a hash of an already known password, skipping completely the cracking step


if an attacker is able to get the hash of a password, like in the way you described above, then yes it is possible to attempt to find the collision of that hash using rainbow tables if salting hasn't been used.

If salting has been used, then the difficulty of cracking passwords becomes much more difficult.

EDIT: Just to be clear - when I refer to salting, I meant it in salting can be done by an external tool / process, and simply stored in the database, and not that MySQL had any input in the process besides storing the values. Apologies to those confused!

  • I am not sure, I but think MySQL does not use salting. See Why are the passwords in MySQL (5.x) not salted?
    – Suma
    Commented Aug 30, 2018 at 14:33
  • I am afraid this is above my current MySQL knowledge level. I have no idea what MySQL does to the password before it is stored in the table. (I am talking about MySQL own users table.)
    – Suma
    Commented Aug 30, 2018 at 14:38
  • 1
    Pretty sure MySQL doesn't salt, but it also doesn't matter as much for MySQL as it does for websites. Rainbow tables are really only helpful for trying to crack large numbers of passwords at the same time. With MySQL you presumably won't see more than a few passwords at the same time, so rainbow tables are less relevant. Commented Aug 30, 2018 at 16:05
  • @ConorMancone Rainbow tables can still be useful for one password since you can compute the table before you have access to the password. Not as useful, but it's still a possibility. Commented Aug 30, 2018 at 17:37
  • 1
    @AndrolGenhald Presumably MySQL doesn't salt but uses the same hashing algorithm everywhere, so I'm betting you can find a pre-computed rainbow table for MySQL hashes. That would be super-useful. No attempt at cracking even required, presuming the password is simple enough to be on the table. Commented Aug 30, 2018 at 17:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .