Populaire wachtwoordkraker Hashcat nu open source
De ontwikkelaar van de populaire wachtwoordkrakers Hashcat en oclHashcat heeft besloten de projecten open source te maken en de broncode vrij te geven zodat gebruikers beter gebruik van de software kunnen maken. Hashcat en oclHashcat zijn programma's om wachtwoordhashes mee te kraken.
Hashes worden gebruikt om wachtwoorden verhaspeld in een database op te slaan. Dit voorkomt dat als bijvoorbeeld een website wordt gehackt en de database wordt gestolen, de aanvaller meteen toegang tot de wachtwoorden van gebruikers heeft, aangezien die gehasht zijn. Het is echter mogelijk om een hash te kraken en het bijbehorende wachtwoord te achterhalen. OclHashcat kan hiervoor zowel de rekenkracht van de processor als videokaart gebruiken, terwijl Hashcat alleen de processor aanspreekt.
Hoewel de software al jaren bestaat besloot de ontwikkelaar de broncode niet vrij te geven. Daar is nu door verschillende redenen verandering in gekomen. OclHashcat en Hashcat worden door veel security professionals, penetratietesters en forensisch onderzoekers gebruikt. Vaak hebben die speciale eisen om de software in te zetten, zoals het gebruik van bepaalde algoritmen. Door de broncode open source te maken moet dit eenvoudiger worden.
Een andere reden is de ondersteuning van OS X. Standaard wordt Apple's platform niet door de software ondersteund, omdat Apple het 'offline' compileren van kernelcode niet toestaat. Door de broncode van Hashcat en oclHashcat open source te maken kunnen gebruikers de code toch op OS X compileren en deze beperking omzeilen. De voornaamste reden is echter het verbeteren van de prestaties als er hashes met een salt moeten worden gekraakt.
Een 'salt' is een waarde die aan het wachtwoord wordt toegevoegd, waarna er een hash van wordt gemaakt. Doordat de broncode nu open source is kunnen gebruikers die zelf compileren met de salt er direct bij, wat bij op DES-gebaseerde algoritmes voor een prestatietoename van 300% tot 400% kan zorgen. De broncode van beide wachtwoordkrakers is te vinden op GitHub.
De punten die mij niet duidelijk waren :
De genoemde professionals, pentesters e.d. willen blijkbaar de generatie code (ik denk dictionary / permutatie generators e.d.) koppelen aan een eigen crypto-backend, bijvoorbeeld voor custom hashes welke niet standaard door hashcat gesupport worden. Of misschien omdat ze een nog snellere implementatie hebben van een bepaalde hash.
OS-X kernel : Kernel slaat hier niet op de operating system kernel , maar op de kernel die de crypto hash functies berekent.
Die leunt op het gebruik van de GPU (grafische processor) via OpenCL , en die code/aanroepen worden blijkbaar niet als standaard OS-X api aangeboden, en dus wil Apple het distribueren van een applicatie die niet gesupporte calls gebruikt niet toestaan.
Het zal een voorwaarde voor gebruik van de Apple development toolkit zijn, en als je als project 'officieel' genoeg bent zul je je daaraan moeten houden, als je de Apple development tools gebruikt.
Tenslotte DES en het salt :
De snelste DES implementaties zijn gebaseerd op 'bitslicing' , waarbij de CPU een 64 blocks tegelijk aangeboden krijgt als een bitvector.
De implementatie is gebaseerd op logische operaties, als ware het een hardware implementatie met gates - waar DES voor geoptimalizeerd was.
(zie http://www.darkside.com.au/bitslice/ e.a. )
Daar waar het Salt gebruikt wordt om een deel van de DES permutatie te wijzigen, betekent een ander salt ook een andere bitslice "hardware layout" . En dat vereist (in de hashcat implementatie) om de DES kernel opnieuw te compileren.
Overigens zou het zeker mogelijk zijn om de bij een salt passende bitslice DES 'gate layout' on the fly te genereren (feitelijk een vorm van JIT) maar dat is blijkbaar niet hoe hashcat geschreven is .
"OclHast"?
"OclHast"?
Bijna goed. Er staat nu 'oclHascat' :-)
De punten die mij niet duidelijk waren :
De genoemde professionals, pentesters e.d. willen blijkbaar de generatie code (ik denk dictionary / permutatie generators e.d.) koppelen aan een eigen crypto-backend, bijvoorbeeld voor custom hashes welke niet standaard door hashcat gesupport worden. Of misschien omdat ze een nog snellere implementatie hebben van een bepaalde hash.
OS-X kernel : Kernel slaat hier niet op de operating system kernel , maar op de kernel die de crypto hash functies berekent.
Die leunt op het gebruik van de GPU (grafische processor) via OpenCL , en die code/aanroepen worden blijkbaar niet als standaard OS-X api aangeboden, en dus wil Apple het distribueren van een applicatie die niet gesupporte calls gebruikt niet toestaan.
Het zal een voorwaarde voor gebruik van de Apple development toolkit zijn, en als je als project 'officieel' genoeg bent zul je je daaraan moeten houden, als je de Apple development tools gebruikt.
Tenslotte DES en het salt :
De snelste DES implementaties zijn gebaseerd op 'bitslicing' , waarbij de CPU een 64 blocks tegelijk aangeboden krijgt als een bitvector.
De implementatie is gebaseerd op logische operaties, als ware het een hardware implementatie met gates - waar DES voor geoptimalizeerd was.
(zie http://www.darkside.com.au/bitslice/ e.a. )
Daar waar het Salt gebruikt wordt om een deel van de DES permutatie te wijzigen, betekent een ander salt ook een andere bitslice "hardware layout" . En dat vereist (in de hashcat implementatie) om de DES kernel opnieuw te compileren.
Overigens zou het zeker mogelijk zijn om de bij een salt passende bitslice DES 'gate layout' on the fly te genereren (feitelijk een vorm van JIT) maar dat is blijkbaar niet hoe hashcat geschreven is .
Dus.... Meer kraak opties?
Ik zie hier geen heil in als "research" middel, enkel om mensen meer opties en tools te geven om hashes te kraken en wachtwoorden te achterhalen.
Dit gaat waarschijnlijk meer problemen opleveren als dat het zaken op orde gaat brengen.
Dus.... Meer kraak opties?
Ik zie hier geen heil in als "research" middel, enkel om mensen meer opties en tools te geven om hashes te kraken en wachtwoorden te achterhalen.
Dit gaat waarschijnlijk meer problemen opleveren als dat het zaken op orde gaat brengen.
Die discussie is minimaal zo oud als de release van "crack" (1991) - zoek maar op mailinglists archieven naar alle argumenten voor en tegen - de kans is erg klein dat er hier een nieuw standpunt langs komt.
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.
