35.000 Rootkit.com wachtwoorden in 5 minuten gekraakt
Bijna de helft van de gebruikers op Rootkit.com gebruikte een zwak wachtwoord, zo blijkt uit onderzoek waarbij ruim 35.000 van de wachtwoord-hashes binnen vijf minuten werden gekraakt. De website werd onlangs door Anonymous aangevallen, omdat die van de eigenaar van beveiligingsbedrijf HBGary is. Een werknemer van dit bedrijf wilde informatie over kernleden van Anonymous aan de FBI verkopen en zou onderdeel van een smeercampagne tegen WikiLeaks zijn.
De aanvallers maakten onder andere de database met 81.000 wachtwoord-hashes buit. Beveiligingsonderzoeker Joseph Bonneau wist 44% van de accounts via een woordenboek met 10 miljoen woorden binnen vijf minuten te kraken. Rootkit.com gebruikte alleen het MD5 hashing-algoritme voor het hashen van de wachtwoorden, zonder salt.
Hergebruik
Aangezien onlangs ook de database met wachtwoorden van Gawker was gelekt, besloot Bonneau die naast elkaar te leggen. Van Gawker wist hij 54% van de wachtwoorden te achterhalen. In totaal waren 456 e-mailadressen bij beide websites geregistreerd. Bonneau kraakte van 172 e-mailadressen het wachtwoord bij zowel Gawker als Rootkit.com. Van deze gebruikers waren er 131 (76%) die hetzelfde wachtwoord gebruikten. Een verdere zes procent gebruikte hetzelfde wachtwoord met een kleine aanpassing.
De onderzoeker schat dat zo'n 31% van de gebruikers zijn wachtwoord hergebruikt. Veel hoger dan uit andere studies blijkt. Een mogelijke reden hiervoor is dat het om laagdrempelige fora met weinig waarde gaat of dat het hergebruik van wachtwoorden de afgelopen vijf jaar is toegenomen. Bonneau roept echter op tot meer onderzoek, bijvoorbeeld in hoeverre wachtwoorden op onbelangrijke websites ook op belangrijke websites, zoals bij internetbankieren, worden gebruikt.
Ik ben altijd van het 3voudig encrypten van wachtwoorden (in verschillende delen van de md5 string)
Ik ben altijd van het 3voudig encrypten van wachtwoorden (in verschillende delen van de md5 string)
Kijk hier maar eens:
http://www.molenaar-technologies.nl/blog/reageer/548/waarom-een--salt--belangrijk-is-voor-je-website/
Ik ben altijd van het 3voudig encrypten van wachtwoorden (in verschillende delen van de md5 string)
MD5? Bestaat dat nog? :)
Bijv: zonder salt: $md5hash = md5($password)
met salt: $salt = "$0[]]1=-a,1\_?-2="
$md5hash = md5($password.$salt)
Deze laatste hash is veel moeilijker te kraken.
Wat bedoel je met 3voudig encrypten?
Iets in de trend van md5(md5(md5(wachtwoord))) ?
Dit wordt vaak als heel slim gezien, maar is het niet echt eigenlijk. Ook niet in combinatie met andere hashing algo's.
Een 'goede' salt gebruiken is al een heel stuk beter.
Een mogelijke reden hiervoor is dat het om laagdrempelige fora met weinig waarde gaat of dat het hergebruik van wachtwoorden de afgelopen vijf jaar is toegenomen. Bonneau roept echter op tot meer onderzoek, bijvoorbeeld in hoeverre wachtwoorden op onbelangrijke websites ook op belangrijke websites, zoals bij internetbankieren, worden gebruikt.
Ja met een email adres en een brak wachtwoord kan je leuke dingen doen als je even geduld hebt om het uit te zoeken.
Wat wel discutabel is:
Als het alleen bij onderzoek blijft kan het nog maar die gegevens daadwerkelijk te gaan gebruiken is natuurlijk NOT DONE.
Ik ben altijd van het 3voudig encrypten van wachtwoorden (in verschillende delen van de md5 string)
Een salt is een random string (liefst random per gebruiker) die aan het te hashen wachtwoord wordt vastgeplakt. Zo hebben rainbow-aanvallen niet zo veel zin, omdat voor elk wachtwoord een aparte rainbowtable gemaakt moet worden.
Ik weet niet wat je bedoelt met het 3voudig encrypten van wachtwoorden, maar het lijkt dat je wel wat kennis mist als je websites ontwikkelt. Op Tweakers.net (http://gathering.tweakers.net/forum/list_messages/1104760//) staat veel meer info daarover dan ik je nu kan vertellen.
Normaal zou je een wachtwoord door een MD5 (of een ander hash algoritme) halen en dan weet je vrijwel zeker dat je het juiste wachtwoord hebt ingetyped om dezelfde hash te krijgen. Het hoeft echter niet zo te, omdat er meer wachtwoorden mogelijk zijn die dezelfde hash opleveren.
Dergelijke collisions berekenen is wel mogelijk, maar het is nog steeds erg lastig om exact dezelfde string te berekenen.
Door nu een vast stukje tekst voor het wachtwoord te plakken, krijg je een deel wat de gebruiker ingeeft en een deel wat je systeem toevoegt. Dan zijn de berekende collisions dus onbruikbaar, tenzij ze beginnen met die 'salt'.
Die kans is echter erg klein, dat je een collision kunt berekenen die begint met die salt. Zeker als je ook nog eens, zoals wizzkizz al zei, verschillende salts gebruikt voor elk account.
Normaal zou je een wachtwoord door een MD5 (of een ander hash algoritme) halen en dan weet je vrijwel zeker dat je het juiste wachtwoord hebt ingetyped om dezelfde hash te krijgen. Het hoeft echter niet zo te, omdat er meer wachtwoorden mogelijk zijn die dezelfde hash opleveren.
Dergelijke collisions berekenen is wel mogelijk, maar het is nog steeds erg lastig om exact dezelfde string te berekenen.
Door nu een vast stukje tekst voor het wachtwoord te plakken, krijg je een deel wat de gebruiker ingeeft en een deel wat je systeem toevoegt. Dan zijn de berekende collisions dus onbruikbaar, tenzij ze beginnen met die 'salt'.
Die kans is echter erg klein, dat je een collision kunt berekenen die begint met die salt. Zeker als je ook nog eens, zoals wizzkizz al zei, verschillende salts gebruikt voor elk account.
Als je één salt voor de hele database gebruikt, dan is het in feite een sleutel, die je goed moet beschermen. Maar dat is in principe mogelijk.
Als je per individueel account een andere salt kiest, moet je die salt dus ook opslaan. Grote kans dat je dan diezelfde database gebruikt. Voor mensen die aan de database kunnen komen (zoals in dit geval, of insiders), zal dit laatste dus niet helpen.
Dank :-)
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
