"Er is zelfs een speciale website waar dit soort 'plain text offenders' aan de schandpaal worden genageld."

Zoals security.nl (:

Het trieste is dat het door een denkfout van de gebruiker kwam dat er pas navraag werd gedaan.

De gebruiker wist zijn wachtwoord niet meer en bij een reset kreeg hij een nieuw wachtwoord per email. Van daar uit gaat hij er meteen vanuit dat de wachtwoorden dus in plain text worden opgeslagen. Maar dat is een foute redenatie, tal van systemen genereren een nieuw wachtwoord, sturen dit door per mail en slaan een salted hashwaarde uiteindelijk op in de database. Ik heb maar weinig reacties gezien die hieraan denken, het grootste deel wil graag meegaan in de gedachte van de TS. Je krijgt je wachtwoord in plain text dus moet die zogenaamd wel in plain text worden opgeslagen.

Dat een wachtwoord onversleuteld verstuurd wordt betekent niet dat deze onversleuteld opgeslagen wordt. Ze worden niet gehashed, maar kunnen wel een reversible encryption gebruiken... En het versturen van wachtwoorden per sms of mail is heel normaal. Allemaal niet geweldig, maar geen bewijs voor unencrypted opslag dus. Slecht onderzoek, sensatiezucht etc..

Beste Bergen, het maakt volgens mij niet zoveel uit waar de pw's onversleuteld staan opgeslagen, tijdens een registratie of anders.
In het geval van Vodafone is dit trouwens een academische discussie daar deze niet ontkennen dat ze pw's on-gehashed opslaan. In het artikel wordt trouwens ook gesproken over encryptie, maar volgens mij worden de pw's gezouten of gepeperd gehashed (meestal) , hashing is geen encryptie .....

Van de KPN heb ik bij de laatste rel trouwens ook mijn nieuwe pw in een briefje zonder enige vorm van beveiliging opgestuud gekregen (tegen het licht houden van de envelope zou het pw zichtbaar maken) ....


Allerlei bedrijven gaan erg onvoorzichtig om met passwoorden, wat ik raar vind daar wij klanten hun belangrijkste assets zijn (zonder klanten => failliet) maar schijnbaar stop er niemand op na dat soort onthullingen, dus het lijkt erop dat het niemand wat uitmaakt .

Waarom vind je dat eigenlijk zo belangrijk ?
Als je kijkt naar de oogst van wel-gehashde password dumps op pastebin et.al , kun je dan oprecht zeggen dat je met een salted hash geen probleem hebt ?

De oogst van een password cracker op een behoorlijk grote dump van userpasswords is vele tientallen procenten minimaal.
Qua impact, zowel publicitair als qua te nemen maatregelen / recovery moet je gewoon bij lekken van een dump van hashes of plaintext hetzelfde handelen.

En zijn er hier echt mensen die een password hebben wat zo goed is dat ze zeggen "geen probleem" als een salted hash publiek geworden is ?


Nogmaals, gegeven de impact en succesrate bij een break die hashed passwords oplevert, kun je werkelijk zeggen dat onversleuteld nog zoveel erger is ?
Je kunt een klein beetje schuld naar de gebruiker schuiven die dan maar een password met 160 bits entropie had moeten kiezen, maar feitelijk moet je respons ook bij lekkage van gehashde passwords al hetzelfde zijn als bij plaintext.

Ik zou niet eens uitsluiten dat er ergens een technische noodzaak was waardoor hashes opslaan geen optie is.
(CHAP authenticatie is een voorbeeld, er zullen wel meer van dat soort shared secret systemen bestaan)


Haha, hoewel ik het vodafone systeem niet kan, ik denk dat je verlies maakt als je op die basis (en dus fixed price) offreert.

Huh ? Je vindt gehashde passwords zo belangrijk omdat er rainbowtables bestaan ?
Kom op, rainbowtables laten zien dat de gebruikelijke hash methoden niet zo veel bescherming beiden voor het overgrote deel van de user passwords.
Als je bedoelt dat rainbowtables de reden zijn waarom je salts wilt gebruiken, inderdaad.


Nee, dat kun je niet.
Je HOEFT het niet met rainbowtables te doen. Rainbowtables zijn een efficiente lookup van precomputed passwords voor hashes zonder,of met een kleine salt.

Je kunt gewoon met een dictionary van een paar duizend woorden elke hash individueel proberen, en nog steeds heel hoge percentages eruit halen.

Je wilt misschien zeggen dat een mega security geek met een password van 25 random karakters dan geen probleem heeft.
Maar ga jij als security officer van een bedrijf waarvan 100K usernames + password hash + 10 karakter salt lekken dan zeggen " niks aan de hand, want de hash en de salt is goed ? "

En wat leg je uit als daar de eerste duizenden passwords uitrollen (de abcdef, de qwerty1234, de LinkedIn1 's ? )

"Eigen schuld van de gebruiker, niet ons probleem ? "

[knip sample van enkele hash met salt die misschien wel een goed gekozen password bevat.]

[knip gebruikers hebben vaak hetzelfde password op diverse sites. Ja duh]


Je kunt salten wat je wilt, maar Linkedin1 en MyLinkedInPW, password1 etc etc vallen er echt wel uit. En van dat kaliber zijn er zoveel dat je niet anders kunt dan reageren alsof het volledige bestand gecompromitteerd is.

Fijn voor de paar paranoide security freaks dat hun 100+ bit entropie password inderdaad wel veilig blijft bij een goede hash en salt, maar daar kun je je response (of je security policy) niet op baseren.


Ik weet niet over welke vroeger je praat, maar Crack in de jaren 90 haalde er tientallen procenten op typische password files. Zonder rainbowtables, en met bestanden waarbij de salt in verhouding tot het aantal accounts vrij groot was.
Het aantal karakters wat binnen brute force bereik ligt is een klein beetje groter geworden (twee of drie letters meer denk ik), maar het grote aantal wat je kunt oogsten komt uit wat gebruikers kiezen.


Ja lekker, moet je mensen nog meer passwords door de strot duwen. Waar ik overigens eerder aan denk zijn intern verschillende authenticatie/trust domeinen waarbij misschien een CHAP-achtige methode gebruikt wordt zodat, o de ironie, het password niet ongecrypt tussen de systemen uitgewisseld wordt...

[knip over financieel ] . Ik bedoelde dat als de systemen ingewikkeld genoeg samengegroeid zijn je dat gewoon in een week niet opgelost krijgt, zelfs niet met een zeer ruim project budget.

Ik wil wel zeggen dat hashes + salt *beter* zijn dan plaintext, maar ik bestrijd dat ze de bij een compromise van de username/hash database je de mogelijkheid geven om anders te reageren dan bij een plaintext password lek.

't Feit dat deze hash amper te brute-forcen is, komt meer doordat 't gebruikte algoritme 'n hoge cost heeft voor de key-schedule, waardoor je op 'n beetje standaard hardware maar 'n paar pogingen per seconde kan doen...

Vergelijk dat met een aantal miljoenen pogingen per seconde voor gesalte MD5-hashes, en je hele salt helpt helemaal niets (als deze bekend is)... Ok, rainbowtabels werken niet meer, maar that's it...

Dat is leuk op je eigen systeem, of op een server met alleen een handvol admin accounts, maar als authenticatie backend voor een LinkedIn, of een MyVodafone, of een andere publieke service met een behoorlijk aantal (echte) login pogingen per seconde kun je toch geen hash gebruiken die op een high end systeem nauwelijks een login per seconde kan verwerken ?

Lees "api call met parameters naar hash functie " waar ik eerst "hash..." schreef.
Maar het probleem blijft : Een authenticatie stap die zodanig zwaar is dat bij verlies van de gehashde passwords dictionary- en brute force aanvallen serieus gehinderd worden , is te zwaar om bruikbaar te zijn voor een systeem waarbij het authenticatie backend een hoog volume van logins moet valideren.

Ik probeer hier de stuurlui aan de wal een beetje te challengen, dat de afwegingen die de stuurman van een MS Vodafone moet maken anders liggen die bij kapitein opblaasboot.

Eh ? Met een salt van 10 karakters heb je al 2^(10*6) verschillende uitkomsten mogelijk voor eenzelfde input.
(Uitgaande nog maar van printable tekens, dus 64 mogelijkheden = 6 bits).
Je rainbow table wordt 2^60 x zo groot en jij noemt dat veel te weinig ?

Ik wil weten waar jij je storage haalt !

(Ik schreef en bedoelde -salt- , niet maximale password lengte )


Dat is niet hoe een salt werkt. Je schrijft alsof het salt geheim kan blijven en dus een verlenging van het password geeft.
Een salt is gewoon bekend in/bij de password hash functie (en dus bij de hacker die de hash-file te pakken krijgt), want die moet in staat zijn het user password te vergelijken met de opgeslagen hash+salt resultaat.
Het doel van het salt is dat als 10 mensen allemaal "password" als password nemen, er toch 10 verschillende hash resultaten in de file staan, waarvan niet te zien is dat ze hetzelfde password hebben.
En waarbij een precomputed rainbow table tig keer zo groot wordt, omdat elk password dus evenveel keren voorkomt als de salt groot is.


Ik wil niet al te hard in de ouwe lullen stand, maar je zou echt naar Crack en Jack the Ripper moeten kijken, en de papers die proefondervindelijke resultaten ervan beschrijven, met welke toegevoegde rule of woordenlijst en weer een paar procent extra accounts uit rolde.
Nogal veel mensen halen hun password uit een feitelijk erg beperkte zoekruimte.

Bij password crackers gaat het bij de dictionary niet (letterlijk) om de Van Dale, maar om woorden, en de 'normale' permutaties die mensen typisch gebruiken als password.
qwerty, asdf, variaties op de username, 1=l, e=3, a=@ , Klingon, staan niet in de Van Dale, maar wel in de dictionary en de permutatie rules op de basis woorden lijsten.

Dan is LinkedIn1, LinkedinPW1, L1nked1n,L1nk3d1n echt niet buiten bereik.
De mensen zijn gewoon niet zo veel veranderd.


Ok, maar uiteindelijk moet je op een end-to-end pad uitkomen tussen user password en authenticatie back end.
Als je tot aan de end-user toe een challenge-response geeft (en dus de hashing door javascript bij de enduser laat uitvoeren) gaat er nooit een plaintext password over de verbinding tussen user en ook niet over alle tussenliggende systemen.

Het nadeel is dat ergens aan de serverzijde een plaintext van het password beschikbaar moet zijn ...


Ik ben geen enorme fan van de boeken van WF Hermans, maar hij kon sommige titels goed kiezen ;-)