Hashcat kan nu wachtwoorden van 256 karakters kraken
Er is een nieuwe versie van de populaire wachtwoordkraker Hashcat verschenen die wachtwoorden en salts met een lengte van maximaal 256 karakters kan kraken. Ook is de ondersteuning van macOS verbeterd en biedt de tool nu de mogelijkheid om een zelftest uit te voeren.
Hashcat 4.0.0 is maanden in ontwikkeling geweest. Volgens de ontwikkelaar komt dit door het toevoegen van een nieuwe hash-interface en het herschrijven van de kernel. Naast de mogelijkheid om wachtwoorden en salts met een maximale lengte van 256 karakters te krijgen noemt de ontwikkelaar ook de zelftest een belangrijke nieuwe feature. Voorheen gaf Hashcat in bepaalde gevallen geen duidelijke foutmeldingen als er problemen met de kernel waren. Hashcat 4.0.0 probeert tijdens het opstarten de hash van een bekend wachtwoord te kraken. Op deze manier weten gebruikers meteen of hun systeem goed is ingesteld. Naast de nieuwe features zijn ook tal van bugfixes en kleine verbeteringen doorgevoerd. De nieuwste versie is te downloaden via Hashcat.net.
Hashcat is zeer geliefd bij beveiligingsonderzoekers. penetratietesters en forensisch onderzoekers voor het kraken van wachtwoordhashes. Hashes worden gebruikt om wachtwoorden gecodeerd 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. Iets wat middels een tool als Hashcat mogelijk is. Het programma maakt hierbij gebruik van de rekenkracht van de videokaart en processor.
klopt, maar voor heel veel accounts is dat simpelweg niet mogelijk. denk aan service of np accounts.
Meer triest is dat al deze kraakprogramma's een dump van de hash nodig hebben - de beschikbaarheid van die dump van de hashfiles is het gevolg van hacks die al totaal niet mogelijk hadden moeten zijn.
Als er nou één ding _echt_ belangrijk is om te beveiligen op je service is dat je authenticatie systeem...
Het kan hashes kraken dus je kunt ermee testen of je hashes te kraken zijn? Maar dat wist je toch van tevoren al, dat hashcat dat kan, want daarvoor heb je het nou juist gekocht? Wat test je dan, of hashcat goed werkt? Dat laatste mag je toch veronderstellen als je het net gekocht hebt. En de wachtwoorden ken je ook al want die heb je net zelf opgeslagen.
Kortom, wat heb je hier aan als je niet van plan bent om de hashes van andermans wachtwoorden te gaan kraken, want dat is het enige (illegale) nut dat ik zou zien.
Het wordt me uit bovenstaand stukje niet duidelijk.
Meer triest is dat al deze kraakprogramma's een dump van de hash nodig hebben - de beschikbaarheid van die dump van de hashfiles is het gevolg van hacks die al totaal niet mogelijk hadden moeten zijn.
Als er nou één ding _echt_ belangrijk is om te beveiligen op je service is dat je authenticatie systeem...
Dit soort tools wordt vaak gebruikt om het eigen systeem te testen. Daar is uiteraard de hash gewoon beschikbaar.
Meer triest is dat al deze kraakprogramma's een dump van de hash nodig hebben - de beschikbaarheid van die dump van de hashfiles is het gevolg van hacks die al totaal niet mogelijk hadden moeten zijn.
Als er nou één ding _echt_ belangrijk is om te beveiligen op je service is dat je authenticatie systeem...
Dit soort tools wordt vaak gebruikt om het eigen systeem te testen. Daar is uiteraard de hash gewoon beschikbaar.
Ik twijfel wel eens een beetje of *dat* gebruik de hoofdmoot is, maar misschien is dat het geval.
Verder heb je op het eigen systeem ook de mogelijkheid om een password tijdens keuze tegen alle soorten rules te houden wat toch een stuk simpeler is dan achteraf hashcat draaien.
Overigens was mijn opmerking voornamelijk een reactie op iemand die riep over multi-factor authenticatie - alsof de beschikbaarheid van hashes voor hackers gegeven is.
Het kan hashes kraken dus je kunt ermee testen of je hashes te kraken zijn? Maar dat wist je toch van tevoren al, dat hashcat dat kan, want daarvoor heb je het nou juist gekocht? Wat test je dan, of hashcat goed werkt? Dat laatste mag je toch veronderstellen als je het net gekocht hebt.
Overigens koopt men hashcat niet, het is gratis open-source software.
Het kan hashes kraken dus je kunt ermee testen of je hashes te kraken zijn? Maar dat wist je toch van tevoren al, dat hashcat dat kan, want daarvoor heb je het nou juist gekocht? Wat test je dan, of hashcat goed werkt? Dat laatste mag je toch veronderstellen als je het net gekocht hebt. En de wachtwoorden ken je ook al want die heb je net zelf opgeslagen.
Kortom, wat heb je hier aan als je niet van plan bent om de hashes van andermans wachtwoorden te gaan kraken, want dat is het enige (illegale) nut dat ik zou zien.
Het wordt me uit bovenstaand stukje niet duidelijk.
Stel je bent beheerder van een systeem. De gebruiker heeft voordat hij op vakantie ging zijn wachtwoord gewijzigd en weet dat nu niet meer (komt wel eens voor schijnbaar). Stel de gebruiker heeft dat oude wachtwoord ook (foei, dat mag niet maar ze doen het toch) gebruikt om zijn documenten in de cloud te beveiligen. De gebruiker kan nu niet meer bij zijn documenten. Gelukkig is er hashcat en kun je met het gehashte wachtwoord zijn oude wachtwoord achterhalen waarmee de gebruiker weer bij zijn documenten kan...
die is die zo te kraken???
https://www.grc.com/passwords.htm
Voorbeeld wachtwoord:
[w*3ILU,L%g*hpx.$af-M*ZmU#@b]QxLkw<94U$hT`)4yDM1S?x0{E';D\cW|/h
Snap het niet meer
die is die zo te kraken???
https://www.grc.com/passwords.htm
Voorbeeld wachtwoord:
[w*3ILU,L%g*hpx.$af-M*ZmU#@b]QxLkw<94U$hT`)4yDM1S?x0{E';D\cW|/h
Snap het niet meer
Nee natuurlijk is _zo'n_ password niet te kraken.
Als je het wilt snappen moet je een beetje meer gaan lezen op internet .
Het is niet zo moeilijk.
klopt, maar voor heel veel accounts is dat simpelweg niet mogelijk. denk aan service of np accounts.
Je hebt dan in feite zeer veilige containers gemaakt naar je eigen bedrijfs omgevingseisen. Niet eens moeilijk of echt complex.
Wat moeilijk is is het doorbreken van het dogma dat een sudo voor root vanuit die beheerder moet.
Wat moeilijk is is het doorbreken van het dogma dat een externe leverancier het wal zal weten en dat de oplossing ligt in het aanschaffen voor tools. Als je zelf niet hoeft na te denken is dat veel goedkoper ... op de korte termijn.
Het kan hashes kraken dus je kunt ermee testen of je hashes te kraken zijn? Maar dat wist je toch van tevoren al, dat hashcat dat kan, want daarvoor heb je het nou juist gekocht? Wat test je dan, of hashcat goed werkt? Dat laatste mag je toch veronderstellen als je het net gekocht hebt. En de wachtwoorden ken je ook al want die heb je net zelf opgeslagen.
Kortom, wat heb je hier aan als je niet van plan bent om de hashes van andermans wachtwoorden te gaan kraken, want dat is het enige (illegale) nut dat ik zou zien.
Het wordt me uit bovenstaand stukje niet duidelijk.
Ooit gehoord van een penetratietest? Wanneer men een beveiligingstest uitvoert is het extreem handig om bemachtigde hashes te kraken en vervolgens dat wachtwoord te gebruiken om op andere systemen in te loggen. Compleet legaal, het wordt onder strikt toezicht en met toestemming gedaan. Het is juist bevorderlijk dat onderzoekers toegang hebben tot de zelfde tools als kwaadwillenden omdat het risico dan realistisch kan worden ingeschat.
die is die zo te kraken???
https://www.grc.com/passwords.htm
Voorbeeld wachtwoord:
[w*3ILU,L%g*hpx.$af-M*ZmU#@b]QxLkw<94U$hT`)4yDM1S?x0{E';D\cW|/h
Snap het niet meer
(= AF1DB7D2A649BA64D948072696BB58F86D925DFE2B3257B14616989739814AC4 )
dan kan Hashcat met die hash weer het oorspronkelijke wachtwoord achterhalen.
Wat is de lol daarvan? Bijv. security onderzoekers vermelden gelekte wachtwoorden vaak in hashvorm.
Die kan Hashcat nu dus herleiden tot het oorspronkelijke wachtwoord. Ook als het SHA256 is. (=256 karakters)
Er zijn nog meer dingen mogelijk met Hashcat, maar daarvoor kan je het beste op hun website of hun forum kijken of zoeken. Daar vind je ook systeemeisen en welke drivers je erbij nodig hebt.
die is die zo te kraken???
https://www.grc.com/passwords.htm
Voorbeeld wachtwoord:
[w*3ILU,L%g*hpx.$af-M*ZmU#@b]QxLkw<94U$hT`)4yDM1S?x0{E';D\cW|/h
Snap het niet meer
(= AF1DB7D2A649BA64D948072696BB58F86D925DFE2B3257B14616989739814AC4 )
dan kan Hashcat met die hash weer het oorspronkelijke wachtwoord achterhalen.
Nou ja, proberen te achterhalen. Van dat voorbeeld password zal het niet lukken.
Wat is de lol daarvan? Bijv. security onderzoekers vermelden gelekte wachtwoorden vaak in hashvorm.
Die kan Hashcat nu dus herleiden tot het oorspronkelijke wachtwoord. Ook als het SHA256 is. (=256 karakters)
Zucht. SHA-256 is een hash van 256 *bits* output lengte . (=32 bytes, dus 32 [of minder - UTF-8] karakters.
De input van een hash kan willekeurig lang zijn, en blijkbaar wil deze versie van hashcat pogingen (woorden achter elkaar plakken, permuteren) doen tot een invoerlengte van 256 karakters.
hashcat kan verschillende hash functies testen .
En 256 bits is 64 hex-karakters.
En 256 bits is 64 hex-karakters.
'karakters' is nooit zo precies wanneer de tekenset waar die karakters uit gekozen worden beperkt is.
Als je de tekenset beperkt tot '0' en '1' heb je 256 van deze karakters nodig om de SHA-256 output weer te geven.
Als je de tekenset beperkt tot 'A-F0-9' (hex) heb je , zoals je zegt, 64 karakters nodig - per karakter druk je vier bits uit.
Als je de tekenset beperkt tot 'a-zA-Z0<>' (- hoort niet bij de tekenset hier) heb je 43 karakters nodig - met een tekenset van 64 karakters druk je 6 bit per karakter uit.
Als je de volledige ascii set gebruikt, inclusief alle controlcodes zit je op 8 bit per karakter en dus 32 karakters.
En als je UTF-8 gaat gebruiken heb je karakters die meer dan één byte lang zijn, en kun je dus met nog minder karakters de 256 bits weergeven. Het wordt natuurlijk wel lastig leesbaar , gezien de heel kleine verschillen tussen sommige van die karakters.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
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?