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.
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.