Verschillende gebruikers die hetzelfde wachtwoord kiezen zullen ook dezelfde wachtwoordhash hebben.

Dat is met moderne passwordhashes die een random salt gebruiken per hash wel behoorlijk achterhaald.

* Microsoft Active Directory has left the chat

"Hierbij moet worden opgemerkt dat er geen salting bij het hashen werd toegepast en voor bcrypt 32 iteraties werden gebruikt"

Bcrypt met 32 iteraties is achterhaalt. Maak er minstens 1024 van, of 2048, 4096 (workfactor 10/11/12). Tijdens daamee vermenigvuldigen dus, dan komt er heel iets anders uit :)

Een MD5 hash van een sterk wachtwoord is tegenwoordig nog steeds niet eenvoudig te kraken (toelichting: https://security.nl/posting/796625).

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).

Salts (uniek per account) helpen nauwelijks nog, zie https://tweakers.net/nieuws/217734/#r_19528434 (en https://tweakers.net/nieuws/217734/#r_19529272).

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.

Er zitten fouten in de formules:
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.

Een wachtwoord is pas sterk indien (ik sluit niet uit dat ik iets vergeet):

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...