Mixing
Is password information dumped from the MySQL user table sensitive?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
20
down vote
favorite
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?
passwords mysql
asked Aug 30 at 13:13
Suma
1,036710
add a comment |Â
up vote
20
down vote
favorite
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?
passwords mysql
asked Aug 30 at 13:13
Suma
1,036710
add a comment |Â
up vote
20
down vote
favorite
up vote
20
down vote
favorite
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?
passwords mysql
asked Aug 30 at 13:13
Suma
1,036710
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?
passwords mysql
asked Aug 30 at 13:13
Suma
1,036710
asked Aug 30 at 13:13
Suma
1,036710
asked Aug 30 at 13:13
Suma
1,036710
asked Aug 30 at 13:13
Suma
1,036710
1,036710
add a comment |Â
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
38
down vote
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.
answered Aug 30 at 13:28
ThoriumBR
16.4k44060
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
Aug 30 at 23:30
1
In the new versions, it's true. But older versions used to open a TCP socket on0.0.0.0.
– ThoriumBR
Aug 31 at 1:20
2
The % is just mysql's hostname check, it has nothing to do with whether a firewall is present or not
– nullability
Aug 31 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
Aug 31 at 6:57
5
@jjmontes both salted and unsalted SHA1 can also be brute forced. Unsalted password can be "rainbow-tabled"
– xDaizu
Aug 31 at 10:43
 |Â
show 2 more comments
up vote
8
down vote
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.
answered Aug 30 at 15:48
Royce Williams
4,43811235
1
Not sure this applies since it's the actual MySQL users table (I missed that at first too).
– AndrolGenhald
Aug 30 at 16:02
1
Fair. Though passwords for MySQL users are selected by humans, too.
– Royce Williams
Aug 30 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
Aug 30 at 17:08
The primary risk of leaked passwords is Account Take Over (ATO) attacks on other sites. If I see your email is roycew@example.net and crack your password, I'll try logging in everywhere else using those credentials: Citibank, WellsFargo, Walmart, Amazon, etc.
– John Deters
Aug 31 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.
– Royce Williams
Sep 1 at 1:03
add a comment |Â
up vote
3
down vote
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.
answered Aug 30 at 14:20
Sjoerd
14.7k73553
add a comment |Â
up vote
0
down vote
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
answered Aug 31 at 0:05
Mr. E
1,725518
add a comment |Â
up vote
-1
down vote
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!
answered Aug 30 at 13:24
Connor J
77519
I am not sure, I but think MySQL does not use salting. See Why are the passwords in MySQL (5.x) not salted?
– Suma
Aug 30 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
Aug 30 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.
– Conor Mancone
Aug 30 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.
– AndrolGenhald
Aug 30 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.
– Conor Mancone
Aug 30 at 17:42
add a comment |Â
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
38
down vote
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.
answered Aug 30 at 13:28
ThoriumBR
16.4k44060
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
Aug 30 at 23:30
1
In the new versions, it's true. But older versions used to open a TCP socket on0.0.0.0.
– ThoriumBR
Aug 31 at 1:20
2
The % is just mysql's hostname check, it has nothing to do with whether a firewall is present or not
– nullability
Aug 31 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
Aug 31 at 6:57
5
@jjmontes both salted and unsalted SHA1 can also be brute forced. Unsalted password can be "rainbow-tabled"
– xDaizu
Aug 31 at 10:43
 |Â
show 2 more comments
up vote
38
down vote
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.
answered Aug 30 at 13:28
ThoriumBR
16.4k44060
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
Aug 30 at 23:30
1
In the new versions, it's true. But older versions used to open a TCP socket on0.0.0.0.
– ThoriumBR
Aug 31 at 1:20
2
The % is just mysql's hostname check, it has nothing to do with whether a firewall is present or not
– nullability
Aug 31 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
Aug 31 at 6:57
5
@jjmontes both salted and unsalted SHA1 can also be brute forced. Unsalted password can be "rainbow-tabled"
– xDaizu
Aug 31 at 10:43
 |Â
show 2 more comments
up vote
38
down vote
up vote
38
down vote
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.
answered Aug 30 at 13:28
ThoriumBR
16.4k44060
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.
answered Aug 30 at 13:28
ThoriumBR
16.4k44060
answered Aug 30 at 13:28
ThoriumBR
16.4k44060
answered Aug 30 at 13:28
ThoriumBR
16.4k44060
answered Aug 30 at 13:28
ThoriumBR
16.4k44060
16.4k44060
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
Aug 30 at 23:30
1
In the new versions, it's true. But older versions used to open a TCP socket on0.0.0.0.
– ThoriumBR
Aug 31 at 1:20
2
The % is just mysql's hostname check, it has nothing to do with whether a firewall is present or not
– nullability
Aug 31 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
Aug 31 at 6:57
5
@jjmontes both salted and unsalted SHA1 can also be brute forced. Unsalted password can be "rainbow-tabled"
– xDaizu
Aug 31 at 10:43
 |Â
show 2 more comments
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
Aug 30 at 23:30
1
In the new versions, it's true. But older versions used to open a TCP socket on0.0.0.0.
– ThoriumBR
Aug 31 at 1:20
2
The % is just mysql's hostname check, it has nothing to do with whether a firewall is present or not
– nullability
Aug 31 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
Aug 31 at 6:57
5
@jjmontes both salted and unsalted SHA1 can also be brute forced. Unsalted password can be "rainbow-tabled"
– xDaizu
Aug 31 at 10:43
1
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
Aug 30 at 23:30
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
Aug 30 at 23:30
1
1
In the new versions, it's true. But older versions used to open a TCP socket on
0.0.0.0.– ThoriumBR
Aug 31 at 1:20
In the new versions, it's true. But older versions used to open a TCP socket on
0.0.0.0.– ThoriumBR
Aug 31 at 1:20
2
2
The % is just mysql's hostname check, it has nothing to do with whether a firewall is present or not
– nullability
Aug 31 at 6:49
The % is just mysql's hostname check, it has nothing to do with whether a firewall is present or not
– nullability
Aug 31 at 6:49
5
5
It'd also be worth noting that MySQL passwords are not salted, and being basically SHA1 hashes, they can be brute forced.
– jjmontes
Aug 31 at 6:57
It'd also be worth noting that MySQL passwords are not salted, and being basically SHA1 hashes, they can be brute forced.
– jjmontes
Aug 31 at 6:57
5
5
@jjmontes both salted and unsalted SHA1 can also be brute forced. Unsalted password can be "rainbow-tabled"
– xDaizu
Aug 31 at 10:43
@jjmontes both salted and unsalted SHA1 can also be brute forced. Unsalted password can be "rainbow-tabled"
– xDaizu
Aug 31 at 10:43
 |Â
show 2 more comments
up vote
8
down vote
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.
answered Aug 30 at 15:48
Royce Williams
4,43811235
1
Not sure this applies since it's the actual MySQL users table (I missed that at first too).
– AndrolGenhald
Aug 30 at 16:02
1
Fair. Though passwords for MySQL users are selected by humans, too.
– Royce Williams
Aug 30 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
Aug 30 at 17:08
The primary risk of leaked passwords is Account Take Over (ATO) attacks on other sites. If I see your email is roycew@example.net and crack your password, I'll try logging in everywhere else using those credentials: Citibank, WellsFargo, Walmart, Amazon, etc.
– John Deters
Aug 31 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.
– Royce Williams
Sep 1 at 1:03
add a comment |Â
up vote
8
down vote
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.
answered Aug 30 at 15:48
Royce Williams
4,43811235
1
Not sure this applies since it's the actual MySQL users table (I missed that at first too).
– AndrolGenhald
Aug 30 at 16:02
1
Fair. Though passwords for MySQL users are selected by humans, too.
– Royce Williams
Aug 30 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
Aug 30 at 17:08
The primary risk of leaked passwords is Account Take Over (ATO) attacks on other sites. If I see your email is roycew@example.net and crack your password, I'll try logging in everywhere else using those credentials: Citibank, WellsFargo, Walmart, Amazon, etc.
– John Deters
Aug 31 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.
– Royce Williams
Sep 1 at 1:03
add a comment |Â
up vote
8
down vote
up vote
8
down vote
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.
answered Aug 30 at 15:48
Royce Williams
4,43811235
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.
answered Aug 30 at 15:48
Royce Williams
4,43811235
edited Sep 1 at 1:08
answered Aug 30 at 15:48
Royce Williams
4,43811235
answered Aug 30 at 15:48
Royce Williams
4,43811235
answered Aug 30 at 15:48
Royce Williams
4,43811235
4,43811235
1
Not sure this applies since it's the actual MySQL users table (I missed that at first too).
– AndrolGenhald
Aug 30 at 16:02
1
Fair. Though passwords for MySQL users are selected by humans, too.
– Royce Williams
Aug 30 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
Aug 30 at 17:08
The primary risk of leaked passwords is Account Take Over (ATO) attacks on other sites. If I see your email is roycew@example.net and crack your password, I'll try logging in everywhere else using those credentials: Citibank, WellsFargo, Walmart, Amazon, etc.
– John Deters
Aug 31 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.
– Royce Williams
Sep 1 at 1:03
add a comment |Â
1
Not sure this applies since it's the actual MySQL users table (I missed that at first too).
– AndrolGenhald
Aug 30 at 16:02
1
Fair. Though passwords for MySQL users are selected by humans, too.
– Royce Williams
Aug 30 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
Aug 30 at 17:08
The primary risk of leaked passwords is Account Take Over (ATO) attacks on other sites. If I see your email is roycew@example.net and crack your password, I'll try logging in everywhere else using those credentials: Citibank, WellsFargo, Walmart, Amazon, etc.
– John Deters
Aug 31 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.
– Royce Williams
Sep 1 at 1:03
1
1
Not sure this applies since it's the actual MySQL users table (I missed that at first too).
– AndrolGenhald
Aug 30 at 16:02
Not sure this applies since it's the actual MySQL users table (I missed that at first too).
– AndrolGenhald
Aug 30 at 16:02
1
1
Fair. Though passwords for MySQL users are selected by humans, too.
– Royce Williams
Aug 30 at 16:19
Fair. Though passwords for MySQL users are selected by humans, too.
– Royce Williams
Aug 30 at 16:19
4
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
Aug 30 at 17:08
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
Aug 30 at 17:08
The primary risk of leaked passwords is Account Take Over (ATO) attacks on other sites. If I see your email is roycew@example.net and crack your password, I'll try logging in everywhere else using those credentials: Citibank, WellsFargo, Walmart, Amazon, etc.
– John Deters
Aug 31 at 22:09
The primary risk of leaked passwords is Account Take Over (ATO) attacks on other sites. If I see your email is roycew@example.net and crack your password, I'll try logging in everywhere else using those credentials: Citibank, WellsFargo, Walmart, Amazon, etc.
– John Deters
Aug 31 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.
– Royce Williams
Sep 1 at 1:03
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.
– Royce Williams
Sep 1 at 1:03
add a comment |Â
up vote
3
down vote
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.
answered Aug 30 at 14:20
Sjoerd
14.7k73553
add a comment |Â
up vote
3
down vote
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.
answered Aug 30 at 14:20
Sjoerd
14.7k73553
add a comment |Â
up vote
3
down vote
up vote
3
down vote
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.
answered Aug 30 at 14:20
Sjoerd
14.7k73553
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.
answered Aug 30 at 14:20
Sjoerd
14.7k73553
answered Aug 30 at 14:20
Sjoerd
14.7k73553
answered Aug 30 at 14:20
Sjoerd
14.7k73553
answered Aug 30 at 14:20
Sjoerd
14.7k73553
14.7k73553
add a comment |Â
add a comment |Â
up vote
0
down vote
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
answered Aug 31 at 0:05
Mr. E
1,725518
add a comment |Â
up vote
0
down vote
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
answered Aug 31 at 0:05
Mr. E
1,725518
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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
answered Aug 31 at 0:05
Mr. E
1,725518
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
answered Aug 31 at 0:05
Mr. E
1,725518
answered Aug 31 at 0:05
Mr. E
1,725518
answered Aug 31 at 0:05
Mr. E
1,725518
answered Aug 31 at 0:05
Mr. E
1,725518
1,725518
add a comment |Â
add a comment |Â
up vote
-1
down vote
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!
answered Aug 30 at 13:24
Connor J
77519
I am not sure, I but think MySQL does not use salting. See Why are the passwords in MySQL (5.x) not salted?
– Suma
Aug 30 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
Aug 30 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.
– Conor Mancone
Aug 30 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.
– AndrolGenhald
Aug 30 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.
– Conor Mancone
Aug 30 at 17:42
add a comment |Â
up vote
-1
down vote
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!
answered Aug 30 at 13:24
Connor J
77519
I am not sure, I but think MySQL does not use salting. See Why are the passwords in MySQL (5.x) not salted?
– Suma
Aug 30 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
Aug 30 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.
– Conor Mancone
Aug 30 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.
– AndrolGenhald
Aug 30 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.
– Conor Mancone
Aug 30 at 17:42
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
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!
answered Aug 30 at 13:24
Connor J
77519
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!
answered Aug 30 at 13:24
Connor J
77519
edited Aug 30 at 16:59
answered Aug 30 at 13:24
Connor J
77519
answered Aug 30 at 13:24
Connor J
77519
answered Aug 30 at 13:24
Connor J
77519
77519
I am not sure, I but think MySQL does not use salting. See Why are the passwords in MySQL (5.x) not salted?
– Suma
Aug 30 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
Aug 30 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.
– Conor Mancone
Aug 30 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.
– AndrolGenhald
Aug 30 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.
– Conor Mancone
Aug 30 at 17:42
add a comment |Â
I am not sure, I but think MySQL does not use salting. See Why are the passwords in MySQL (5.x) not salted?
– Suma
Aug 30 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
Aug 30 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.
– Conor Mancone
Aug 30 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.
– AndrolGenhald
Aug 30 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.
– Conor Mancone
Aug 30 at 17:42
I am not sure, I but think MySQL does not use salting. See Why are the passwords in MySQL (5.x) not salted?
– Suma
Aug 30 at 14:33
I am not sure, I but think MySQL does not use salting. See Why are the passwords in MySQL (5.x) not salted?
– Suma
Aug 30 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
Aug 30 at 14:38
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
Aug 30 at 14:38
1
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.
– Conor Mancone
Aug 30 at 16:05
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.
– Conor Mancone
Aug 30 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.
– AndrolGenhald
Aug 30 at 17:37
@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.
– AndrolGenhald
Aug 30 at 17:37
1
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.
– Conor Mancone
Aug 30 at 17:42
@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.
– Conor Mancone
Aug 30 at 17:42
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f192716%2fis-password-information-dumped-from-the-mysql-user-table-sensitive%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
