Ja, het is gevoelige informatie. Het is een wachtwoord-hash-lek.

Aanvallers leveren deze informatie aan een bruteforce-applicatie (er zijn er een die speciaal voor MySQL zijn gemaakt) en halen het wachtwoord op.

Niet alleen dit, maar ook de % op het hostveld betekent dat als uw MySQL-poort (standaard 3306) niet door een firewall is beveiligd, de aanvaller deze overal kan openen als admin .

Overweeg om het admin -account alleen voor localhost te vergrendelen en maak nooit een wachtwoordhash vrij, hoe zeker je ook bent over de moeilijkheid om zo'n hash te kraken.

Niet alleen zijn de wachtwoorden zelf inherent gevoelig (zoals de andere antwoorden terecht aangeven als het primaire risico) ... maar de informatie die ze bevatten is vaak ook gevoelig .

Zodra de hashes zijn gekraakt, bevatten veel wachtwoorden verjaardagen, kindernamen, telefoonnummers, de-facto antwoorden op veiligheidsvragen, straatadressen ... zelfs burgerservicenummers!

We onthouden wat belangrijk is voor ons - en wat persoonlijk is voor ons. Dit zorgt voor wachtwoorden met een geweldige UX ... maar ze zijn vreselijk vanuit een beveiligingsperspectief.

Deze psychologie van wachtwoordselectie moet als een beperking worden beschouwd. Aangezien veel gebruikers op deze manier wachtwoorden kiezen, moeten ze dienovereenkomstig worden behandeld en beschermd.

Het is mogelijk om het originele wachtwoord uit een hash te halen met behulp van een hulpprogramma voor het kraken van wachtwoorden, zoals John the Ripper of hashcat. Deze tools proberen gewoon veel wachtwoorden bij een brute-force aanval. Dit kan lang duren, afhankelijk van de complexiteit van het wachtwoord.

Ja, het is gevoelig. Een aanvaller kan proberen de hash te "kraken" door middel van bruteforce-pogingen of woordenboekaanvallen. In alle gevallen die ik heb gezien, zijn MySQL-wachtwoorden gezouten, maar als ze geen vooraf berekende hashtabel zijn, of regenboogtabellen kunnen worden gebruikt om het proces te versnellen.

Verder, als die hash is verkregen via een kwetsbaarheid voor SQL-injectie (zeer waarschijnlijk). Het is mogelijk dat een aanvaller probeert gegevens in de tabel in te voegen of bij te werken, afhankelijk van hoe de query is uitgevoerd. Als dit mogelijk is, kan de aanvaller eenvoudig een nieuwe gebruiker toevoegen of de hash van het beheerderswachtwoord wijzigen met een hash van een reeds bekend wachtwoord, waardoor de kraakstap volledig wordt overgeslagen.

als een aanvaller in staat is om de hash van een wachtwoord te krijgen, zoals op de manier die hierboven is beschreven, dan is het mogelijk om te proberen de botsing van die hash te vinden met behulp van regenboogtabellen if salting is niet gebruikt.

Als salting is gebruikt, wordt de moeilijkheid om wachtwoorden te kraken veel moeilijker.

BEWERK: Voor de duidelijkheid - als ik verwijs naar zouten, bedoelde ik dat het bij zouten kan worden gedaan door een externe tool / proces, en gewoon worden opgeslagen in de database, en niet dat MySQL enige input had in het proces naast het opslaan van de waarden. Excuses aan degenen die in de war zijn!