Wachtwoordeisen

[Mentalist]

CyBeR schreef op vrijdag 16 september 2011 @ 01:00:
[...]

Voor dit soort data (in essentie configuratiedata) kun je er niet van uitgaan dat die geheim blijft. Als een haxx0rer inbreekt is zoiets het eerste waar 'ie achteraan gaat. En dan heb je dus een probleem: je wilt dan eigenlijk je salt veranderen, maar dat kan niet want je weet niet hoe je de wachtwoorden dan opnieuw moet hashen.

Goed, opnieuw hashen is dan een probleem. True. Al kan je waarschijnlijk ook net als t.net rehashen bij het inloggen.

Hier veroorzaak je dus een probleem voor jezelf. Zelfs als 't geen inbreker was maar een configuratiefout (zoals .php's die niet intepreted worden, dat komt nog best vaak voor) dan is je salt compromised en moet je dus een nieuwe gebruiken. Kan niet.

Dit probleem heb je niet als je salt buiten de webroot staat.

Die extra drempel is alleen niet zo heel boeiend voor je beveiliging. Een salt helpt tegen rainbow tables en (als bijkomstigheid) identieke hashes, meer niet. Je moet 't ook niet voor meer dan dat gebruiken.

En met een enkele systeemsalt heb je dat laatste voordeel dus niet en dat eerste is dan ook al niet meer boeiend want in plaats van md5(passwd) laat de hacker z'n systeem gewoon md5(salt+pw) uitrekenen. Een compleet oninteressante stap dus.

Wèl interessant als de hacker de systeemsalt niet heeft, maar wel alle salts+wachtwoordhashes uit de database heeft.

Verwijderd schreef op vrijdag 16 september 2011 @ 01:12:
Een geheime salt is zinloos want de salt maakt dan technisch gezien deel uit van het wachtwoord.

Als je er zo naar kijk maakt de geheime salt zelfs een wachtwoord als "123" sterk. En zo werkt het ook, zolang die salt geheim is is zelfs het wachtwoord "wachtwoord" niet te kraken, ook al heb je de hele database+unieke salts.

Vanaf het moment dat ik de post van .oisyn las (een heel stuk terug dus al) zag ik al in dat de systeem/geheime salt geen complete oplossing is, maar als extra kan het in bepaalde situaties best helpen. Voor .oisyn zijn post had ik me nog niet bedacht dat de salt er o.a. is om het bruteforcen enorm te vertragen.

Toen ik 5 jaar terug met PHP zat te kloten las ik ook al suggesties om salts te gebruiken, maar toen kon niemand echt goed uitleggen waar het goed voor was. Het zijn ook vooral de GPGPU systemen van vandaag die hier echte grote risico's realistisch maken.

Neem nu jullie oude database met zuiver MD5 sums. Als die database was gelekt was er een groot probleem geweest. Had er dan een systeem/geheime salt in gezeten en de hacker had geen rootaccess, dan was er wat betreft wachtwoorden geen al te serieus probleem geweest.

[ Voor 19% gewijzigd door Mentalist op 16-09-2011 01:35 ]

[CyBeR]

W3ird_N3rd schreef op vrijdag 16 september 2011 @ 01:24:
[...]

Goed, opnieuw hashen is dan een probleem. True. Al kan je waarschijnlijk ook net als t.net rehashen bij het inloggen.

Behalve dat in dat geval al je wachtwoorden ook al als compromised te beschouwen zijn en je dus alles moet resetten.

Dit probleem heb je niet als je salt buiten de webroot staat.

True, maar denk je werkelijk dat dat het enige is wat kan gebeuren?

Wèl interessant als de hacker de systeemsalt niet heeft, maar wel alle salts+wachtwoordhashes uit de database heeft.

Neuh. Hij moet dan een iets langere string bruteforcen. Boo hoo. Wordt pas interessant als je salt langer is dan je hash, maar dan moet je weer aan collisions gaan denken waarmee in veel gevallen je salt buiten spel gezet wordt.

Als je er zo naar kijk maakt de geheime salt zelfs een wachtwoord als "123" sterk. En zo werkt het ook, zolang die salt geheim is is zelfs het wachtwoord "wachtwoord" niet te kraken, ook al heb je de hele database+unieke salts.

Maar we hadden je toch geleerd dat je van die heimelijkheid niet uit mag gaan? Dit is een schoolvoorbeeld van security by obscurity.

Toen ik 5 jaar terug met PHP zat te kloten las ik ook al suggesties om salts te gebruiken, maar toen kon niemand echt goed uitleggen waar het goed voor was. Het zijn ook vooral de GPGPU systemen van vandaag die hier echte grote risico's realistisch maken.

Juist. Het is uitermate simpel om vandaag nog (nouja, morgen) een systeem in elkaar te bakken wat een miljard hashes per seconde kan uitrekenen. Daarmee ga je snel door zo'n keyspace heen hoor.

Neem nu jullie oude database met zuiver MD5 sums. Als die database was gelekt was er een groot probleem geweest. Had er dan een systeem/geheime salt in gezeten en de hacker had geen rootaccess, dan was er wat betreft wachtwoorden geen al te serieus probleem geweest.

Again, iets meer moeite maar om 't noemenswaardig te noemen gaat me te ver. Zeker als je jezelf wat kunt helpen met een known plaintext (zodat je het bruteforcen van hegt wachtwoord zelf over kunt slaan.)

[Mentalist]

CyBeR schreef op vrijdag 16 september 2011 @ 02:17:
Again, iets meer moeite maar om 't noemenswaardig te noemen gaat me te ver. Zeker als je jezelf wat kunt helpen met een known plaintext (zodat je het bruteforcen van hegt wachtwoord zelf over kunt slaan.)

Nu is mijn voorbeeldsysteemhash van 63 karakters natuurlijk nergens op gebaseerd. Ik weet niet hoe krachtig zo'n GPGPU systeem precies is, maar kan je daarmee werkelijk een string van 1024chars bruteforcen? Of anders 4096. Of.. hoeveel moet het zijn voor je het niet meer realistisch kan bruteforcen?

Als je 140chars kan bruteforcen kan je ieder bericht dat ooit op Twitter is gepost en in de toekomst zal worden gepost en iedere SMS die ooit is verzonden en ooit zal worden verzonden bruteforcen. Dat is.. wow.

[ Voor 14% gewijzigd door Mentalist op 16-09-2011 02:34 ]

[CyBeR]

Met dergelijke lengtes zit je weer tegen collisions aan te kijken. Zoals je snapt kun je met een hash van, zeg 128 bits (zoals md5) geen strings hashen van meer dan 128 bits zonder strings tegen te komen die dezelfde hash opleveren. Een md5 maakt het niet uit of je 'bla' invult of iets wat toevallig dezelfde hash oplevert.

Nogmaals: het is slechts obscurity. Het levert je wat extra tijd op maar vooral een groot ongemak.

[Mentalist]

CyBeR schreef op vrijdag 16 september 2011 @ 02:56:
Nogmaals: het is slechts obscurity. Het levert je wat extra tijd op maar vooral een groot ongemak.

Het ongemak hoeft niet zo groot te zijn (je kan de key in hetzelfde bestand als je SQL-password opslaan, dat staat ook buiten je webroot) en bij een kraak waarbij alle hashes+unieke salts op straat liggen kan het het verschil beteken tussen "langzaam maar zeker worden de meeste wachtwoorden gekraakt" en "laten we eens rustig nadenken hoe we een veiliger systeem op kunnen zetten".

Als de systeemsalt ook op straat ligt werkt het natuurlijk niet, maar dat hoeft niet te gebeuren. Mocht het wel gebeuren, dan is de situatie niet slechter dan wanneer je geen systeemsalt had gehad.

[ Voor 14% gewijzigd door Mentalist op 16-09-2011 03:15 ]

[CyBeR]

Ok. Dan doe jij 't zo.

Wij niet.

[stereohead]

Interesante discussie hoor, maar wel totaal offtopic (lees de TS anders nog eens).

Femme schreef op woensdag 14 september 2011 @ 15:08:
[...]

Het lijkt me zinvol om de eisen voor het wachtwoord aan te passen zodat lengte en gebruik van verschillende soorten tekens (cijfers, lowercase letters, uppercase letters en bijzondere tekens) tegen elkaar worden afgewogen.

Iets voor de volgende scrum iteratie?

[ACM]

stereohead schreef op vrijdag 16 september 2011 @ 12:54:
Iets voor de volgende scrum iteratie?

In ieder geval een volgende iteratie of het de volgende al komt is natuurlijk even afwachten

[ACM]

Ik heb op basis van dit NIST-verhaal een simpel javascriptje gebakken dat een "entropy" berekend en aan de hand daarvan je wachtwoord wel of niet accepteerd. Momenteel zit de arbitraire grens op 24 bits entropy en alsnog minimaal 8 tekens. 24 bits haal je o.a. door een wachtwoord van 8 karakters te typen volgens de oude eisen (dus met een hoofdletter en cijfer of speciaal teken), maar ook makkelijk door een passphrase toe te passen (bijv die uit het xkcd-voorbeeld).

Type een testwachtwoord.

Sluit dit beter aan bij jullie verwachtingen van eis voor een relatief sterk wachtwoord, maar met voldoende vrijheid om daar een eigen interpretatie aan te geven?

T.o.v. het NIST-verhaal heb ik het iets aangepast, omdat de password-crackers die ik gezien heb met verschillende character-classes werken.

[.oisyn]

Mijn vertrouwde wachtwoord zonder hoofdletter: 27 bits. Uitstekelbaars
.edit: wel apart dat hoofdletters meer entropie opleveren dan kleine letters.

[ Voor 35% gewijzigd door .oisyn op 16-09-2011 17:49 ]

[Verwijderd]

Ik vind het concept in principe goed.

Maar:

Mijn wachtwoord voor Tweakers levert 28bits, met 10 tekens. Klinkt goed. Niettemin kreeg ik met dat wachtwoord wel zo'n gele balk te zien dat mijn password niet sterk genoeg was... Vermoedelijk omdat een deel van mijn wachtwoord in zo'n dictionary stond? Dus dan is deze methode misschien toch niet zo heel goed. (maar wel beter dan wat we hadden.)

[.oisyn]

Maar dat wordt nu ook niet afgeschermd. "Buschauffeur1" voldoet ook aan de huidige eisen, maar zou waarschijnlijk ook gekraakt zijn. Daar doe je gewoon niets aan.

[Gomez12]

Enige manier om dezelfde check als de gele balk te krijgen is door per wachtwoordwijziging een half uur per gebruiker te gaan cracks, daar zit ook niemand op te wachten...

[ACM]

Gomez12 schreef op vrijdag 16 september 2011 @ 18:12:
Enige manier om dezelfde check als de gele balk te krijgen is door per wachtwoordwijziging een half uur per gebruiker te gaan cracks, daar zit ook niemand op te wachten...

Nouja, je kan de hash-stap natuurlijk overslaan, dus wellicht dat het "maar" 5-10 minuten is dan

[stereohead]

ACM schreef op vrijdag 16 september 2011 @ 17:12:
...
Sluit dit beter aan bij jullie verwachtingen van eis voor een relatief sterk wachtwoord, maar met voldoende vrijheid om daar een eigen interpretatie aan te geven?
...

Met die check is een random wachtwoord met kleine-letters en cijfers nog steeds niet veilig genoeg. Bijvoorbeeld 'ab1c7d5ef', zo'n wachtwoord lijkt mij wel veilig genoeg. Tevens is mijn 'favoriete' wachtwoord een random reeks van kleine-letters en cijfers.

Ik pleit voor geen enkele restrictie op het wachtwoord, het is IMO de verantwoordelijkheid van de gebruiker om een veilig wachtwoord te gebruiken.

[ Voor 12% gewijzigd door stereohead op 17-09-2011 18:49 ]

[crisp]

stereohead schreef op zaterdag 17 september 2011 @ 18:48:
[...]


Met die check is een random wachtwoord met kleine-letters en cijfers nog steeds niet veilig genoeg. Bijvoorbeeld 'ab1c7d5ef', zo'n wachtwoord lijkt mij wel veilig genoeg. Tevens is mijn 'favoriete' wachtwoord een random reeks van kleine-letters en cijfers.

Met 1 teken erbij is het wel genoeg

Randgevallen zal je altijd houden waarbij de gebruiker het 'wel voldoende' vindt, maar ons algoritme het daar niet mee eens is...

Ik pleit voor geen enkele restrictie op het wachtwoord, het is IMO de verantwoordelijkheid van de gebruiker om een veilig wachtwoord te gebruiken.

Daar ben ik het niet geheel mee eens. Het is gebleken dat je de gemiddelde gebruiker op het gebied van wachtwoorden best als 'dom' kan beschouwen, dus er mag best wat opvoedkundige waarde uitgaan van een wachtwoordpolicy, vermits die policy ook redelijk is en de gebruiker weer niet te veel belemmerd in het kiezen van een goed wachtwoord.

Redelijkheid is in het geding als de policy bepaalde eisen stelt die niet noodzakelijk bijdragen aan extra veiligheid bij een bepaald gekozen wachtwoord, dus moeten die eisen worden bijgesteld zodat het een betere indicatie geeft van de veiligheid van een bepaald wachtwoord. De entropy-berekening van ACM is een methode daartoe, maar we doen eigenlijk al langer een soort entropybereking van het wachtwoord in de vorm van de wachtwoordsterktemeter - alles wat minder dan 'vrij sterk' is zouden we eigenlijk kunnen afwijzen.

Je kan pleiten voor 'geen restricties', maar wij als Tweakers.net hebben ook een bepaalde zorgplicht naar onze gebruikers, waaronder de zorg om persoonsgegevens veilig te bewaren. Dat betekent dus automatisch dat wij verplicht zijn om een bepaalde mate van beveiliging op te dringen aan onze gebruikers waar het om hun account gaat.

[stereohead]

crisp schreef op zondag 18 september 2011 @ 01:39:
[...]

Met 1 teken erbij is het wel genoeg

Randgevallen zal je altijd houden waarbij de gebruiker het 'wel voldoende' vindt, maar ons algoritme het daar niet mee eens is...

[...]

Maargoed mijn favoriete wachtwoord bestaat dus uit random 6 kleine letters + 2 cijfers. Deze is toch veilig tegen dictionary en bruteforce attacks. Om maar even een voorbeeld te nemen, google geeft aan dat mijn wachtwoord 'sterk' is.

Ik denk dus het algoritme te streng is.

Daar ben ik het niet geheel mee eens.
[...]

Had al wel verwacht dat niet iedereen mijn mening zou delen . Ik ga hier dan ook verder niet op in. Niet om de discussie uit de weg te gaan, maar om het een beetje ontopic te houden.

[ Voor 44% gewijzigd door stereohead op 18-09-2011 10:23 ]

[Mentalist]

stereohead schreef op zondag 18 september 2011 @ 10:20:
[...]

Maargoed mijn favoriete wachtwoord bestaat dus uit random 6 kleine letters + 2 cijfers. Deze is toch veilig tegen dictionary en bruteforce attacks. Om maar even een voorbeeld te nemen, google geeft aan dat mijn wachtwoord 'sterk' is.

Niet meer dus, want ik heb begrepen dat dit met GPGPU in een kwestie van uren te bruteforcen is.

[.oisyn]

Met MD5 ja, een hash algoritme dat t.net nu niet meer gebruikt.

[Mentalist]

.oisyn schreef op zondag 18 september 2011 @ 17:00:
Met MD5 ja, een hash algoritme dat t.net nu niet meer gebruikt.

Ik ga er voor het gemak vanuit dat het huidige algoritme ook wel weer eens gekraakt zal worden.

En het aantal mogelijkheden met 8 karakters is blijkbaar gewoon snel genoeg te doorlopen.

[Rukapul]

stereohead schreef op zondag 18 september 2011 @ 10:20:
[...]


Maargoed mijn favoriete wachtwoord bestaat dus uit random 6 kleine letters + 2 cijfers. Deze is toch veilig tegen dictionary en bruteforce attacks. Om maar even een voorbeeld te nemen, google geeft aan dat mijn wachtwoord 'sterk' is.

Je wachtwoord is binnen een paar minuten gekraakt bij gebruik van MD5:
http://golubev.com/gpuest.htm

Met 10 miljard pogingen per seconde op een nieuwe GPU gaat het hard Een wachtwoord bestaande uit alleen kleine letters plus cijfers met lengte 8 heeft slechts 36^8 = 2821109907456 (ca 2821 miljard) oplossingen.

Gemiddeld genomen zal het wachtwoord dan dus gevonden worden na 2821 / 10 / 2 = 141 seconden oftewel 2 minuten en 21 seconden

Ter vergelijk PKBDF2 oplossingen zoals nu door tweakers toegepast zijn te vergelijken met de methoden voor MS Office 2007, WinZip/AES en WPA (iteraties verschillen, hash algo's evt ook) die slechts 50 duizend tot 1 miljoen passwords per seconde kunnen testen (zie gelinkte tabel).

Concreet: je wachtwoord kun je echt beter wat langer/complexer maken en een update zoals nu door t.net snijdt hout

[ Voor 10% gewijzigd door Rukapul op 18-09-2011 17:49 ]

[.oisyn]

W3ird_N3rd schreef op zondag 18 september 2011 @ 17:03:
[...]

Ik ga er voor het gemak vanuit dat het huidige algoritme ook wel weer eens gekraakt zal worden.

MD5 is niet gekraakt (niet in de context van het omkeren van een hash althans - hij is hoogstens niet meer collision-resistant, wat voor de toepassing van het opslaan van wachtwoorden weinig uitmaakt). Het doel van MD5 is een snel message digest algoritme met een goede distributie van de hash space. Juist die eigenschap "snel" maakt het eigenlijk ongeschikt voor het gebruik van het hashen van wachtwoorden - dat is het feitelijk altijd al geweest.

Daarnet zei ik dat t.net geen MD5 meer gebruikt - dat is niet per se waar. Wat ik eigenlijk bedoelde te zeggen was dat ze geen md5($password) meer deden. PBKBF is een key derivation function dat gebruik maakt van key stretching en een bestaand hasing algoritme om de tijd van een enkele hash zo lang mogelijk te maken. Het is prima mogelijk om MD5 te gebruiken als hashing algoritme voor PBKBF, en feitelijk staat nergens dat t.net dat niet doet.

[ Voor 43% gewijzigd door .oisyn op 18-09-2011 18:55 ]

[Mentalist]

.oisyn schreef op zondag 18 september 2011 @ 18:34:
MD5 is niet gekraakt (niet in de context van het omkeren van een hash althans - hij is hoogstens niet meer collision-resistant, wat voor de toepassing van het opslaan van wachtwoorden weinig uitmaakt). Het doel van MD5 is een snel message digest algoritme met een goede distributie van de hash space. Juist die eigenschap "snel" maakt het eigenlijk ongeschikt voor het gebruik van het hashen van wachtwoorden - dat is het feitelijk altijd al geweest.

Klopt, ik bedoelde het meer in de zin van "er komt mogelijk weer betere hardware of een slim algoritme om de huidige methode net zo snel te hashen als md5 nu".

[.oisyn]

En daarom lijkt het me ook meer van belang dat t.net up to date blijft, ipv exorbitante eisen te stellen aan wachtwoorden die nu wellicht wel veilig zijn maar over X jaar niet meer.

[stereohead]

Rukapul schreef op zondag 18 september 2011 @ 17:48:
[...]

Concreet: je wachtwoord kun je echt beter wat langer/complexer maken en een update zoals nu door t.net snijdt hout

Ik moet zeggen dat jouw post ook wel hout snijdt .

Maar alsnog, waarom een T.net password 'veiliger' maken dan b.v. een gmail password. Ik neem aan dat google ook wel serieus nadenkt over dit soort kwesties.

Ik vind het positief dat T.net haar users op de hoogte brengt van de veiligheid van hun wachtwoorden. Maar vind nog steeds dat het de verantwoordelijkheid van de gebruiker is om een veilig wachtwoord te kiezen.

Je mag als T.net dan wel een zorgplicht hebben, maar 'zorgen' betekend niet dat je je users met een stok moet gaan slaan tot ie z'n bord leeg vreet.

Sorry dat ik zo eigenwijs ben, maar ik wil graag m'n huidige, slechte wachtwoord vervangen door mn favoriete, betere wachtwoord.

[.oisyn]

Overigens aan de devvers / db admins, ik hoop dat de MD5 database inmiddels fysiek is verwijderd? En dus ook niet ergens nog in een archief of database backup staat oid.

[ Voor 26% gewijzigd door .oisyn op 18-09-2011 23:01 ]

[Kees]

.oisyn schreef op zondag 18 september 2011 @ 22:59:
Overigens aan de devvers / db admins, ik hoop dat de MD5 database inmiddels fysiek is verwijderd? En dus ook niet ergens nog in een archief of database backup staat oid.

Ik heb inderdaad al onze backups 'gesloopt' door die tables eruit te halen, onsite en offsite. Als het goed is bestaat er nergens meer een kopie van die table.

[.oisyn]

Nice

[Rekcor]

Misschien is dit al eerder gemeld hierboven (in dat geval kun je dit bericht als niet-gepost beschouwen)

Ik voer een nieuw wachtwoord in: volgens het algoritme is dit 'Sterk'. Als ik hem op wil slaan, krijg ik echter te horen dat 'ie niet goed is, omdat er geen hoofdletter in zat.

Ik zou verwachten dat ik dan niet eerder te horen krijg dat mijn wachtwoord 'Sterk' is.

[crisp]

Rekcor schreef op maandag 19 september 2011 @ 13:25:
Misschien is dit al eerder gemeld hierboven (in dat geval kun je dit bericht als niet-gepost beschouwen)

Ik voer een nieuw wachtwoord in: volgens het algoritme is dit 'Sterk'. Als ik hem op wil slaan, krijg ik echter te horen dat 'ie niet goed is, omdat er geen hoofdletter in zat.

Ik zou verwachten dat ik dan niet eerder te horen krijg dat mijn wachtwoord 'Sterk' is.

Dat is ook wat er in dit topic wordt voorgesteld en we uiteindelijk ook wel willen gaan implementeren: op het moment dat uit een entropy-check blijkt dat een wachtwoord voldoet aan een bepaalde minimum-sterkte dan worden er verder geen inhoudelijke restricties meer opgelegd

[Mentalist]

Beetje offtopic maar ook geen nieuw topic waard: ik ben wel nieuwsgierig hoeveel crewleden er precies zijn en hoeveel daarvan een notificatie hebben gekregen. Om dus te zien of mensen met een "waardevol" account ook echt een beter wachtwoord kiezen, of dat dit niet uitmaakt.

[CyBeR]

ACM schreef op vrijdag 16 september 2011 @ 17:12:
Ik heb op basis van dit NIST-verhaal een simpel javascriptje gebakken dat een "entropy" berekend en aan de hand daarvan je wachtwoord wel of niet accepteerd. Momenteel zit de arbitraire grens op 24 bits entropy en alsnog minimaal 8 tekens. 24 bits haal je o.a. door een wachtwoord van 8 karakters te typen volgens de oude eisen (dus met een hoofdletter en cijfer of speciaal teken), maar ook makkelijk door een passphrase toe te passen (bijv die uit het xkcd-voorbeeld).
[..]

Sluit dit beter aan bij jullie verwachtingen van eis voor een relatief sterk wachtwoord, maar met voldoende vrijheid om daar een eigen interpretatie aan te geven?

T.o.v. het NIST-verhaal heb ik het iets aangepast, omdat de password-crackers die ik gezien heb met verschillende character-classes werken.

Hoeveel problemen zou jij ermee hebben als ik jouw javascriptje zou rippen en toepassen in m'n eigen password-change-appje?

[ACM]

CyBeR schreef op maandag 19 september 2011 @ 17:17:
Hoeveel problemen zou jij ermee hebben als ik jouw javascriptje zou rippen en toepassen in m'n eigen password-change-appje?

Niet zoveel. Zo spannende code is het niet en het is een vrij straight-forward vertaling van die NIST-informatie.

[crisp]

En fixed: plan: Development-round-up - iteratie #7