Onderzoekers testen kraken bcrypt-wachtwoordhashes met videokaarten
Onderzoekers hebben gekeken hoelang het duurt om bcrypt-wachtwoordhashes met verschillende videokaarten te kraken. Het gaat dan specifiek om hashes van wachtwoorden die uit acht karakters bestaan. Hashes worden gebruikt om wachtwoorden gecodeerd in een database op te slaan. Wanneer de gebruiker zich bijvoorbeeld bij een website registreert en een wachtwoord opgeeft, wordt hier via een hashingalgoritme een hash van gemaakt. De hash wordt in de database opgeslagen.
Dit voorkomt dat als de website wordt gecompromitteerd en de database gestolen, de aanvaller meteen toegang tot de wachtwoorden van gebruikers heeft. Die zijn namelijk gehasht. Een ander kenmerk van hashes is dat een hashingalgoritme voor een gegeven wachtwoord altijd dezelfde hash zal genereren. Verschillende gebruikers die hetzelfde wachtwoord kiezen zullen ook dezelfde wachtwoordhash hebben.
Een populair hashing-algoritme was lange tijd MD5, maar dat is tegenwoordig eenvoudig te kraken. Uit gegevens van datalekzoekmachine Have I Been Pwned blijkt dat de afgelopen jaren de meeste gelekte wachtwoordhashes via het bcrypt-algoritme zijn gemaakt. Voor het onderzoek gebruikten de onderzoekers van Hive Systems verschillende videokaarten, waaronder een cluster van twaalf RTX 4090-videokaarten.
Een dergelijk systeem heeft 99 jaar nodig om een willekeurig gegenereerde hash te kraken van een wachtwoord dat uit acht karakters bestaat (getallen, hoofdletters, kleine letters en symbolen). Tienduizend Nvidia Tesla A100-kaarten zouden er vijf dagen over doen. Hierbij moet worden opgemerkt dat er geen salting bij het hashen werd toegepast en voor bcrypt 32 iteraties werden gebruikt. Uit het onderzoek blijkt ook dat hoe langer het wachtwoord, hoe langer de tijd om het wachtwoord te kraken. Daarbij stellen de onderzoekers dat passphrases gebruikers kunnen helpen om aan een langer wachtwoord te komen.
Dat is met moderne passwordhashes die een random salt gebruiken per hash wel behoorlijk achterhaald.
Dat is met moderne passwordhashes die een random salt gebruiken per hash wel behoorlijk achterhaald.
* Microsoft Active Directory has left the chat
Dat is met moderne passwordhashes die een random salt gebruiken per hash wel behoorlijk achterhaald.
"Hierbij moet worden opgemerkt dat er geen salting bij het hashen werd toegepast en voor bcrypt 32 iteraties werden gebruikt"
En daarom is dat statement verwarrend. Het probleem is niet MD5, maar de combinatie van:
1) Wachtwoorden die zwak zijn en/of die worden hergebruikt;
2) Elke snelle (en weinig werkgeheugen en slechts één CPU-core gebruikende) cryptografische hashfunctie, waarmee -tijdens inloggen- naar de server gestuurde wachtwoorden worden gehasht - waarna het resultaat wordt vergeleken met de eerder in de accounts-database opgeslagen wachtwoordhash;
3) Het in verkeerde handen vallen van een kopie van zo'n accounts-database.
M.b.t. punt 3: daarbij vallen meestal ook niet eenvoudig te wijzigen (en niet gehashte of versleutelde) persoonsgegevens in verkeerde handen; dit "wil je sowieso niet".
Bovendien is, m.b.t. punt 2, de olifant in de porcelijnkast dat serverbeheerders géén resources vretende, deels werkende en alleen voor "sukkels" noodzakelijke, oplossingen willen. Methodes die ook nog eens regelmatig moeten worden aangepast of vervangen, omdat er nóg snellere hardware op de markt is verschenen (met alle ellende van gebruikers die langere tijd niet inloggen, waardoor de zwakkere variant beschikbaar moet blijven - extra complexiteit en extra risico's voor de betrokken gebruikers).
Alles wat we proberen te doen om het probleem van zwakke en/of hergebruikte wachtwoorden te mitigeren, is symtoombestrijding en dus tijdverspilling. En dat laatste kan ten koste gaan van het beter beveiligen van de server(s).
En daarom is dat statement verwarrend. Het probleem is niet MD5, maar de combinatie van:
De definitie van "sterk password" - als in, valt niet te kraken door hashcat met een berg GPUs" is echt fors verschillend wanneer MD5 de hash is, en wanneer bijvoorbeeld bcrypt de hash is.
8 random karakters (upper,lower, cijfers, symbolen) - MD5 duurt 59 minuten met een RTX-4090 GPU , en 17 jaar als het een bcrypt met 32 iteraties is op dezelfde GPU.
(Dat is het aardige van deze link van Hive, er is weer eens een benchmark en wat statistiek)
Dat is een significant verschil .
Natuurlijk - als je de invoer "lang genoeg, random genoeg" kan/mag/wil maken is ook MD5 niet te brute-forcen.
Maar de grens van wat voor je natte vinger (cq ietwat oudere aanbevelingen) 'lang genoeg' was, is behoorlijk verschoven.
En zeker als gebruik ook (wel eens) "overtikken" omvat zit de grens 'acceptabel qua gebruik' en 'veilig genoeg qua lengte' niet zo lekker.
Onzin. Met N salted MD5 hashes duurt het N maal zo lang om zeflde aanval uit te voeren. Dus: stel, hebt een karakterset van 100 (mixed case alphanumeriek + specials), een miljoen hashes en wilt t/m 8 brute forcen. Met een 4090 haalt je ~165G/s.
Zonder salt: 100**8/165**9/3600/24 = 0,7 dagen (16,8 uur)
Met unieke salts: 100**8/*10**6/165**9/3600/24 = 700.000 dagen (700k dagen dus).
Dat vind ik niet "nauwelijks" een verschil :)
Ik denk dat die poster ongelijk heeft, of meer - alleen gedacht heeft aan de situatie een pre-compute aanval op een enkel account.
rainbow tables - als in pre-compute van hashes hebben inderdaad weinig baat meer.
Maar salting is _wel_ zinvol om aanvallers die zich richten op "zoveel mogelijk accounts uit deze dump" het leven moeilijker te maken.
Zonder salting kan ieder gegeneerde hash-uitkomst getest worden tegen de hashes van het hele bestand .
Je hoeft 'Welkom01' (en alle andere dictionary en brute force pogingen) maar één keer te hashen, en vergelijkt de uitkomst met alle accounts in je dump.
Als ieder account een eigen salt heeft, moet iedere test-poging opnieuw gehashed worden voor ieder account.
Hoe meer accounts met unieke salts er in je dump zitten des te meer hash-berekeningen moet je doen .
Om die reden is salting nog steeds erg aan te raden.
Onzin. Met N salted MD5 hashes duurt het N maal zo lang om zeflde aanval uit te voeren. Dus: stel, hebt een karakterset van 100 (mixed case alphanumeriek + specials), een miljoen hashes en wilt t/m 8 brute forcen. Met een 4090 haalt je ~165G/s.
Zonder salt: 100**8/165**9/3600/24 = 0,7 dagen (16,8 uur)
Met unieke salts: 100**8/*10**6/165**9/3600/24 = 700.000 dagen (700k dagen dus).
Dat vind ik niet "nauwelijks" een verschil :)
100**8/165**9/3600/24 = 1.28e-09
100**8/165e9/3600/24 = 0.7
100**8/*10**6/165**9/3600/24 >> error
100**8*10**6/165**9/3600/24 = 0.0013
100**8*10**6/165e9/3600/24 = 701459
Onzin. Met N salted MD5 hashes duurt het N maal zo lang om zeflde aanval uit te voeren. Dus: stel, hebt een karakterset van 100 (mixed case alphanumeriek + specials), een miljoen hashes en wilt t/m 8 brute forcen. Met een 4090 haalt je ~165G/s.
Zonder salt: 100**8/165**9/3600/24 = 0,7 dagen (16,8 uur)
Met unieke salts: 100**8/*10**6/165**9/3600/24 = 700.000 dagen (700k dagen dus).
Dat vind ik niet "nauwelijks" een verschil :)
100**8/165**9/3600/24 = 1.28e-09
100**8/165e9/3600/24 = 0.7
100**8/*10**6/165**9/3600/24 >> error
100**8*10**6/165**9/3600/24 = 0.0013
100**8*10**6/165e9/3600/24 = 701459
Inderdaad. 165 G/s (giga-hashes per seconde , blijkbaar) is 165e+9 (165*10^9) . Niet 165^9 .
En 1M accounts met 8 karakters uit een alfabet van 100 tekens met 1M unieke salts geeft je 100**8 * 10**6 hashes die geprobeerd moeten worden.
Je deelt dat door 165*10**9 (aantal hashes dat per seconde getest kan worden) , dat geeft de tijd in seconden. En dat deel je door (60*60*24) [aantal seconden in een dag] en dan kom je op de tijd in dagen.
(niet degene die de oorspronkelijke berekening postte)
Terug naar het begin. Claim was: "Salts (uniek per account) helpen nauwelijks". Reactie: onzin, salts doen er wel toe. N salted hashes duur N maal zo lang om te kraken. Dus bij 1M salted hashes 1M maal zo lang als niet salted.
De juiste berekening lijkt me: karakterset^lengte x salts / snelheid. In het genoemde voorbeeld:
Unsalted:
100^8 * 1 = 10.000.000.000.000.000 / 165.000.000.000 = 60.606s / 86.400 = 0.70 dagen.
Salted:
100^8 * 1.000.000 = 10.000.000.000.000.000.000.000 / 165.000.000.000 = 60.606.060.606s /86.400 = 701.459,03 dagen
Blijkbaar klopt de notatie in de orignele berekening niet ("x^y" versus "x*10^y"). De berekeningen, uitkomsten en het punt kloppen wel.
1) Het in geen enkele dictionary vóórkomt (zeker niet in RockYou2021). Als dat wél het geval is, heeft een "slimme" brute force zin (en kunnen alle berekeningen voor domme brute force de vuilnisbak in), én
2) De "eigenaar" het nooit voor een ander account heeft gebruikt (je kunt immers nooit zeker weten dat het daardoor niet in verkeerde handen is gevallen), én
3) De "eigenaar" er geen informatie in gebruikt die gerelateerd is of was aan die eigenaar, diens familie, vrienden, werk of collega's (zoals postcode, geboortedatum, adresgegevens, werkproject etc.). Beter, het wachtwoord qua onvoorspelbaarheid nauwelijks of niet afwijkt van een (cryptografisch veilig gegenereerde) random reeks "karakters" (hoofdletters en/of kleine letters en/of cijfers en/of leestekens), én
4) Het aantal mogelijke combinaties van "karakters" groot genoeg is om domme brute force voldoende te bemoeilijken, én
5) Het wachtwoord nooit op onveilige wijze is gecommuniceerd of kan zijn afgekeken (of kan zijn "gesnifft" m.b.v. een keylogger, browser-bug of Javvascript afkomstig van een foute of gehackte third-party website). Nb. dit vereist dat het client-device, plus alle firmware en software die "bij één of meer wachtwoorden kan", volledig kunnen worden vertrouwd.
"Probleempje": voor veel mensen is ca. 5 of meer wachtwoorden, die aan criteria 1 t/m 4 voldoen, bedenken en onthouden al een onmogelijke opgave (vooral als deze niet voldoende frequent worden ingevoerd).
==> Om unieke, (cryptografisch veilige) random en zo lang mogelijke wachtwoorden te kunnen genereren, heb je software nodig - zoals een goede wachtwoordmanager. Die kan ook wachtwoorden en andere accountgegevens op een zo veilig mogelijke manier bewaren, in het bijzonder doordat de database (en dus ook backups daarvan) sterk zijn versleuteld. Hoewel niet risicoos is dus zeer verstandig om een wachtwoordmanager te gebruiken - en ervoor te zorgen dat je, na elke wijziging, één of meer backups van de database veiligstelt).
==> Terzijde, als je dat toch doet, zorg dan dat deze de domeinnaam van de website checkt waarop je wilt inloggen, en dat je precies weet hoe die wachtwoordmanager reageert als je verleid dreigt te worden om op een nepsite in te loggen.
==> Als iedereen een wachtwoordmanager gebruikt, heb je, op de server, geen salts en geen resources-vretende-algoritmes meer nodig. Zelfs MD5 zou dan prima zijn (niet doen, uitsluitend om te voorkómen dat sommige mensen kunnen denken dat, indien MD5 nog ergens geschikt voor is, je het ook wel ergens anders veilig voor kunt gebruiken. Het is voor veel mensen namelijk erg lastig om voor specifieke situaties te beredeneren dat je dan juist géén MD5 moet gebruiken). Elke op geen enkele wijze gekraakte cryptografische hashfunctie is dus prima voor dit doel.
==> "Server-side" 2FA heeft dan zéker meer nadelen dan voordelen, weg ermee.
Stop met het verheerlijken van symptoombestrijding, help mee het probleem op te lossen...
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
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.
