Hashcat-hacktool richt zich op lange wachtwoorden en Active Directory

OclHashcat-plus, een versie van de wachtwoordcracker die is geoptimaliseerd voor gpu's, biedt voortaan de mogelijkheid om wachtwoorden langer dan vijftien tekens te kraken, zoals passphrases. Daarnaast zijn er nieuwe aanvalsmethoden voor Microsoft Active Directory-accounts.

De laatst versie van OclHashcat-plus, met versienummer 0.15, kan voortaan wachtwoorden tot 55 tekens aanvallen. Daarmee kunnen wachtwoordhackers hun pijlen richten op hashes voor langere wachtwoorden of zogeheten passphrases. Dergelijke wachtwoorden worden populairder nu kortere wachtwoorden - tot 8 à 10 karakters - steeds sneller zijn te kraken dankzij de inzet van gpu's en wachtwoordlijsten.

Developers van Hashcat hebben ook de PACK-toolkit uitgebracht. Deze software kan bij het kraken van wachtwoorden rekening houden met de ingestelde password-policies die veelal op Microsoft Active Directory-accounts van toepassing zijn. Doordat bij bepaalde policy-instellingen, die met name bij bedrijven worden gebruikt, wachtwoorden voorspelbare patronen krijgen, kan het aantal mogelijkheden bij het aanvallen van dergelijke accounts flink verlaagd worden.

Versie 0.15 van OclHashcat-plus, waar zes maanden aan is gewerkt, kan voortaan ook met een groter aantal wachtwoordalgoritmen om, waaronder Grub2, Mac OS X 10.8 en Truecrypt. Ook is het aantal ondersteunde gpu's van AMD en Nvidia vergroot.

Reacties (83)

Nou ben ik wel nieuwsgierig: iemand wel eens geprobeerd een volledig random wachtwoord van 8 karakters bestaande uit hoofdletters, kleine letters, getallen en alfa-numeric characters (brute force) te kraken?

Ik zou zelf zeggen dat zijn ongeveer 72 mogelijkheden per karakter, dus zo'n 722 biljoen mogelijkheden totaal. Alleen heb ik geen idee hoeveel computation power het kost om één wachtwoord te proberen, dus... ben wel erg benieuwd hoe lang een beetje moderne videokaart daarover doet?

Moet je de volgende site eens lezen. Hierin hebben ze 3 crackers aan het werk gezet om een lijst van 16.000 wachtwoorden te kraken. Onder deze mensen zat ook Jens Steube, de lead developer van OclHashcat.
http://www.wired.co.uk/ne...3-05/28/password-cracking

Uit nieuws: Helft gebruikers Tweakers.net blijkt zwak wachtwoord te hebben blijkt dat je ook al een heel eind komt zonder echte brute force.

met een miljoen pogingen per seconde, zal dit zo'n 200.000 uur (bijna 23 jaar zijn).
Lijkt me behoorlijk sterk, maar als een botnet hieraan gaat rekenen, dan is het waarschijnlijk redelijk snel te kraken .....

Maar kost het echt zoveel om een wachtwoord te proberen? Ik bedoel, 1 TFLOPS (niet heel gek voor een moderne grafische kaart) = 1 biljoen floating point operations per second. Stel dat het testen van een wachtwoord 100 floating point operations kost (echt geen idee he, ik speculeer maar iets, misschien is het veel meer), dan zit je op 72200 seconden, wat ongeveer 20u is. Dat zou dan weer niet onmogelijk zijn.

Maar omdat ik dus geen idee heb hoeveel floating point operations het kost om een wachtwoord te testen vroeg ik me af of iemand wel eens iets dergelijks geprobeerd heeft en weet hoeveel pogingen per seconde zo'n beetje realistisch is... Die miljoen van jou, is dat zomaar een wilde gok, of uit ervaring / bronnen?

Edit: gevonden!

Ordinary desktop computers can test over a hundred million passwords per second using password cracking tools that run on a general purpose CPU and billions of passwords per second using GPU-based password cracking tools.[4][5][6] See: John the Ripper benchmarks.[7] A user-selected eight-character password with numbers, mixed case, and symbols, reaches an estimated 30-bit strength, according to NIST. 230 is only one billion permutations and would take an average of 16 minutes to crack.[8]

Bron: http://en.wikipedia.org/wiki/Password_cracking

[Reactie gewijzigd door casparvl op 27 augustus 2013 16:02]

Hier is een brute force calculator die je misschien iets wijzer kan maken. De calculator gaat er echter wel vanuit dat de cracker weet met welke karakter-set hij te maken heeft. En dat is vrijwel nooit het geval. Hoe dan ook, een wachtwoord als "password" zou met een snelheid van zo'n 1 miljard wachtwoorden per seconde in ongeveer 200 seconden zijn gekraakt. Het wachtwoord "correcthorsebatterystaple" is alweer iets veiliger. Daar gaan een paar mensenlevens overeen.

De sleutel tot een goed wachtwoord is tegenwoordig dus lengte, en niet zozeer speciale tekens. Volgens de calculator duurt het zo'n 3 jaar om een wachtwoord van 12 karakters te kraken (1 miljard/sec). Een distributed attack maakt die tijd natuurlijk wel flink wat korter.

[Reactie gewijzigd door 3raser op 27 augustus 2013 16:18]

De sleutel tot een goed wachtwoord, is om geen denk-methode te gebruiken die de kraker verwacht.

Een daadwerkelijk random serie van karakters blijft lastig brute-force te kraken. Het probleem is echter dat de meeste wachtwoorden helemaal niet zo random zijn.

Alle typische patronen die mensen gebruiken, maken de passwords minder random, en dus meer voorspelbaar. En daar maken krakers gebruik van.

Wachtwoorden beginnen vaak met een hoofdletter, en niet met een cijfer. Ze bevatten vaak een bestaand woord. En hebben vaak een paar cijfers aan het eind. (Vooral als de password policy verplicht om iedere maand te wijzigen.)

Dat soort zaken maakt het aantal mogelijkheden véél kleiner als je denkt.


Passphrases waren tot nu toe veilig, omdat maar weinig mensen ze gebruikten. Maar hoe meer het gebruikt wordt, hoe onveiliger het word. "correcthorsebatterystaple" is slechts een aaneenschakeling van 4 woorden. Dát is met een dictionary helemaal niet zo moeilijk te kraken als jij denkt!

Ik heb gerekend, en een password met 8 random karakters heeft dezelfde entropie als een passphrase met 4 woorden, met een woordenschat van 9000 woorden. De gemiddelde woordenschat van een Nederlander is 10.000 woorden.....

De woorden die je dagelijkes gebruikt, is slechts een 1000. Dat komt overeen met een password met 6 puur random karakters (simpel te kraken), of 8 typisch gebruikte karakters.

Die veiligheid van passphrases is dus nogal betrekkelijk, omdat het veel te voorspelbaar is.

[Reactie gewijzigd door AHBdV op 27 augustus 2013 17:09]

heb gerekend, en een password met 8 random karakters heeft dezelfde entropie als een passphrase met 4 woorden, met een woordenschat van 9000 woorden. De gemiddelde woordenschat van een Nederlander is 10.000 woorden.....

En dat is waarom je niet je eigen woordenschat gebruikt (al was het maar omdat je dan onmogelijk tot een "willekeurig" resultaat kan komen) maar, bijvoorbeeld, een lijst met 20.000 woorden, en daar 5 (cryptografisch) willekeurige uit (die nog steeds erin slagen een beeld op te roepen en memorabel te zijn en samen een minimale lengte hebben). Dat is om en nabij de 70 bits entropie en dat is ruim voldoende om zelfs de krachtigste brute forcer onderuit te halen (als je het combineert met wachtwoordrotatie), zelfs als die precies weet hoe jij te werk bent gegaan en dezelfde lijst met 20.000 woorden heeft. Als hij dat niet weet is hij een stuk langer bezig.

Met 1 miljoen per seconde wel ja, feit is dat je over miljarden pogingen per seconden praat (standard desktop PC met grafische kaart van ~200 euro).

Wordt wel eens onderschat door managers die tegen minder onveilige wachtwoorden zijn (en wachtwoorden bestaande uit 8 characters veilig genoeg achten...)

Standaard putten wij in NL uit 92 en niet 72
Een 'standaard' PC met een grafische kaart van ~200 euro kan ongeveer 5.000 miljoen pogingen per seconden doen (ja, m miljard dus).

Kortom: characters van 8 characters zijn zeer onveilig (maar dat wisten we allemaal toch al?)

Ik nog niet, en mcmd hierboven blijkbaar ook niet want die schatte 23 jaar rekentijd dus ik ben gelukkig niet de enige

Wist natuurlijk wel dat 8 character wachtwoorden over het algemeen onveilig zijn omdat er vaak logica (woorden, oplopende getallen etc) in zit, maar dat t ook voor brute-force zo onveilig was had ik me nooit zo gerealiseerd.

Nice, Geniale tool (wel is gebruikt om WPA2 key mee te kraken had een 14GB dictionary - en mijn 660TI deed toch 65k keys per seconde dacht ik?)

Voor nvidia is er Cudahashcat (OCL = AMD)

Leuk dat je er ook AD accounts mee kan kraken tegenwoordig

[Reactie gewijzigd door 3DDude op 27 augustus 2013 17:13]

ActiveDirectory kon volgens mij altijd al, maar de password-mask zit er juist nu in verwerkt.

De password-mask zorgt er voor dat wachtwoord combinaties die niet mogelijk zijn ook daadwerkelijk worden overgeslagen.

Met de AD toevoeging hebben ze een password-mask gemaakt die gebaseerd is op de "Password Policy"

Minimum Password Length: 7 (kun je alles t/m 6 tekens al overslaan)
Password Complexity: (kun je alle wachtwoorden met bijvoorbeeld alleen nummers overslaan)

• English uppercase characters (A – Z)
• English lowercase characters (a – z)
• Base 10 digits (0 – 9)
• Non-alphanumeric (For example: $, #, or %)

En dit, mensen, is waarom restricties op soorten wachtwoorden een heel slecht idee zijn. Plotseling verlaag je de hoeveelheid mogelijkheden (als dat alles benodigd is) met een flinke factor.

In de meeste gevallen zorgt het toch voor vertraging.
Geen policy hebben zorgt er voor dat mensen hele eenvoudige wachtwoorden nemen zoals bijvoorbeeld koe, kat, hond, de naam van een geliefde of iets anders eenvoudigs. Allemaal dingen welke redelijk hoog in de dictionaries staan. Een lowercase wachtwoord van 3 (17576 mogelijkheden) of 4 (456976 mogelijkheden) karakters is zo in een paar seconden gevonden. Met een policy maak je de wachtwoorden complexer. Minimaal 8 karakters met minimaal 1 hoofdletter, 1 kleine letter en 1 cijfer geeft dan al 722.204.136.308.736 mogelijkheden. Voeg daar ook nog eens verplicht 1 leesteken aan toe en het neemt exponentieel toe.

Behalve dat 9 van de 10 gebruikers de hoofdletter aan het begin zetten en het cijfer op het eind. Waarmee je het juist weer een flink stuk makkelijker maakt om het wachtwoord te raden.

Wachtwoordrestricties in de vorm van 'zoveel hoofdletters, cijfers, rare tekens en lengte x' zijn niet veel meer dan regels om wachtwoorden te verzinnen die moeilijk zijn te onthouden en makkelijk te raden.

[Reactie gewijzigd door harryvr op 27 augustus 2013 17:40]

Je hebt het nu over de praktische kant en je hebt gelijk dat het er voor zorgt dat mensen meer tekens gaan gebruiken om zo het aantal mogelijkheden te vergroten.

Echter wat ExNomenDei zegt is ook zeker waar. In het simpele voorbeeld dat je minimaal 1 cijfer MOET gebruiken, weet je nu dus van te voren dat er bijvoorbeeld ten minste 1 cijfer in voorkomt. Dus op ten minste 1 positie verlaag je dus het aantal mogelijkheden naar 10 in tegenstelling tot de 10+26+26 die je eigenlijk zou willen (in het geval van enkel cijfers en grote letters/kleine letters). Als je dus drie of 4 voorwaarden hebt in een wachtwoord van tenminste 6 letters (en regelmatig ook maximaal 10 ) ga je er effectief gezien voor dit soort programmas op achteruit kwa veiligheid.

(Ik raak een beetje offtopic misschien) De truc is dus de tussenweg: mensen 'motiveren' om een goed wachtwoord te kiezen zonder teveel specifiek restricties op te leggen. Zie ook http://inside.indivirtual.nl/2011/03/password-policy/ dat (vind ik) best wel een goed overzicht geeft in het gehele probleem.

Wat zeg je nou...
Als er minimaal één cijfer moet in komen, verhoog je op elke positie het aantal mogelijkheden van 26 naar 36. Je gaat er qua veiligheid wel degelijk sterk op vooruit

Dit is niet waar, door meer soorten karakters toe te voegen komen er in totaal meer combinaties wachtwoorden bij (voor alle users) dan er af gaan. Alleen mensen die al ingewikkelde wachtwoorden hadden, gaan er een beetje op achteruit.

je kan zelf het verplicht aantal karakters van je policy bepalen, alleen zijn er slordige mensen die hem domweg niet aanpassen

Eh, OpenCL is volgens mij platformonafhankelijk? Kan op zowel AMD als Nvidia GPU's hoor. Staat nota bene in het artikel dat zowel Nvidia als AMD GPU's ondersteund worden (laatste regel).

[Reactie gewijzigd door Seal64 op 27 augustus 2013 16:15]

OpenCL kan zelfs op de CPU draaien.

Blijft een interessant feit dat policies die bedoeld zijn om de beveiliging te versterken (minimaal zes tekens, een letter, een cijfer en een leesteken bijvoorbeeld) uiteindelijk juist tegenovergesteld werken

tegenovergesteld? err nee. Rainbowtables, dictionary lists etc zijn nog altijd 100000x sneller dan een brute force.

Totaal niet waar, door de parallelle kracht van de GPU is het real time kraken op de GPU met een hybrid attack (bruteforce voor de korte paswoorden + wordlist + permutations + mask + pattern based) van hashes van bepaalde (onveilig voor paswoord opslag) hashalgoritmes al veel sneller dan rainbowtables. (voornamelijk md5 en SHA varianten, met of zonder gebruik van salts)

Als je met rainbowtables wilt werkten voor paswoorden langer dan 10 tekens heb je zo gigantisch veel opslag ruimte nodig. En wanneer hashes gesalt zijn met een willekeurige salt dan moet je voor elke database met hashes die je te pakken krijgt een nieuwe rainbowtable laten genereren. En dat is natuurlijk niet wat je wilt als je al rainbowtables gebruikt want je gebruikte ze juist om tijd te sparen.

Hybrid attacks op PC's met 8 of meer snelle ATI GPU's. En dan nog moet de hacker voor hij begint door patroon analyse (en analyse van de doelgroep waar je hashes van dan komt) een groot deel van de combinaties er van te voren al uit filteren of hij vind na 100 jaar nog niks. Daarom dat hackers grote lijsten van paswoorden willen, door een aantal de eerste keer te kraken komen ze achter patronen die ze dan weer gebruiken om het aantal combinaties dat ze moeten proberen flink te verlagen. Dan vinden ze weer meer paswoorden die hun weer toelaat om een beter patroon te vinden. Uiteindelijk worden alle voorgaande analyses en wordlists ook gebruikt voor de volgende database van hashes die ze te pakken krijgen. Een enkelvoudig paswoord dat complex genoeg is en gehasht is met een algoritme bedoelt voor paswoord opslag is NIET te kraken door de gemiddelde hacker of zelfs een botnet. (Misschien wel door de NSA of de Chinezen, wie weet hebben die al een quantumcomputer)

MD5, SHA en dergelijk algoritmes zijn NOOIT specifiek ontwikkelt voor veilige paswoord opslag. Immers toen ze uitgevonden werden moesten ze snel werken op hardware die nu totaal verouderd is. En dus wanneer de hardware steeds sneller word, worden deze hashing algoritmes steeds onveiliger.

(BCrypt,BCrypt,BCrypt,BCrypt,BCrypt,BCrypt, gebruik BCrypt jij idioot!) --> zie reactie DFyNt2U

En veruit de meeste tweakers hier hebben een totaal verkeerd beeld van rainbow tables. De meeste denken dat het een fancy naam is voor een database waarin elke hash en het bijbehorende paswoord zit opgeslagen. Nou, forget it. Neem alle paswoorden van 10 tekens lang en korter met alleen gewone letters en hoofdletters.
Da's 26 kleine letters + 26 hoofdletter = 52 en dat tot de 10de macht (paswoord lengte)
Weet je hoe groot je harde schijf moet zijn om dat op te slaan?
(Blitzdoctor geeft het antwoord onder mij)

Voor het kraken van hashes zijn er twee mogelijkheden
1) Probeer elk mogelijk paswoorden tot je een match hebt --> kost gigantisch veel tijd
2) Doe exact hetzelfde maar doe het maar een keer en sla de database op zodat je daarna eenvoudig kunt opzoeken welke hash bij welk paswoord hoort --> kost gigantisch veel opslag ruimte

Een "regenboogtabel" is de weg tussen deze twee in, een "time–memory tradeoff"
Wat er gebeurd wanneer je een rainbow table gegenereerd (en dit duurt gigantisch lang, maar hoeft maar een keer te gebeuren) is het volgende:

Je begint met het eerste mogelijke paswoord. In ons geval "aaaaaaaaaa".
Daar bereken je de hash van. Stel dat we een 32 bit hash krijgen
( afhankelijk van het gebruikte algoritme)
Nu vereenvoudig je die hash (reduce).
Bijvoorbeeld, je neemt alleen de eerste 6 bit van je hash.
Nu gebruik je deze hash als paswoord (dus input voor je hash algoritme) en berekent daar weer de hash van.
Nu vereenvoudig je deze hash weer en gebruikte die eenvoudige hash als paswoord om weer een nieuwe hash te genereren.
Wanneer je uiteindelijke bij de laatste hash bent aangekomen sla je alleen de begin hash en de laatste hash op in je database.

Een keten (chain) in een "regenboogtabel" bestaat dus uit
start paswoord --> starthash --> eindhash
(alle miljoenen hashes hier tussen worden NIET opgeslagen)
En zo worden er lange ketens gevormd. Onze rainbow table is klaar.
Nu willen we een hash opzoeken in onze rainbow table:
Het algoritme is:

• Start
• Zoek voor de hash in de lange lijst van laatste hashes, als dat er is breek uit de loop
• Zoniet, vereenvoudig de hash in een paswoord en hash het paswoord
• Ga naar start
• Wanneer de hash overeenkomt met de laatste hash in je lijst dan is het deze keten die de hash bevat waarvan jij het paswoord wilt weten.

Je hoeft nu nog maar een paar miljoen berekeningen te doen. Exact dezelfde die je computer deed voor deze keten op het moment dat je de rainbow table maakte, alleen die berekeningen werden dus niet opgeslagen. Alleen het eerste antwoord en het laatste.

Snap ie? Dat is de geheugen - tijd compromis.

Ik vind het vernuftig maar GPU's zijn zo gigantisch veel sneller dan zelfs de snelste SSD's tegenwoordig dat rainbow tables alleen nog effectief zijn wanneer:

• Je al een tabel hebt die je meteen kunt gebruiken (NTLM hashes bv)
• Je terabytes aan RAM hebt, en er altijd stroom op je RAM staat zodat je je waardevolle rainbow tables in je vluchtig geheugen nooit kwijt raakt
• Je de NSA bent en datacenters hebt gebouwd waar je petabytes aan opslag ruimte tot je beschikking hebt. En de beste wiskundige in de wereld want zonder patroon analyse heeft zelfde de NSA niet genoeg opslag ruimte (bij gebruik van lange salts) of computerkracht (bij expres trage algoritmes zoals Bcrypt) voor een rainbow table bij het gebruik van een hash algoritmes dat ontwikkelt is speciaal voor paswoord opslag.

De hoofdreden dat er de laatste jaren zoveel nieuws naar buiten is gekomen van paswoord lekken is dat het internet bestaat uit idioten. Idioten die een totaal verkeerde manier van paswoord opslag gebruiken en idioten die die opslag vullen met de meeste stupide paswoorden. En altijd hetzelfde paswoord gebruiken.
Uiteindelijk zijn er misschien wel ontelbare mogelijke paswoorden, maar mensen zijn zo voorspelbaar dat je die lijst gigantisch kunt terug brengen tot je een lijst hebt van effectief gebruikte paswoorden. Daarom dat die database lek van die grote dating site een aantal jaar terug zo een gigantische effect heeft gehad.
Nadat die database voor 99,9% gekraakt was hadden de crackers de beste mogelijke tool voor patroon analyse ooit en de gevolgen daarvan zijn bekend. De ene na de andere hash database moest er aan geloven.

Bij het gebruiken van willekeurige salts of algoritmes die zichzelf miljoenen keren herhalen voor je de uiteindelijke hash hebt is het niet meer mogelijk om rainbow tables te gebruiken. Immers, door het injecteren van een lange salt in een kort paswoord is de input voor je hashgenerator al zo groot dat je voor een rainbow table meer geheugen nodig hebt dan er deeltjes in het universum zijn.

[Reactie gewijzigd door Kain_niaK op 27 augustus 2013 18:33]

Wellicht verstandig om uit te leggen waarom bcrypt belangrijk is? Je lijkt er tenslotte veel nadruk op te leggen

bcrypt maakt gebruikt van het blowfish encryptie algoritme. Op zich niet bijzonder, maar blowfish heeft een aantal karakteristieken die het erg moeilijk maken om het mbv GPUs te kraken.

Blowfish heeft nl een 'key schedule' die langdradig is en relatief veel geheugen gebruikt (ongv 4 kilobytes iirc). Als je dus blowfish instelt met een bepaalde key, dan duurt het relatief lang voordat hij kan beginnen encrypten/decrypten, maar is daarna snel in het encrypten/decrypten zelf. Dus een groot bestand decrypten is niet een probleem, maar veel kleine bestanden met verschillende keys wel.
Dat laatste maken we dus gebruik van want key=wachtwoord. Het is op dit moment erg moeilijk om iets effectief te paralleliseren in de GPU als het veel geheugen gebruikt. Niet omdat de GPU zo weinig ervan heeft, maar omdat de cache van de GPU gewoon de bottleneck wordt en al die GPGPU cores zitten te wachten op data.

Dat maakt bruteforce mbv GPU veel minder effectief, combineer dat met een goede salt en ook rainbow tables zijn getackeld.

Nu is het natuurlijk de mens de zwakste schakel, met slechte ww keuzes. Das wat lastiger aan te pakken.

PS: Blowfish heeft al weer wat opvolgers. Dus zie het niet als heilig, das is bij cryptografie nooit zo.

Thx! Tijd ontbrak mij om dieper op Bcrypt in te gaan. Mijn baas is al pissed momenteel. (Neeee, niet slaan ... AAAUW )

Maar het grootste voordeel met Bcrypt is dat het aantal iteraties in te stellen valt. En dus kun je beter met de hardware mee schalen. Als het nu nog te traag is om in real time 100 miljard iteraties uit te voeren voor je een paswoord hebt dan heb je met bruteforce hetzelfde probleem. Maar wanneer de bruteforcers dat probleem straks niet meer hebben door betere hardware dan heb jij ook geen probleem meer met het opschalen van je aantal iteraties.
Dat is in mijn opzicht de grootste kracht van Bcrypt. Voor een gelekte database nu die over 10 jaar gekraakt word bied dat natuurlijk geen bescherming. Maar als je database nu, 10 jaar later gekraakt word is dat niet zo heel erg. En anders moet je maar TrueCrypt gebruiken met een complexe paswoordzin.
Da's zelfs NSA veilig voor de komende 25 jaar.

[Reactie gewijzigd door Kain_niaK op 27 augustus 2013 18:07]

En veruit de meeste tweakers hier hebben een totaal verkeerd beeld van rainbow tables. De meeste denken dat het een fancy naam is voor een database waarin elke hash en het bijbehoorende pw zit opgeslagen.
Nou, forget it. Neem alle pw van 10 tekens lang en korter met alleen gewone letters en hoofdletters. Da's (26 x 26) tot de 10de macht. Weet je hoe groot je hardeschijf moet zijn om dat op te slaan?

Je berekening is fout. Het is (26 + 26) tot de 10de macht.

Laat ons het nog uitbreiden naar mixed-case alfanumeriek. Als je het even beperkt tot 8 karakters, dan heb je met 160 GB genoeg voor een MD5 db.
Ga je naar 9 karakters (aantal combinaties verveelvoudigt met 62) dan heb je met 864 GB genoeg
http://project-rainbowcrack.com/table.htm

Tegenwoordig heb je consument HDs van 1TB, dus met enkele van die schijven heb je voldoende ruimte.

[Reactie gewijzigd door StijnH op 28 augustus 2013 12:08]

Ik heb mijn berekening verbeterd, perongeluk x ipv + getypt. Maar 52 tot de 10de macht is 144555105949057024
Stel dat je hash 32 bits lang is. Dan heb je alleen al om alle mogelijke hashes in een database op te slaan 32 x 144555105949057024 bits nodig.
Da's 578.2 PB . Nu weet ik niet waar jij je harde schijven koopt maar ik kan deze opslag ruimte niet betalen. En dan heb je alleen nog maar een lijst van alle mogelijke hashes, zonder de bijbehoorden passwoorden en deze database is TOTAAL iets anders als de rainbowtables waar jij het nu over hebt.

16 bit per MD5 hash voor alle hashes van 8 karakters = 16((26 + 26 + 10)^8) bit en dit is 436.7 TB. (zonder de passwoorden)

Die 160 GB waar jij het over hebt is de rainbowtable en dit is NIET een database van alle mogelijke hashes en passwoorden, en daar ging het grootste deel van mijn post juist over.

Lees misschien eerst eens een volledige post voor je er op reageert.

edit: Blitzdocor bedankt voor het verbeteren van mijn foutje

[Reactie gewijzigd door Kain_niaK op 27 augustus 2013 18:11]

klein foutje nog: 26^10 is 141167095653376, 52^10 is 1.44*10^17
Je berekening komt dan op 4 exabyte uit zelfs.

Correct! Weer verbeterd Ik heb koffie nodig
(het is hier 9:25 AM)
Maar nu maak jij ook een klein foutje.
Het is 0.5782 exabyte !
Volgens wolfram alpha bijna 6 keer meer dan Data van Star Trek in zijn hoofd heeft.

[Reactie gewijzigd door Kain_niaK op 27 augustus 2013 17:29]

Ik had inderdaad een fout gemaakt ivm die databases.

Het ligt wel iets genuanceerder gezien er hashing algoritmes zijn die express erg veel CPU gebruiken voor het hashen. Voor 1 hash niet zo erg, als je er miljoenen wilt hebben wel.

Weet niet meer welk algoritme ik laatst tegen kwam, maar m'n videokaart deed daar 'maar' 20.000 ww per seconde op. Ter vergelijking, met md5 bijna 2.000.000 per seconde. Das toch aanzienlijk (even afgezien van dat ik er van schrok, zo'n fancy videokaart heb ik nou ook weer niet 1.95M hashes p/s wtf...).

Precies, scrypt bijvoorbeeld werkt met een grote vector van pseudowillekeurige bit strings die geregenereerd worden als onderdeel van het algoritme. Wanneer je dat rechtstreeks implementeert moet je die volledige string in je RAM houden. Niet te vergelijken met md5.

Wanneer je nu gaan bruteforcen met een GPU heb je een probleem, binnen de kortste keren zit het RAM van je GPU vol. En daarom is scrypt veel weerbaarder tegen bruteforcing op GPU en speciaal ontwikkelde hardware.

Ik denk dat de cryptocurrency Litecoin gebruik maakt van scrypt om zo te voorkomen dat er ASIC's komen om Litecoin te minen.

In mijn voorbeelden heb ik het alleen over hash algoritmes of KDF die nooit ontwikkeld zijn voor veilige paswoord opslag. In tegendeel, md5 is ontwikkelt om supersnel te zijn en te werken met hele zwakke hardware. Dat is handig als je met chips in bankkaarten werkt maar werkt tegen je wanneer iemand je md5 probeert te kraken met een GPU die een paar 100W aan energie kan gebruiken.

Mwa dat is wel kort door de bocht, als je de polcies niet insteld dan gebruiken heel veel gebruikers zéér voorspelbare en korte wachtwoorden omdat die makkelijker te onthouden zijn. Het heeft dus zeker wel nut, het probleem is dat je aan de andere kant ook weet wat er in moet zitten en hoe lang hij minimaal is (dat elimineert nogal wat mogelijkheden).

Policies worden pas een beveiligingsrisico als ze sterke wachtwoorden gaan tegenwerken

Nouja als jij als policy hebt: minimaal 5 letters, 2 cijfers en één leesteken dan kan je er gif op innemen dat 90% van de mensen exact datgene gaat doen.

Als jij als policy hebt minimaal 30 tekens (letters, cijfers, spaties, leestekens) dan heb je pas een goede policy.

Nee, een heel slechte: dan vind je het wachtwoord op 2 sticky notes onder de monitor (1 past niet ), en/of moet systeembeheer elke dag een password-reset uitvoeren, waardoor social engineering makkelijker wordt.

Misschien dat je een echte passphrase kan afdwingen van 30 tekens (eerste zin van hoodstuk X van dat boek dat toch op tafel ligt), als je de eis van cijfers en leestekens weglaat. Maar zeg zelf: hoeveel mensen denk je dat een zin van 30 tekens foutloos en blind kunnen intypen?

Daar heb je password managers voor.

En zinnen gebruiken als password is niet handig, zeker niet als het boek ook ergens op internet te vinden is. Als je dat doet, doe dan op z'n minst wat typo's in de woorden.

Een goed wachtwoord is bijvoorbeeld N2 !FdPZ2YKt/ve S1\\l/B

[Reactie gewijzigd door Ramon op 27 augustus 2013 15:59]

Leuk dat dat wellicht technisch goed is, in de praktijk gaan dergelijke wachtwoorden niet werken. Als men uiteindelijk voor een password manager weer een simpel wachtwoord gebruiken om voor de rest moeilijke wachtwoorden te gebruiken is het hele idee ook een beetje weg.

Nee, daar ben ik het dus totaal niet mee eens. Het grootste risico tegenwoordig is dat je een account hebt op een site die gehackt wordt en waar de hashes op straat komen te liggen.

Heb jij dan een zwak wachtwoord, en ben je zo slim om dat wachtwoord op andere sites ook te gebruiken (lekker makkelijk), dan ben je fucked en kan iedereen bij bijvoorbeeld je mail of andere belangrijke spullen komen. Het is dus belangrijk om overal een ander wachtwoord te hebben (en dan niet alleen een nummertje of een vraagtekentje erbij).
Daarnaast als jij een wachtwoord zoals hierboven kiest dan zit je hoogstwaarschijnlijk ook nog eens bij de 10% van de wachtwoorden die niet gekraakt zijn bij een site-hack en ben je gewoon veiliger.

Natuurlijk is er een risico dat je thuis-PC wordt gehackt of iemand met fysieke toegang kan je password manager benaderen, maar dat risico is marginaal tov sites met jouw data die gehackt worden.

[Reactie gewijzigd door Ramon op 27 augustus 2013 16:15]

Je kan daar vrij eenvoudig nog een stapje verder in gaan, door op iedere site een ander email adres te gebruiken (welke simpelweg forwards zijn naar je algemene email adres). Dat is uiteraard wat meer werk bij het aanmaken van een nieuw account (al kun je het met een beetje programmeerskills automatiseren), maar het kan nuttig zijn wanneer security van groot belang voor je is. Het is op zichzelf staand absoluut geen veilige methode, maar uiteindelijk is veiligheid toch een kwestie van "het zo moeilijk mogelijk maken".

Dat is helemaal geen beter wachtwoord dan bijvoorbeeld: Ditiseenmakkelijkteonhoudenwachtwoord!

Ja, je gebruikt meer verschillende tekens, maar het is niet te onthouden voor de gebruiker. Tevens gaat het bij het bruteforcen alleen om het aantal mogelijkheden. Die kan je op 2 manieren verhogen, namelijk door meer tekens te gebruiken, of door een groteren tekenset te gebruiken.
Ik ben dan voor een langer wachtwoord ipv onmogelijke tekens gebruiken, want dat verlaagd de gebruiksvriendelijkheid enorm.

Ik heb nu 70 verschillende wachtwoorden in mijn password manager. Jij wil dus zeggen dat een gemiddelde gebruiker 70 verschillende zinnen kan onthouden?

Ik weet niet maar ik vind het gebruiken van een password manager toch vriendelijker.

Dan maak je er toch van <website>+<passphrase> Moet ook te regelen zijn met je password manager, maar is tenminste ook bruikbaar als je daar even geen toegang to hebt, onverhoopt. Sowieso werkt je password manager niet voor Windows logon, om eens iets te noemen.

Dat is volgens mij juist niet handig als passwordscheme. Als er eentje gekraakt wordt is het te makkelijk te achterhalen wat je wachtwoord elders is door het website deel te vervangen.

Valt wel mee hoor.

Wat denk je van een wachtwoord als:

"mijnhondiseenbeetjedom"

"diefietsheefteenlekkeband"

"mijnhuismoetnodiggeverfdworden"

Stuk voor stuk makkelijk te onthouden, eventueel met een reminder zoals

hond-dom
fiets-band
huis-verf

Voeg nog een getalletje en/of een uitroepteken toe en je krijgt wel hele sterke wachtwoorden. Zoals dus

"3mijnHuismoetnodiggeverfdworden!" of:

"ditismijnwachtwoord.ikhouvanmijnwachtwoord". 42 tekens, begint u maar met het kraken als je er alleen een hash van hebt...

Mensen moeten opgevoed wordt dat een wachtwoord niet moeilijk hoeft te zijn maar wel lang.

Dus geen a0b1c2d3 wat heel ingewikkeld lijkt maar gewoon "mijn3kattenzijnthuis" of "ikhounietvanspinazie". En DAT kunnen we mensen prima aanleren.

Zelfs met 5 eenvoudige woorden van 3 tot 4 tekens elk kun je vrijwel onkraakbare wachtwoorden maken.

"hondkatmuishuisverf"

"hetwaseenbrugverweg"

"omagaatnaarhuis"

"tweakersiseennuttigesite"

Het is al bewezen dat passphrases als wachtwoord ook goed te kraken zijn. Als je het kraken echt moeilijk wilt maken dan maak je in sommige woorden typo's zodat een dictionary attack niet meer werkt.

Behalve dat mensen dat niet kunnen onthouden en dan met patronen gaan werken (of erger nog, het opschrijven en bij de pc bewaren)

zoals de lengte van wachtwoorden ernstig beperken, ik heb dit al een aantal keer tegen gekomen. dan wil je een wachtwoord invoeren dat lekker lang en sterk is krijg je een melding password length has exceded x characters

DAT vind ik ook een van de belachelijkste eisen aan een wachtwoord, de maximale lengte.
Ja, uiteraard, als je meer dan 255 characters gebruikt oid, maar meer dan 5 maar minder dan 9 is echt ronduit debiel.

Ik wou ooit als paswoord het woord "penis" gebruiken.
Zegt de computer: "U paswoord is niet lang genoeg"

sommige policies doen dat ook.
omdat ze zo streng zijn zijn je pasworden niet meer te onthouden en moet je ze op de een of andere manier bijhouden.

Heb zo'n systeem gekend waar alle voorspelbare varianten van paswoorden geblokkeerd werden.
bvb P@ssw0rd werd daar niet toegelaten. alle leter/cijfer/teken combinaties die in een woordenboek staat werden ook afgekeurd.

gevolg : over post -it's, notaboekjes, ... hééél veilig allemaal

Ach... hier in huis moeten we elke 2 maanden ofzo ons password veranderen. Elke keer een ander sterk wachtwoord onthouden gaat me niet lukken, en dus... een patroon dat voldoet aan de minimum policy gaan gebruiken. Nog niet opgeschreven trouwens, maar wel veel minder sterk dan het ww dat ik eerst gebruikte (en alleen hier).

gevolg : over post -it's, notaboekjes, ... hééél veilig allemaal

Zolang jij met dat analoge equivalent van een password vault zorgvuldig te werk gaat is dat verreweg te prefereren boven brakke passwords.

Het einde van het wachtwoord komt zo wel snel dichterbij, het duurt denk ik niet lang meer voordat we allemaal een (USB) stickje hebben oid. met een 1024bit key er op om ergens in te loggen of overal two-step authentication voor nodig hebben.

Valt best mee hoor. Wachtwoorden - of beter passphrases - zijn prima door mensen te onthouden en bevatten genoeg entropie om nog een tijdje vooruit te kunnen. Een goede passphrase van 20 tekens bevat gemakkelijk 64 bits entropie, voldoende om nog minstens 10 jaar vooruit te kunnen.

Dit soort entropie getalletjes zegt weinig over de daadwerkelijke sterkte van een password.

Het kraken van passphrases is een kwestie van meerdere woorden uit de dictionary achter elkaar zetten. En dan is een 20 tekens passphrase in werkelijkheid slechts een 4 woord phrase. En dat heeft een veel kleinere entropie dan het lijkt, omdat de het aantal woorden in de praktijk redelijk beperkt zal zijn, en het aantal woorden slechts heel klein.

Je ziet dat nu al met password krakers die een dictionary gebruiken. Een daadwerkelijk random 8-letter password is nog steeds niet brute-force te kraken. Maar de meeste password zijn helemaal niet random. Zo gauw er maar een daadwerkelijk woord in voor komt, wordt het ploteseling een miljoen keer makkelijker. Omdat het dan woord plus 4 random letters is.

Passwords die goed te onthouden zijn, zullen per definitie ook sneller te kraken zijn. Simpelweg omdat de kraker van dezelfde methode gebruik maakt als de gebruiker.

Wat ik makkelijk te onthouden vind hoeft voor jou helemaal niet logisch te zijn.

Daarnaast, als ik een passphrase gebruik, welke dictionary moet je dan gebruiken?
Nederlands, Engels, Duits? Een eigennaam staat waarschijnlijk niet in een woordenboek, maar is wel makkelijk in een zin te gebruiken.

8 random characters is nog steeds 8 random characters, zelfs als er een woord in staat.
aaaa1111 is sneller gevonden dan zzzz9999.

De passphrase:

'Hoe hard rijden we nu?' vroeg ik.

is enorm makkelijk te onthouden (zeker als je weet dat het antwoord 'zesennegentig' is :-))

Hottentottententententoonstelling. is net zo lang en is maar 1 woord. Ik zie niet helemaal hoeveel geluk je gaat hebben met een dictionary attack voor mijn eerste voorbeeld?

Daar hoop ik maar op dan. Hopelijk een stuk veiliger en tegelijkertijd makkelijker, geen 30 mogelijke wachtwoordcombinaties onthouden altijd.

Enige wat ik hoop is dan dat je niet van zulke western situaties krijgt: "Geef de USB stick hier of ik schiet je overhoop", waar je dan ook meteen alle wachtwoorden kwijt bent.

Die situatie heb je nu ook al. Als men je telefoon afneemt en eist deze te unlocken kunnen ze bij mij ook overal in, zelfs met two factor waar een keurige app voor is.

Als we dan toch met zo'n ding moeten slepen, waarom zouden we ons dan beperken tot 1024 bits? Ik zou direct voor 4096 of 8192 bits gaan, dan kan het ding tenminste een paar jaar mee. Met 1024 bits is hij in no time weer achterhaald. De extra productiekosten zijn waarschijnlijk te verwaarlozen, omdat transport en de overige grondstoffen veel meer kosten.

Ik maak al lange tijd gebruik van yubikey Wat dankzij de windows login software ook nog eens prima werkt voor mijn laptop die ik mee neem naar school, zonder mijn key komt niemand op me laptop (of de harde schijf benaderbaar is via linux heb ik niet getest, het ging me meer om het 1e oog privacy. De echte kenners komen er altijd wel in maar mijn laptop staat geen extreem gevoelige gegevens op)

Met zo'n USB stickie lijkt me ook niet echt veilig, die dingen worden om de haverklap vergeten. Dus als je dan ergens anders bent ingelogd en je vergeet je stick Of daar moet ook weer een ww opzitten En two-step, ja als je de eerste hebt dan kun je toch het prgtje gebruiken voor het volgende ww of zie ik dat verkeerd ?

[Reactie gewijzigd door bonus op 27 augustus 2013 15:37]

Het einde van het wachtwoord komt zo wel snel dichterbij, het duurt denk ik niet lang meer voordat we allemaal een (USB) stickje hebben oid. met een 1024bit key er op om ergens in te loggen of overal two-step authentication voor nodig hebben.

Dat is wel een beetje kort door de bocht, dat het de optie biedt om passwords tot 55 tekens te kraken betekent niet dat het ook maar enigszins mogelijk is om écht random wachtwoorden van die lengte te brute forcen. Dat je een heel eind komt met slim gokken is wat anders.

Het gevaar van wachtwoorden zit veel meer in de vele re-use, maar aan de andere kant zijn dat misschien ook niet de mensen die wachtwoorden van 55 tekens nemen.

[Reactie gewijzigd door Argantonis op 27 augustus 2013 15:41]

Deze tool staat nu op block in de AppLocker policy, website is nu ook niet te benaderen (o.a. websites met keyword hashcat)

Edit @ hier onder: Laten we het zo zeggen dat je niet eens met je linux laptopje in ons netwerk
komt

Edit 2: Ik ga hier niet onze hele security uit lichten. Uiteraard worden mensen na 3 keer gelocked. Ten tweede is AppLocker natuurlijk wel cr*p, aangezien je het bestand gewoon kan renamen en dan zou je het kunnen openen (behalve bij ons dan, want alles is dicht getimmerd).

[Reactie gewijzigd door JerX op 27 augustus 2013 15:33]

Maar daar heb je toch niks aan als je met een Linux laptopje langs komt die direct met LDAP lult?

Je hoeft niet perse in je ActiveDirectory te hangen toch?

Als de AD zo goed beveiligt is bij (de werkgever van) JerX neem ik aan dat het netwerk zelf ook goed beveiligt is en niet-geautoriseerde machines niet op het AD-netwerk komen maar geïsoleerd worden met behulp van NAC of een soortgelijk systeem.

Indien 802.1x authenticatie wordt gebruikt (ook op bekabeld netwerk), dan kun je inderdaad weinig met live-usb/cdtjes en/of eigen computers.

Maar dan kun je dezelfde authenticatie tegen je RADIUS/NAP server aan knallen ipv LDAP, zoalang je maar weet dat ActiveDirectory er achter zit. Het gaat voornamelijk om de password-mask.

Ik zou wel meer doen dan een applocker, als mensen hun eigen laptop je meenemen helpt zo'n applocker helemaal niets. Of even kali booten van een usb stickje of cd.
Je doet er een stuk verstandiger aan om mensen in de ban te gooien als ze meer dan 3 foutieve logins doen.

Dit is juist het tegenovergestelde van wat je moet doen. Dit creëert een vals gevoel van veiligheid bij de sysadmin ('oh, ze kunnen toch niet bij hacktool X'), maar introduceert extra complexiteit en dus potentiële vulnerabilities in je netwerk.

Zorg er liever voor dat alle potentiële aanvalbare items in je netwerk beveiligd zijn met wachtwoorden met hoge entropie die zo min mogelijk gereset hoeven te worden.

Dan zijn je applocker policies verkeerd ingesteld als het renamen al zou werken.
Ik doe het altijd op signature (bij signed executables) of op hash (bij unsigned executables).

Overigens heeft inderdaad ieder bedrijf met AD normaal gesproken wel een password lockout policy (ik zet deze doorgaans wel wat hoger als 3 pogingen omdat je anders continu bezig bent met accounts unlocken, vooral met de mobile devices van tegenwoordig, 1x password change en de mobiele telefoon zorgt voor een account lockout ivm meerdere keren proberen om de mail op te halen - password lockout kan je echt gebruiken voor een denial of service, daarom zet ik deze vaak op 5-10 tries)

Ik heb waar 't kan two step authentication aanstaan, alsnog veilig dus... Toch?

Dat vroeg ik mij laatst ook af.
Ik heb voor een tiental sites two factor aanstaan, maar dat is wel via de google app.
Als theoretisch google gehacked zou worden, kan men dan mijn two factor inzien? Of is dit ook nog eens gekoppeld aan een uniek ID van mijn toestel oid?

De app laad een QR code waar een OTP URL in staat. Die OTP URL voorziet je authenticator van een 'wachtwoord' waarmee de codes gegenereert worden op basis van de huidige tijd (icm met dat wachtwoord uiteraard).

Hoe het aan de kant van Google opgeslagen wordt is me niet duidelijk. Dat dat wereld je naait vaak wel. Zo zeggen Aladdin tokens bijv. te voldoen aan OATH (T|H)OTP, echter mag je met hun software alleen hun tokens gebruiken terwijl in theorie de Google authenticator het ook prima zou moeten doen (ze voorzien hun authenticator echter van meerdere codes, als je zou kunnen achterhalen naar welk wachtwoord dit uiteindelijk vertaald zou de Google authenticator het waarschijnlijk ook prima doen).

FYI, wel OT:
Als je handig bent trek je die string uit de QR code en sla je hem op in bijvoorbeeld Keepass. Ik heb altijd ruzie met het resetten van m'n tel namelijk. Als ik niet meteen m'n username/password opgeef bij de setup wizard van de telefoon gaat het restoren van apps en hun data vanaf google meestal niet goed. Als je je account later instelt start dit om de een of andere reden niet.

Op mijn telefoon (Samsung Galaxy S met Cyanogenmod) komt de SMS backup code niet binnen voor de wizard is afgerond of afgebroken - daar kan ik dus niet op terug vallen.

De 10 codes vind ik onveilig en heb ik nooit opgeslagen. Google geeft je standaard 10 codes die het 1 keer doen (ben daar zelf niet blij mee). Daar kan ik dus ook niet op terug vallen.

Zelf gebruik ik dan oathtool om de code te genereren of een andere authenticator.

OTP URL Syntax: https://code.google.com/p...ticator/wiki/KeyUriFormat
OATH Toolkit: http://www.nongnu.org/oath-toolkit/oathtool.1.html

Bijv:
oathtool --totp -b <google authenticator password>

En ik krijg dezelfde code als m'n telefoon zou genereren (als de klok goed staat ).

De website heeft een key voor jouw account gemaakt (de key die je van een website krijgt met het scannen van de QR code), deze key slaat de website en de google auth app lokaal op . Verder zit er een algoritme achter die aan de hand van de UTC tijd met die key een OTP token genereerd.

Het moment dat jij inlogt maakt de website ook een OTP token aan adv de eerder gemaakte key. Wanneer deze twee keys overeenkomen (meestal binnen een bepaalde tijd) dan wordt er een OK gegeven en kan je inloggen.


Dit hele proces is ook publiek inzichtbaar via de verschillende implementaties, zie bv hier de implementatie in php: https://github.com/PHPGan...a/GoogleAuthenticator.php

In de praktijk zal het testen van passwords met 0 tot 6 tekens of het overslagen van de reeks een onbeduidend verschil in tijd geven.

Ars Technica heeft regelmatig diepgaande artikelen over password cracking en veiligheid. Laat ook maar zien hoe weinig je eigenlijk kan doen als men eenmaal over je hash beschikt door een database breach. Zeer aan te raden.

correcthorsebatterystaple bijv. is zeer eenvoudig te kraken, omdat men niet random alles probeert, maar aan de hand van veel ervaring en bestaande lijsten patronen gebruikt. 4 woorden achter elkaar is bijv. al heel snel makkelijk te pakken. Zeker als je bedenkt dat men miljoenen wachtwoorden per seconde kan proberen met een beetje normale videokaart.

[Reactie gewijzigd door - peter - op 27 augustus 2013 17:24]

ik vraag me af waarom jullie dergelijke informatie en hackprogramma's hier gewoon te geef op jullie website zetten alsof het kraken van andermans password een leuk avontuurtje is waar niets slechts over kan gezegd worden.

Zie het dan maar als een waarschuwing om zelf goede wachtwoorden te gaan gebruiken

@Sander:
Het gaat om 't principe dat niet-complexe wachtwoorden door eenieder die dat wil, te kraken zijn.
Heel internet staat vol met kraaktools, of je maakt 't zelf als je een beetje kunt programmeren. Security by obscurity is geen goed idee.
Als je 't niet op mainstream informatiebronnen zoals tweakers tegenkomt, dan denk je ook niet: 'Goh, ik moet toch maar eens echte wachtwoorden gaan gebruiken...'.
Openheid is hier van (heel) groot belang. Zij het in de zin dat men doorkrijgt dat men betere wachtwoorden moet gebruiken, danwel dat er veiligere inlogsystemen komen (dat je bijv. een USB-sleutel nodig hebt, naast je wachtwoord).

En hoe werkt dat dan met Active Directory ??
Want na 3 keer proberen , gaat je account toch al "locked-out", althans zo doen wij dat .

of mis ik hier nu iets ??

Dit soort tools werken op password hashes, niet via de AD API. Hoe je aan die password hashes komt is weer een ander verhaal, fysieke toegang is de meest voor de hand liggende methode. Geen methode dus die een willekeurige gebruiker op je netwerk toe kan passen. Hier nog wat meer informatie over het bemachtigen van Windows password hashes: Dump Windows password hashes efficiently.