Les informations de mot de passe sont-elles sauvegardées depuis la table utilisateur MySQL?
Supposons que j'ai vidé la liste d'utilisateurs MySQL en utilisant
SELECT user, Host, password, ssl_type FROM mysql.user;
Le résultat ressemble à ceci:
+------------------+-----------+-------------------------------------------+----------+
| user | Host | password | ssl_type |
+------------------+-----------+-------------------------------------------+----------+
| admin | % | *blablablablablablablablablablablablablaa | ANY |
+------------------+-----------+-------------------------------------------+----------+
Ces informations doivent-elles être considérées comme sensibles? Un attaquant peut-il utiliser les informations de mot de passe pour accéder à la base de données MySQL? Il semble que le mot de passe soit haché, il n'est donc pas directement utilisable, mais peut-être qu'il peut être exploité d'une manière ou d'une autre, par exemple pour aider à créer des tables Rainbow pour mon serveur, ou quelque chose comme ça?
Oui, ce sont des informations sensibles. C'est une fuite de hachage de mot de passe.
Les attaquants fourniront ces informations à une application bruteforce (il y en a sur mesure uniquement pour MySQL) et récupéreront le mot de passe.
Non seulement cela, mais le % sur le champ Host signifie que si votre port MySQL (3306 par défaut) n'est pas pare-feu, l'attaquant peut y accéder en tant que admin de n'importe où.
Pensez à verrouiller le compte admin uniquement pour localhost et ne divulguez jamais un hachage de mot de passe, quelle que soit votre confiance quant à la difficulté de casser un tel hachage.
Non seulement les mots de passe eux-mêmes sont intrinsèquement sensibles (comme les autres réponses le soulignent à juste titre comme le risque principal) ... mais les informations qu'ils contiennent sont souvent aussi sensibles.
Une fois les hachages craqués, de nombreux mots de passe contiennent des anniversaires, des noms d'enfants, des numéros de téléphone, des réponses de facto à des questions de sécurité, des adresses publiques ... même des numéros de sécurité sociale!
Nous nous souvenons de ce qui nous importe - et de ce qui nous est personnel. Cela donne des mots de passe avec une grande UX ... mais ils sont terribles du point de vue de la sécurité.
Cette psychologie de la sélection des mots de passe doit être considérée comme une contrainte. Étant donné que de nombreux utilisateurs choisissent les mots de passe de cette façon, ils doivent être traités et protégés en conséquence.
Il est possible d'obtenir le mot de passe d'origine à partir d'un hachage à l'aide d'un outil de craquage de mot de passe, tel que John the Ripper ou hashcat . Ces outils essaient simplement beaucoup de mots de passe lors d'une attaque par force brute. Cela peut prendre du temps en fonction de la complexité du mot de passe.
Oui, c'est sensible. Un attaquant peut tenter de "casser" le hachage par des tentatives de bruteforce ou des attaques par dictionnaire. Dans tous les cas, j'ai vu des mots de passe MySQL salés, mais s'ils ne sont pas une table de hachage pré-calculée ou des tables Rainbow peuvent être utilisées pour accélérer le processus
De plus, si ce hachage a été obtenu via une vulnérabilité d'injection SQL (hautement probable), il peut être possible pour un attaquant de tenter d'insérer ou de mettre à jour des données dans la table, selon la façon dont la requête a été effectuée. Si cela est possible, l'attaquant peut simplement ajouter un nouvel utilisateur ou modifier le hachage du mot de passe administrateur avec un hachage d'un mot de passe déjà connu, ignorant complètement l'étape de craquage