Een wachtwoordbeleid moet accounts moeilijker te kraken maken zonder veilig gedrag onnodig lastig te maken. De beste beleidsregels zijn duidelijk, praktisch en afgestemd op hoe mensen daadwerkelijk werken. Ze stimuleren het gebruik van lange, unieke wachtwoorden, ondersteunen wachtwoordmanagers, vereisen waar mogelijk multi-factor authenticatie (MFA), en vermijden verouderde regels die voorspelbaar gedrag veroorzaken.
Dit artikel legt uit wat je wel en niet moet doen bij een modern wachtwoordbeleid, wat je moet vermijden, welke best practices er zijn, en bevat een sjabloon dat je direct kunt overnemen voor jouw organisatie.
Wat is een wachtwoordbeleid?
Een wachtwoordbeleid is een reeks regels die bepalen hoe wachtwoorden worden aangemaakt, opgeslagen, gebruikt, gedeeld, gewijzigd en beschermd. Het is van toepassing op medewerkers, contractanten, beheerders, serviceaccounts en soms klanten, afhankelijk van de betrokken systemen.
Een goed wachtwoordbeleid moet praktische vragen beantwoorden:
- Hoe lang moeten wachtwoorden zijn?
- Zijn wachtwoordzinnen toegestaan?
- Mogen gebruikers wachtwoorden plakken vanuit een wachtwoordmanager?
- Wanneer moet een wachtwoord worden gewijzigd?
- Is multi-factor authenticatie verplicht?
- Hoe wordt omgegaan met gedeelde inloggegevens?
- Wat gebeurt er als een wachtwoord mogelijk is gecompromitteerd?
Het doel is niet het meest ingewikkelde regelpakket maken, maar het echte risico verlagen.
De do's van een modern wachtwoordbeleid
Vereis voldoende lengte
Lengte is een van de sterkste verdedigingen tegen gokken en brute-force aanvallen. Eén minimale vereiste voor de hele organisatie is vaak begrijpelijker voor mensen en makkelijker te handhaven dan verschillende regels voor normale gebruikers, beheerders en speciale gevallen. Een praktische standaard is minimaal 16 tekens voor alle accounts van menselijke gebruikers. Langer is beter wanneer men gebruikmaakt van een wachtwoordmanager of willekeurig gegenereerde wachtwoordzinnen.
Sta lange wachtwoorden en wachtwoordzinnen toe
Gebruikers moeten wachtwoorden kunnen maken die veel langer zijn dan het minimum. Vermijd lage maximale limieten zoals 16 of 20 tekens. Een maximumlengte van minimaal 64 tekens is een redelijke basis, en veel systemen kunnen nog langere wachtwoorden veilig ondersteunen.
Wachtwoordzinnen moeten zijn toegestaan mits ze lang zijn en niet gebaseerd op bekende citaten, songteksten, bedrijfsnamen of voorspelbare zinnen. Een wachtwoordzin die uit verschillende willekeurige woorden bestaat is meestal beter dan een kort wachtwoord met geforceerde substituties.
Vereis uniciteit
Elke account moet een uniek wachtwoord hebben. Hergebruik is een van de belangrijkste redenen waardoor een inbreuk bij één dienst leidt tot overname van accounts bij andere diensten. Een wachtwoordmanager maakt het praktisch om unieke wachtwoorden te gebruiken, omdat gebruikers deze niet allemaal hoeven te onthouden.
Ondersteun wachtwoordmanagers
Je beleid moet expliciet goedkeuren en stimuleren om een goedgekeurde wachtwoordmanager te gebruiken. Gebruikers moeten wachtwoorden mogen plakken in inlogformulieren, automatisch laten invullen en willekeurige wachtwoorden mogen genereren. Het blokkeren van plakken lijkt misschien beschermend, maar ontmoedigt vaak juist het gebruik van sterke wachtwoordmanagers.
Controleer wachtwoorden op bekende gecompromitteerde wachtwoorden
Wachtwoorden moeten worden geweigerd als ze voorkomen in bekende dataleklijsten, veelgebruikte wachtwoordenlijsten of organisatie-specifieke zwarte lijsten. Dit is effectiever dan gebruikers verplichten om één hoofdletter, een cijfer en een symbool op te nemen.
Vereis MFA waar technisch mogelijk
Multi-factor authenticatie moet worden ingeschakeld waar technisch mogelijk, vooral voor beheerders, externe toegang, clouddiensten, e-mail, wachtwoordmanagers, financiële systemen en andere waardevolle systemen. MFA vervangt geen sterke wachtwoorden, maar vermindert wel de impact van gestolen credentials.
Geef de voorkeur aan phishing-resistente MFA zoals passkeys, hardwarebeveiligingssleutels, of platform authenticators. App-gebaseerde authenticators zijn meestal beter dan SMS. SMS-MFA mag alleen worden gebruikt als er geen andere MFA-methode technisch mogelijk is, omdat telefoonnummers kunnen worden onderschept, overgezet (SIM-swapping of portering), of misbruikt via account recovery.
Dit is geen theoretisch risico. In 2018 maakte Reddit bekend dat aanvallers sms-gebaseerde twee-factor-authenticatie onderschepten en toegang kregen tot interne systemen: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. In 2021 meldde Coinbase dat aanvallers cryptocurrency van minstens 6.000 klanten hebben gestolen na misbruik van inloggegevens en een zwakke plek in het SMS-recovery-proces: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
Wijzig wachtwoorden na compromittering
Wachtwoorden dienen gewijzigd te worden wanneer er aanwijzingen of een redelijk vermoeden is van compromittering. Voorbeelden zijn phishing, malware op het apparaat van de gebruiker, credentials uitgelekt bij een datalek, verdachte login-activiteit, of onbedoelde openbaarmaking.
Bescherm gedeelde wachtwoorden goed
Gedeelde wachtwoorden moeten worden vermeden waar individuele accounts mogelijk zijn. Indien gedeelde credentials onvermijdelijk zijn, moeten deze worden opgeslagen in een goedgekeurde wachtwoordmanager, alleen toegankelijk zijn voor gemachtigde gebruikers, en moet het delen waar mogelijk worden gelogd.
Maak herstelprocessen veilig
Wachtwoordreset is vaak het zwakste punt in accountbeveiliging. Herstelprocessen moeten identiteit verifiëren, resetlinks snel laten verlopen, single-use tokens gebruiken en gebruikers op de hoogte stellen wanneer hun wachtwoord is gewijzigd.
De don'ts van een modern wachtwoordbeleid
Verplicht geen frequente wachtwoordwijzigingen zonder reden
Verplichte wisselingen elke 30, 60 of 90 dagen leiden vaak tot zwakkere wachtwoorden. Gebruikers passen meestal kleine, voorspelbare aanpassingen toe zoals het toevoegen van een cijfer of een aanpassing aan het seizoen. De Digital Identity Guidelines van NIST hebben het routinematige periodieke vervangen afgeschaft en eisen wijziging alleen bij aanwijzingen van compromittering. Zie sectie 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Eis een wijziging na vermoed compromis, functiewijzigingen, account recovery, of als een wachtwoord niet langer aan het beleid voldoet.
Vertrouw niet alleen op complexiteitsregels
Regels als "moet een hoofdletter, kleine letter, cijfer en symbool bevatten" garanderen geen sterkte. Password1! voldoet aan veel complexiteitsregels maar is nog steeds zwak. Prioriteer lengte, uniciteit, willekeur en screening op datalekken.
Blokkeer kopiëren en plakken niet
Het blokkeren van plakken maakt het gebruik van wachtwoordmanagers lastiger. Dit dwingt gebruikers sneller om kortere, makkelijk te typen wachtwoorden te kiezen. Sta plakken en automatisch invullen toe, tenzij er een specifieke, gedocumenteerde beveiligingsreden is om het te blokkeren.
Sta geen wachtwoordhints toe
Wachtwoordhints geven vaak teveel prijs. Als een gebruiker het antwoord uit de hint kan afleiden, kan een aanvaller dat vaak ook. Gebruik in plaats daarvan veilige herstelprocessen.
Sla wachtwoorden nooit in platte tekst op
Systemen mogen wachtwoorden nooit als platte tekst of met omkeerbare encryptie opslaan. Wachtwoorden dienen gehasht te worden met een moderne, langzame en gesalte hashmethode zoals Argon2id, bcrypt, scrypt of PBKDF2, afhankelijk van de systeemeisen en regelgeving.
Snelle, generieke hash-algoritmen zoals MD5, SHA-1, SHA-256 of SHA-512 zijn niet geschikt als wachtwoordhashmethode. Ze zijn ontworpen om snel te zijn, wat brute-force aanvallen na een datalek makkelijker maakt. Voor meer achtergrond, zie ons artikel over de evolutie van wachtwoordhashing.
Deel wachtwoorden niet via chat of e-mail
Wachtwoorden mogen niet worden verzonden via e-mail, chat, tickets, documenten of screenshots. Gebruik een wachtwoordmanager met veilige deel- en toegangsbeheerfuncties.
Gebruik geen persoonlijke informatie of voorspelbare patronen
Wachtwoorden mogen geen namen, geboortedata, bedrijfsnamen, toetsenbordpatronen, herhaalde karakters of veel gebruikte substituties bevatten zoals @ voor a en 0 voor o. Aanvallers proberen deze patronen als eerste.
Best practices voor organisaties
Stel duidelijke minimumvereisten vast
Gebruik vereisten die makkelijk te begrijpen zijn:
- Eén minimale lengte, bijvoorbeeld 16 tekens voor alle menselijke gebruikersaccounts
- Sta minstens 64 tekens toe
- Sta spaties en gangbare symbolen toe
- Sta wachtwoordzinnen en wachtwoordmanagers toe
- Weiger gecompromitteerde en veelgebruikte wachtwoorden
Behandel bevoorrechte accounts anders
Beheerdersaccounts, serviceaccounts en productie-accounts verdienen strengere controles. Vereis sterkere wachtwoorden, MFA, beperkte toegang, monitoring, en onmiddellijke rotatie bij toegangsveranderingen.
Gebruik rolgebaseerde toegang en least privilege
Sterke wachtwoorden kunnen overmatige rechten niet compenseren. Gebruikers mogen alleen toegang hebben tot systemen en geheimen die nodig zijn voor hun rol.
Monitor op verdachte activiteiten
Detecteer ongebruikelijke loginpatronen, onmogelijk reizen, herhaalde mislukte pogingen, loginpogingen vanuit nieuwe landen, en toegang buiten werktijden. Wachtwoordbeleid dient te worden ondersteund door monitoring en incident response.
Train gebruikers op realistische dreigingen
Training moet zich richten op wachtwoordhergebruik, phishing, valse loginpagina's, MFA-moeheid, veilig delen, en melden van vermoed compromis. Geef gebruikers geen schuld. Maak veilig gedrag makkelijk.
Houd het beleid kort genoeg om te begrijpen
Een wachtwoordbeleid moet begrijpelijk zijn. Is het beleid te lang, vaag of streng, dan zullen mensen het omzeilen. Het beste beleid is dat wat daadwerkelijk gehandhaafd en nageleefd wordt.
Copy-paste wachtwoordbeleid sjabloon
Gebruik onderstaand sjabloon als uitgangspunt. Pas de onderdelen tussen haakjes aan voor jouw organisatie, systemen, risiconiveau en wettelijke vereisten.
Wachtwoordbeleid
Versie: [1.0]
Eigenaar: [Security / IT-afdeling]
Datum van inwerkingtreding: [JJJJ-MM-DD]
Herzieningscyclus: [Elke 12 maanden]
1. Doel
Dit beleid definieert de eisen voor het aanmaken, gebruiken, opslaan, delen en wijzigen van wachtwoorden voor [Organisatienaam]. Het doel is het risico te verminderen van ongeautoriseerde toegang, credentialdiefstal, overname van accounts en dataverlies.
2. Toepassingsgebied
Dit beleid geldt voor alle medewerkers, opdrachtnemers, tijdelijke krachten, dienstverleners, en andere gebruikers die toegang hebben tot systemen, applicaties, netwerken, cloudservices of gegevens van [Organisatienaam].
Dit beleid is van toepassing op standaardgebruikersaccounts, bevoorrechte accounts, serviceaccounts, gedeelde accounts en elk systeem waar wachtwoorden voor authenticatie worden gebruikt.
3. Eisen voor wachtwoordcreatie
Alle wachtwoorden moeten aan de volgende eisen voldoen:
- Accounts van menselijke gebruikers moeten een wachtwoord van minstens 16 tekens hebben.
- Wachtwoorden moeten uniek zijn en mogen niet worden hergebruikt voor werk- of privéaccounts.
- Wachtwoorden mogen geen namen, gebruikersnamen, bedrijfsnamen, geboortedata, toetsenbordpatronen, herhaalde karakters of andere makkelijk te raden informatie bevatten.
- Wachtwoorden mogen niet gebaseerd zijn op bekende zinnen, citaten, songteksten of voorspelbare substituties.
- Wachtwoorden mogen niet voorkomen op bekende datalek- of veelgebruikte wachtwoordenlijsten.
- Wachtwoorden mogen spaties, symbolen, cijfers, hoofdletters en kleine letters bevatten.
- Wachtwoordzinnen zijn toegestaan mits ze lang, uniek en niet gebaseerd op voorspelbare of publieke zinnen zijn.
4. Wachtwoordmanagers
[Organisatienaam] vereist of stimuleert sterk het gebruik van een goedgekeurde wachtwoordmanager voor het aanmaken, opslaan en delen van wachtwoorden.
Gebruikers mogen een wachtwoordgenerator, automatisch invullen en kopieer-/plakfunctionaliteit van de goedgekeurde wachtwoordmanager gebruiken. Wachtwoorden mogen niet worden opgeslagen in browsers, spreadsheets, documenten, notitie-apps, e-mail, chat, screenshots of niet-goedgekeurde middelen.
5. Multi-factor authenticatie
Multi-factor authenticatie moet overal waar technisch mogelijk worden ingeschakeld, waaronder maar niet beperkt tot:
- E-mailaccounts
- Externe toegangssystemen
- Accounts voor wachtwoordmanagers
- Clouddiensten
- Beheerdersaccounts
- Financiële, HR- en andere kritieke systemen
- Elk systeem geclassificeerd als [vertrouwelijk / kritiek]
Waar beschikbaar gebruiken gebruikers phishing-resistente MFA zoals passkeys, hardwarebeveiligingssleutels of platform authenticators. Authenticator-apps hebben de voorkeur boven SMS. SMS-MFA is verboden tenzij geen enkele andere MFA-methode technisch mogelijk is en mag alleen worden gebruikt waar geen sterkere MFA-optie mogelijk is.
6. Wijziging van wachtwoorden
Wachtwoorden moeten direct gewijzigd worden als:
- Een wachtwoord bekend of vermoed gecompromitteerd is.
- Een gebruiker een wachtwoord heeft ingevoerd op een vermoedelijk phishingplatform.
- Een wachtwoord gedeeld is met een niet-geautoriseerde persoon.
- Malware of ongeautoriseerde toegang is gedetecteerd op het apparaat van de gebruiker.
- Een wachtwoord voorkomt in een bekend datalek.
- De rol of het dienstverband van een bevoorrechte gebruiker verandert.
- IT of Security de gebruiker instrueert het wachtwoord te wijzigen.
Routinematige wachtwoordvervaltermijnen zijn niet vereist, tenzij wettelijk, contractueel of door het systeem verplicht. Wachtwoorden mogen niet worden gewijzigd door kleine voorspelbare aanpassingen aan het vorige wachtwoord.
7. Delen van wachtwoorden
Wachtwoorden mogen niet worden gedeeld via e-mail, chat, tickets, documenten, screenshots, telefoongesprekken of mondeling.
Gedeelde credentials zijn alleen toegestaan wanneer individuele accounts technisch niet mogelijk zijn, of met expliciete goedkeuring van [Security / IT]. Gedeelde wachtwoorden moeten opgeslagen en gedeeld worden via de goedgekeurde wachtwoordmanager en alleen toegankelijk zijn voor geautoriseerde gebruikers.
8. Bevoorrechte accounts
Bevoorrechte accounts moeten unieke wachtwoorden gebruiken die niet worden gebruikt voor standaardgebruikersaccounts. Privileged accounts moeten waar mogelijk MFA gebruiken en regelmatig worden gecontroleerd.
Bevoorrechte wachtwoorden moeten worden geroteerd als een beheerder de organisatie verlaat, van rol verandert, geen toegang meer nodig heeft, of als er sprake is van vermoeden van compromis.
9. Serviceaccounts en applicatiegeheimen
Wachtwoorden voor serviceaccounts, API-sleutels, tokens en applicatiegeheimen moeten worden opgeslagen in een goedgekeurd secrets management systeem of wachtwoordmanager.
Inloggegevens voor serviceaccounts mogen niet worden opgenomen in broncode, configuratiebestanden, afbeeldingen, documentatie of scripts, tenzij beschermd door een goedgekeurd secrets management proces.
10. Wachtwoord resetten en recovery
Processen voor het resetten van wachtwoorden moeten de identiteit van de gebruiker verifiëren alvorens toegang te herstellen. Resetlinks en tijdelijke wachtwoorden moeten single-use zijn, snel verlopen en worden verzonden via goedgekeurde kanalen.
Gebruikers moeten worden geïnformeerd wanneer hun wachtwoord is gewijzigd of gereset. Tijdelijke wachtwoorden moeten bij de eerste login worden gewijzigd.
11. Technische controles
Systemen die wachtwoorden opslaan of verwerken moeten:
- Wachtwoorden nooit in platte tekst opslaan.
- Wachtwoorden hashen met een goedgekeurde moderne gesalte hashmethode: PBKDF2, scrypt, bcrypt of Argon2.
- Geen MD5, SHA-1, SHA-256, SHA-512 of andere snelle generieke hash-algoritmen als enige wachtwoordhashmethode gebruiken.
- Authenticatie-endpoints beschermen met rate limiting of gelijkwaardige maatregelen.
- Veelgebruikte, zwakke en bekende gecompromitteerde wachtwoorden weigeren.
- Gebruikers toestaan wachtwoorden te plakken uit wachtwoordmanagers.
- Redelijke wachtwoordlengte ondersteunen, minimaal 64 tekens waar technisch mogelijk.
- Beveiligingsrelevante authenticatiegebeurtenissen loggen.
12. Vermoed compromis melden
Gebruikers moeten vermoed compromis, phishing, ongebruikelijke loginprompts, MFA-pushes die ze niet zelf hebben gestart, of onbedoelde openbaarmaking van een wachtwoord direct melden aan [Security / IT-contact].
13. Uitzonderingen
Uitzonderingen op dit beleid moeten worden gedocumenteerd, risicogewogen, tijdsgebonden en goedgekeurd door [Security / IT-leiding]. Compensatiemaatregelen dienen waar mogelijk te worden toegepast.
14. Handhaving
Niet-naleving van het beleid kan leiden tot verwijdering van toegang, verplichte securitytraining, disciplinaire maatregelen of andere stappen conform [Organisatienaam] beleid en toepasselijke wetgeving.
15. Evaluatie
Dit beleid moet minimaal jaarlijks worden herzien, of na significante veranderingen aan systemen, dreigingen, wetgeving of bedrijfsvoering.
Tot slot
Een sterk wachtwoordbeleid is niet bedoeld om het leven van gebruikers lastig te maken, maar om zwakke gewoontes te doorbreken, wachtwoordmanagers te ondersteunen, MFA te benutten en snel te reageren op blootgestelde credentials. Houd het beleid praktisch, handhaafbaar en gericht op echte aanvallen zoals phishing, credential stuffing, wachtwoordhergebruik en gecompromitteerde accounts.
