Laten we bij het eind beginnen, want het antwoord is kort en bijna niemand geeft het volledig: als er een reden is. Niet elke negentig dagen.
De gewoonte om wachtwoorden op de kalender te wisselen zit er zo diep in dat het op hygiëne lijkt, zoals tandenpoetsen. Maar het was een aanbeveling met een houdbaarheidsdatum, en die is verstreken: het Amerikaanse NIST schreef hem in 2003, trok hem in 2017 in, en de auteur van dat document bood datzelfde jaar in het openbaar zijn excuses aan. Dat verhaal vertellen we volledig in wat een wachtwoord is; hier gaat het om het andere, dat bijna nooit wordt uitgelegd: wat jij vandaag met je wachtwoorden doet.
Een kalender weet niet of er iets van je gestolen is
Het probleem met wisselen op datum is dat de datum geen enkele informatie bevat.
Als iemand op een dinsdag in februari je wachtwoord te pakken kreeg, geef je hem door het op 1 april te wijzigen omdat het toevallig zo uitkomt zes weken gratis toegang cadeau. En als niemand eraan gezeten heeft, heeft het wijzigen je nergens tegen beschermd: je hebt een goed wachtwoord vervangen door een dat waarschijnlijk slechter is, want wachtwoorden die uit plicht worden bedacht, worden lusteloos bedacht.
Daar zit het hele mechanisme van de mislukking. Gedwongen rotatie levert geen
nieuwe wachtwoorden op, maar varianten. Zomer2026! wordt Herfst2026! en
daarna Winter2026!, en wie jou aanvalt weet dat, want die reeks is net zo
voorspelbaar als de kalender waar hij uit komt. Het systeem is tevreden — het
wachtwoord «is gewijzigd» — en de werkelijke veiligheid is gedaald, niet
gestegen.
Daarom zegt het NIST in SP 800-63B de twee dingen in één adem: geen willekeurige wijzigingen op de klok, en een wijziging afdwingen zodra er een aanwijzing van compromittering is. Het is niet zo dat wijzigen er niet toe doet. De trigger moet een feit zijn, geen datum.
De redenen die wél tellen
Dit is de lijst. Als een van deze dingen je overkomt, wordt het wachtwoord vandaag gewijzigd, niet volgende maand:
- Het is in een datalek opgedoken. Van die dienst, of van een andere waar je hetzelfde gebruikte.
- Je hebt het hergebruikt. Als
Xis uitgelekt en het staat ook op vier andere sites, zijn er vijf wachtwoorden te wijzigen, niet één. - Je hebt het ingetypt op een site die de site niet bleek te zijn. Een haastige mail, een link, een formulier dat erop leek. Het maakt niet uit dat je het twee seconden later doorhad: je had het al verstuurd.
- Je hebt het gedeeld. Met je partner, met een collega, in een werkchat, op een briefje. Een wachtwoord dat door een kanaal is gegaan waar je niet bepaalt wie meeleest, is niet meer van jou.
- Je ziet rare activiteit. Een aanmelding vanaf een plek waar je nooit bent geweest, herstelmails die je niet hebt aangevraagd, een verzonden bericht dat je niet hebt geschreven.
- Het apparaat was gecompromitteerd. Een computer met malware, een verloren telefoon, een laptop die langs een onbekende reparateur is geweest.
- De dienst waarschuwt je. Als een bedrijf die mail stuurt, doe er dezelfde dag iets mee. Het is letterlijk het geval dat SP 800-63B voor ogen heeft.
- Een samenleving is geëindigd. Een ex, een gedeeld huis, een compagnon. Accounts die van twee mensen waren en nu van één zijn.
Let op wat ze gemeen hebben: het zijn allemaal gebeurtenissen. Geen ervan is «er zijn negentig dagen verstreken».
Voor de eerste is er gereedschap. Wil je weten of een bepaald wachtwoord op de lijsten staat die al rondgaan, en meteen ook hoe lang het standhoudt, haal het dan door de wachtwoord-checker: hij analyseert het in je browser en daar blijft het.
Als er een reden is, telt de volgorde
Het wachtwoord wijzigen is de voor de hand liggende stap, en vaak niet de eerste. Dit is de volgorde die je het werk niet twee keer laat doen:
Eerst het apparaat. Als je vermoedt dat er iets geïnstalleerd staat dat meeleest wat je typt, komt het wijzigen van je wachtwoord op datzelfde apparaat neer op het overhandigen van het nieuwe. Maak het schoon, of gebruik eerst een ander apparaat.
Daarna de e-mail. Je e-mailaccount is niet zomaar een account: het is het account dat de «wachtwoord vergeten»-links van alle andere ontvangt. Wie de mail beheert, beheert de rest via de voordeur. Als er één wachtwoord is om mee te beginnen, is het dat.
Vervolgens: sluit de open sessies. Een wachtwoordwijziging zet niet altijd degene die al binnen is buiten de deur. Zoek in de accountinstellingen de optie om op alle apparaten af te melden en gebruik hem — anders blijft de indringer verbonden in een sessie die je wachtwoord helemaal niet meer nodig heeft.
En tot slot: kijk wat hij heeft achtergelaten. Dit is de stap die de meeste mensen overslaan. Wie een account binnenkomt, kijkt niet alleen: hij wijzigt het herstel-e-mailadres, voegt een telefoonnummer toe, zet een eigen tweede factor aan, koppelt een app, zet een doorstuurregel in de mailbox. Als je het wachtwoord wijzigt en dat niet controleert, loopt hij morgen weer naar binnen door een deur die openstaat. Loop herstelmethoden, geautoriseerde apparaten, gekoppelde apps en doorstuurregels na.
Nog iets, voor de hand liggend en juist daarom het vaakst genegeerd: als je wijzigt, moet het nieuwe nieuw zijn. Niet het gebruikelijke met een ander cijfer. Genereer het in de generator en bewaar het ergens waar het niet van je geheugen afhangt.
Wat je de andere driehonderdzestig dagen doet
Als de trigger een feit is en feiten zeldzaam zijn, wordt de vraag een andere: dan valt er dus niets te doen? Integendeel. Wat rotatie slecht probeerde op te lossen, wordt goed opgelost door vier dingen, en die zijn allemaal eenmalig.
Maak ze lang. SP 800-63B zet lengte boven gewrongenheid: een lang wachtwoord is meer waard dan een kort vol symbolen. Daar zit het meeste werk.
Maak ze op elke site anders. Dit is wat het datalek van een ander tot een klein incident maakt in plaats van tot een brand. Heeft elk account het zijne, dan raakt één lek de rest niet; deel je een wachtwoord, dan bepaalt een dienst die je je nauwelijks herinnert hoe veilig je bank is.
Laat ze toetsen aan lekkenlijsten. Dat is precies de ruil die het NIST maakte: in plaats van een symbool te eisen, controleren of je wachtwoord niet al in omloop is. Die controle verloopt wél — een wachtwoord dat er vandaag niet op staat, kan er volgend jaar op staan — en daarom herhalen goede managers hem uit zichzelf en laten ze het je weten.
Zet een tweede factor aan waar het kan. Met een tweede factor houdt een gestolen wachtwoord op een sleutel te zijn en wordt het een halve.
Samen doen die vier iets wat rotatie nooit deed: ze wijzigen het wachtwoord precies wanneer er een reden is, omdat je erachter komt dat die er is. Een manager die de lijsten in de gaten houdt is een waarschuwingssysteem; een kalender waarschuwt nergens voor, hij verstrijkt alleen.
En als je werkgever het elke negentig dagen afdwingt
Het gebeurt, en vaak, want er bestaan beleidsregels van vijftien jaar geleden die niemand sindsdien heeft opengeslagen. Twee dingen.
Ten eerste, praktisch: als je het moet wijzigen, wijzig het dan echt. Genereer een volledig nieuw exemplaar en zet het in de manager. De seizoensvariant is het enige wat erger is dan niet wijzigen, omdat het het gevoel geeft dat je iets hebt gedaan.
Ten tweede, voor wie het beleid kan bijsturen: het argument hoef je niet te verzinnen. Het staat in SP 800-63B, het is de officiële richtlijn van het NIST, en er staat met zoveel woorden dat periodieke wachtwoordwijziging niet moet worden geëist en dat een wijziging wél moet worden afgedwongen bij aanwijzingen van compromittering. Wie vandaag de negentigdagenregel aanhoudt, volgt een document dat de instantie die het uitgaf jaren geleden heeft vervangen.
Het korte antwoord, nog een keer
Hoe vaak moet je je wachtwoord veranderen? Als er iets gebeurt.
En omdat «als er iets gebeurt» alleen werkt als je erachter komt dát het gebeurd is, luidt het lange antwoord: zorg dat elk wachtwoord lang, uniek en bewaakt is, zodat je op de dag dat er één gewijzigd moet worden dat weet, dat het er één is, en dat het je twee minuten kost.
De rest is een vinkje zetten op een kalender om je veilig te voelen.
Bronnen: NIST SP 800-63, «Electronic Authentication Guideline» (2003), waarin de samenstellingsregels en de periodieke wijziging staan · NIST SP 800-63B, «Digital Identity Guidelines: Authentication and Lifecycle Management» (2017): lengte boven complexiteit, geen willekeurige periodieke wijziging, afgedwongen wijziging bij aanwijzingen van compromittering en toetsing aan lijsten van gecompromitteerde wachtwoorden · uitspraken van Bill Burr, auteur van de richtlijn uit 2003, tegen de Wall Street Journal in augustus 2017.
Foto van Hatice Baran · Pexels