Security (b)log: passwords

woensdag 18 februari 2026

Lengte loont

Klik op de afbeelding voor een grote versie

Deze week is de Security (b)log er iets eerder vanwege een paar vrije dagen

Precies een jaar geleden stelde collega Alexander een vraag. Sommige onderwerpen liggen wat langer te rijpen. De vraag gaat over wachtwoorden en de wenselijkheid om die lekker ingewikkeld te maken. Hij stuurde een bekend schema mee dat bedoeld is om inzichtelijk te maken hoe snel wachtwoorden kunnen worden gekraakt. Ik zal het schema voor je ontleden, want het bevat veel interessante informatie.

Ik begin met de kop. Daarin is de term ‘brute force aanval’ van belang: letterlijk een aanval met brute kracht. Maar waarop dan? Kijk, een systeem waarop jij wilt inloggen, heeft een bestand waarin alle accounts staan. Het systeem moet immers kunnen controleren of je erin mag. Tenzij de ontwerper van zo’n systeem onder een steen heeft gelegen, staat het wachtwoord daar niet leesbaar in. Want dan zou iemand, die het bestand met accounts weet te bemachtigen, vrij spel hebben. Nee, de wachtwoorden zijn versleuteld opgeslagen. Als jij inlogt, dan wordt het wachtwoord, dat jij invult, eveneens versleuteld. Zo kan het toch vergeleken worden met het opgeslagen wachtwoord.

Een aanvaller heeft veel pogingen nodig om je wachtwoord te kraken. Als hij gewoon maar begint om op een website met jouw account in te loggen, wordt je account bij de meeste systemen na een aantal foute pogingen vergrendeld (‘gelockt’). Dat is dus een beveiligingsmaatregel tegen brute forcing. Dat schiet niet op voor die aanvaller. Hij wil dan ook liefst het complete wachtwoordbestand in handen krijgen, zodat hij er offline rustig op los kan proberen zonder telkens gelockt te worden. Daarvoor moet hij natuurlijk wel eerst even inbreken op zijn doelwit.

Laten we ervan uitgaan dat hij het bestand heeft weten te bemachtigen. Hij gebruikt vervolgens een krachtige computer om de accounts in dat bestand aan te vallen. Het schema geeft aan hoeveel tijd daarvoor nodig is. Verticaal loopt de lengte van de wachtwoorden op van vier naar achttien. Horizontaal loopt het aantal verschillende tekens, waaruit het wachtwoord kan bestaan, steeds verder op. In de eerste kleurrijke kolom zijn er slechts tien verschillende tekens: de cijfers nul tot en met negen. In de volgende kolom zijn het er al 26, vervolgens 52 en dan 62. In de laatste kolom, die staat voor alle mogelijk tekens – cijfers, hoofd- en kleine letters, symbolen (! @ # $ % ^ & * ( ) - _ = + enz.) – hebben we het meestal over 94 tekens (‘printable ASCII’).

Linksboven zie je dat een wachtwoord dat uit vier cijfers bestaat geen weerstand biedt. Er zijn slechts tienduizend verschillende wachtwoorden mogelijk, wat betekent dat de aanvaller gemiddeld vijfduizend pogingen moet doen. Een fluitje van een cent. Rechtsonder vind je het andere uiterste: achttien tekens lang, gekozen uit 94 tekens. Daarmee kun je 3,28 x 10³⁵ verschillende wachtwoorden maken – dat is grofweg een drie met 35 nullen. Die krachtige hackcomputer doet er volgens de tabel 463 triljoen jaar over om het te kraken. Een triljoen is duizend miljard; het universum is slechts 13,8 miljard jaar oud.

Wat ik veel interessanter vind, is dat er in de tabel verticaal meer gebeurt dan horizontaal. Met andere woorden: lengte is veel belangrijker dan het aantal mogelijke tekens. Als je een wachtwoord van alleen cijfers vier keer zo lang maakt, dan heeft de boef al tweeduizend jaar nodig. Daarentegen heeft uitbreiding van het aantal mogelijke tekens (bij gelijke lengte) geen noemenswaardig op de kraaksnelheid. En als je kijkt naar de regel van vijftien karakters, dan zie je dat het kraken van een wachtwoord, dat alleen uit kleine letters bestaat, al bijna een half miljard jaar duurt (en wat mij betreft had dat vakje gerust groen mogen zijn).

Conclusie: als een wachtwoord lekker lang is, dan hoef je je niet druk te maken over de complexiteit ervan. Met andere woorden: veel systemen eisen dat je minimaal 1 cijfer, 1 kleine letter, 1 hoofdletter en 1 symbool gebruikt, maar dat is niet nodig, mits je wachtwoord lang genoeg is. Die lange wachtwoorden laat je comfortabel genereren en beheren door je password manager. Wachtwoorden, die je daar niet in kwijt kunt – bijvoorbeeld het hoofdwachtwoord van je password manager – kies je zo, dat jij ze wel kunt onthouden, maar iemand anders ze niet gemakkelijk kan raden. Bijvoorbeeld ‘Mijn wachtwoord hack je niet’ of ‘iz2bbsodw1wtewbw’ (ik zag 2 beren broodjes smeren…).

En in de grote boze buitenwereld …

vrijdag 16 januari 2026

Zucht

Afbeelding via Unsplash

Pssst… Kun je een geheimpje bewaren? Ik geef je een verzegelde envelop waar een naam op staat. Het geheim zit daarin. Je mag zelf niet in de envelop kijken. Als degene, wiens naam erop staat, langskomt, geef je hem de envelop. Hij kijkt erin, verzegelt de envelop weer en geeft hem terug. Je bewaart hem tot de volgende keer. En verder doe je er helemaal niks mee.

Dit is ongeveer hoe het in veel gevallen werkt als twee computersystemen met elkaar communiceren*. Bijvoorbeeld omdat op het ene systeem een programma draait dat gegevens nodig heeft die op het andere systeem staan. Systeem A moet dan inloggen bij systeem B, want natuurlijk mag niet iedereen zomaar die gegevens ophalen – ook een ander computersysteem niet. In de eerste alinea bewaarde jij een envelop; systeem A heeft daar een digitale variant van: een digitale kluis, of vault in het Engels. Daar staat het wachtwoord versleuteld in. Als A gegevens moet ophalen bij B, dan haalt hij het wachtwoord uit de kluis, ontsleutelt het logt ermee in bij B.

De crux hierbij is dat er geen mens aan te pas komt. En dat geen mens het wachtwoord ooit ziet. En dat er dus niemand misbruik kan maken van het account van A. Net zoals jij niet in die envelop keek, zo ziet nooit iemand het ontsleutelde wachtwoord. Althans, zo is het bedacht. Een poosje geleden stuurde een collega mij een mailtje met als onderwerp: ZUCHT… Hij had geconstateerd dat iemand stiekem in de envelop had gekeken, of in de digitale variant: het wachtwoord handmatig had ontsleuteld. Om vervolgens te proberen handmatig met dat account in te loggen, “om ff te proberen of het werkt”. Terwijl zo’n account toch echt een machine-machine-account is, met andere woorden: het is bedoeld om de ene machine (A) bij de andere (B) te laten inloggen.

De zucht op de onderwerpregel betekende zoveel als: snappen ze het nu nóg niet? Let wel, we hebben het hier over beheerders en ontwikkelaars die deze fratsen uithalen. Van hen zou je mogen verwachten dat ze snappen hoe het werkt. Dat het openen van een envelop waar je naam niet op staat simpelweg niet mag. En dat het handmatig aanloggen met een machine-account óók niet mag. De zucht was er ook omdat dit bepaald geen eenmalige constatering was. Het gebeurt veel te vaak. Daarmee ondergraaf je onze beveiliging. Misschien vraag je je af waarom dit überhaupt mogelijk is. Maar dat is hier nu niet de kwestie. Natuurlijk zou het niet moeten kunnen, maar op dit moment is het nu eenmaal zo; zie ook de voetnoot.

Als aan een bankje in het park een bordje “NAT” hangt, ga je dan voelen of de verf echt nog nat is? Waarom zou je? Je loopt kans op verf aan je vingers en het bankje wordt er niet mooier van. De meeste mensen snappen dat het niet hoort en houden hun handen netjes thuis. Zo werkt het ook met die versleutelde wachtwoorden. Dat iets kan, betekent nog niet dat het ook mag, of dat het verstandig is om te het te doen.

Diep van binnen weet je dat. Maar voor de zekerheid toch maar nog even een oproep aan iedereen die wel eens wat gemakkelijk met dergelijke zaken omspringt: doe het niet. Al was het alleen al omdat die zuchtende collega er grijze haren van krijgt, en ik vol verbazing over iets moet schrijven waarvan ik dacht dat jullie het onderhand wel zouden begrijpen. En natuurlijk ben ik blij met die vele collega’s die het gewoon goed doen <3

*: Er zijn alternatieven, maar die laat ik hier even buiten beschouwing.