Het is tijd de bezem door ons wachtwoordbeleid te halen

Ik heb al vaker geschreven dat wachtwoordcomplexiteitsregels de veiligheid van het wachtwoord niet verhoogt. Aanvankelijk was ik de roepende in de woestijn. Toch vond ik ook medestanders. De eerste medestander was Hacker Highschool, een project van ISECOM in Les 11 - Hacking passwords, die mijn mening overnam. Sindsdien heb ik ook artikelen gelezen van anderen die wachtwoordcomplexiteitsregels verwierpen en erop wezen dat vooral de lengte van het wachtwoord ertoe doet. Maar nu NIST dit ook vindt, kunnen we er echt niet meer omheen. De bezem moet door ons wachtwoordbeleid.

NIST heeft vorig jaar nieuwe eisen voor veilige wachtwoorden beschreven in SP 800-63. NIST vindt de nieuwe richtlijn nodig, omdat wachtwoorden nog steeds veel gebruikt worden en de bestaande gebruiken voor "veilige wachtwoorden" tekort schieten. Voor velen zullen de nieuwe richtlijnen verrassend zijn.

Een ideaal wachtwoord is voldoende complex en willekeurig. Helaas zijn de meeste mensen niet in staat om zulke wachtwoorden te onthouden en kiezen wachtwoorden die eenvoudig te raden zijn. Daarom zijn er regels bedacht voor wachtwoordcomplexiteit. Het wachtwoord moet dan bestaan uit verschillende soorten tekens (hoofdletters, kleine letters, cijfers, overige tekens). Enfin, je kent zulke eisen wel. Bij analyse van gecompromitteerde wachtwoord databases is gebleken dat de complexiteit hierdoor nauwelijks toeneemt.

Uit onderzoek van die gecompromitteerde wachtwoord blijkt, dat regels voor wachtwoordcomplexiteit heel voorspelbaar worden uitgevoerd. Het wachtwoord begint meestal als een woord in kleine letters. Als een hoofdletter vereist is, dan kiezen we daar de eerste letter voor. Als cijfers vereist zijn wordt een volgnummer toegevoegd en aan het eind staat eventueel een bijzonder teken. Als een bijzonder teken wordt gebruikt, is dat meestal het uitroepteken. Bedenkt u zelf maar of u Welkom1! een sterk wachtwoord vindt. Een ander probleem met deze methode is, dat er meestal maar 26 tekens worden geaccepteerd als hoofdletter en 26 als kleine letter. Diacritische tekens (é, ü, ç) of tekens uit het Griekse (?, ?, ?) of Cyrillische alfabet (?, ?, ?) worden zelden toegestaan. Een andere frustratie is dat veel services wachtwoorden met spaties weigeren of bepaalde speciale tekens. Daar is geen steekhoudend argument voor te bedenken, want de speciale tekens zelf worden toch niet in een database opgeslagen. Het wachtwoord wordt immers opgeslagen als een hash. Oftewel, als een heel erg groot getal.

Gebruikers blijken voorkeur te hebben voor bepaalde wachtwoorden. Aanvallers proberen daarom vaak eerst de wachtwoorden die vaak zijn waargenomen bij gekraakte wachtwoorden. Daarom wordt aanbevolen om gebruik te maken van een blacklist met onaanvaardbare wachtwoorden.

Voorbeelden van verboden wachtwoorden kunnen zijn:

wachtwoorden die bij eerdere password breaches bekend zijn geworden

woorden uit het woordenboek

herhalende of opeenvolgende tekens (bv. 'aaaaaa' of '1234abcd')

specifieke woorden, zoals de naam van de dienst of website, de username en afgeleiden daarvan etc.

Fustratie

De tekortkomingen van wachtwoordcomplexiteitsregels leiden niet alleen tot frustratie, maar ook tot schijnveiligheid. NIST wil naar veiliger wachtwoorden of zoals ze het zelf noemen: Memorized Secrets.

NIST wil dat een wachtwoord zo gekozen wordt, dat het wel makkelijk te onthouden is, maar niet dat het eenvoudig te raden is. Het belangrijk dat ze geheim gehouden worden, om te voorkomen dat anderen ze kunnen misbruiken. Daarom heeft NIST tot de volgende regels opgesteld:

Wachtwoorden die gekozen worden door de gebruiker, moeten minimaal acht tekens lang zijn. De verifier mag wachtwoorden weigeren die op een blacklist staan. Hierover later meer. Wordt het wachtwoord willekeurig samengesteld door de verifier (het mechanisme dat controleert of het juiste wachtwoord is ingevoerd), dan moet het minimaal zes tekens lang zijn.

De verifier controleert of het wachtwoord minimaal 8 tekens lang is. Wachtwoorden van 64 tekens of meer, zouden toegestaan moeten worden. Dat betekent niet alleen dat alle printbare ASCII tekens zouden toegestaan moeten worden, maar ook de spatie en alle (!!!) Unicode karakters. De verifier mag meerdere aaneengesloten spaties reduceren tot één spatie of zelfs helemaal negeren. Het moet wel mogelijk zijn dat een gebruiker spaties kan invoeren. De verifier moet het hele wachtwoord controleren en mag dit niet afbreken bij een arbitraire lengte.

Unicode tekens horen genormaliseerd te worden. De gebruiker moet er rekening mee houden dat sommige tekens in Unicode op verschillende manieren kunnen worden geschreven. Dit kan er soms toe leiden dat het authentiseren lastig is. Bijvoorbeeld het woord világ (Hongaars voor wereld), kun je schrijven als világ of als világ. Hoewel het verschil niet visueel zichtbaar is, is de eerste á het extended ASCII teken \u00e1 en de tweede is \u0061\u0301, een kleine letter a met een accent toegevoegd.

De verifier moet eerst de spaties reduceren en normalisatie toepassen voor het wachtwoord wordt gehasht.

Als een gebruiker een nieuw wachtwoord opgeeft, mag de verifier dat toetsen aan een blacklist. Als de verifier een wachtwoord weigert, dan geeft het aan waarom het geweigerd is. De verifier eist dan dat de gebruiker een ander wachtwoord kiest.

De verifier staat een beperkt aantal foutieve inlogpogingen toe.

De verifier zou geen andere complexiteitregels, zoals verschillende typen van tekens, moeten verlangen. Ook zou de verifier niet moeten verlangen dat de gebruiker zijn wachtwoord periodiek wijzigt. De enige reden om een ander wachtwoord te verlangen, is wanneer er bewijs is dat het het wachtwoord of het authenticatiemechanisme gecompromiteerd is.

Password hints of geheime vragen zijn niet toegestaan in het kader van password recovery.

De verifier moet tijdens de authenticatie gebruik maken van degelijke encryptie van het communicatiekanaal, zodat de wachtwoorden afdoende zijn beschermd tegen afluisteren.

De verifier slaat de wachtwoorden zodanig op, dat zij weerstand bieden tegen offline attacks. Het wachtwoord wordt daarom niet zelf opgeslagen, maar wordt gehasht met een salt, waarbij gebruik gemaakt wordt van een voor dit doel goedgekeurde hash-functie. Het salt moet minimaal 32 bits lang zijn en de hash-functie moet minimaal 10.000 iteraties uitvoeren (dat is snel genoeg voor het verifieren van een enkel wachtwoord, maar duurt eindeloos lang als je een password wil brute forcen of rainbow tables wil maken).

Het zijn heel andere eisen dan waar wij tegenwoordig aan gewend zijn en die algemeen als veilige wachtwoorden worden beschouwd. Ik ondersteun deze norm van NIST van harte. Zodra de richtlijn is vastgesteld, is het de bedoeling dat het wachtwoordbeleid bij alle Amerikaanse overheden conform de richtlijn wordt aangepast.

Door: Cor Rosielle, professioneel pentester in samenwerking met cqure.nl kennisplatform.

Over Cor Rosielle

Ik ben Cor Rosielle. In 1978 ben ik afgestudeerd aan de HTS Bouwkunde en in 1979 aan de HTS Weg- en Waterbouwkunde, beide in Amsterdam. Ik ben direct na mijn afstuderen aan het werk gegaan als betonconstructeur. In 1983 heb ik de overstap gemaakt naar ICT. Dat heette toen nog: automatisering. Sindsdien heb ik veel verschillende functies bekleed, zoals: operator, programmeur, systeembeheer, netwerkbeheer, afdelingsmanager, informatiebeveiliger en penetratietester. Ik heb inmiddels ruim 30 jaar ervaring in ICT.