Misschien eist uw wachtwoordbeleid nog steeds een hoofdletter, een symbool en elke 90 dagen een nieuw wachtwoord. Het Amerikaanse National Institute of Standards and Technology (NIST) is van alle drie afgestapt. De actuele richtlijn, SP 800-63B-4, is in 2025 definitief vastgesteld en vervangt de editie van SP 800-63B uit 2020.
NIST schrijft deze richtlijnen voor Amerikaanse federale systemen, maar ze zijn een nuttig referentiepunt voor elke organisatie. Hieronder leest u wat erin staat en hoe u het toepast.
De wachtwoordregels in SP 800-63B-4
Paragraaf 3.1.1.2 bevat de eisen voor systemen die wachtwoorden controleren. NIST gebruikt SHALL voor eisen en SHOULD voor aanbevelingen.
| Onderwerp | Wat NIST zegt |
|---|---|
| Minimale lengte, wachtwoord als enige factor | SHALL: minstens 15 tekens |
| Minimale lengte, wachtwoord als onderdeel van MFA | SHALL: minstens 8 tekens |
| Maximale lengte | SHOULD: minstens 64 tekens toestaan |
| Tekens | SHOULD: alle afdrukbare ASCII-tekens, spaties en Unicode accepteren |
| Samenstellingsregels | SHALL NOT: niet opleggen, bijvoorbeeld "één hoofdletter, één cijfer, één symbool" |
| Periodieke wijziging | SHALL NOT: niet verplichten |
| Bekende compromittering | SHALL: een wijziging afdwingen als er bewijs is dat het wachtwoord is gecompromitteerd |
| Blokkeerlijst | SHALL: nieuwe wachtwoorden toetsen aan bekende veelgebruikte, voorspelbare of gecompromitteerde waarden |
| Hints en beveiligingsvragen | SHALL NOT: geen hints opslaan en niet vragen naar kennisgebaseerde vragen |
| Wachtwoordmanagers | SHALL: toestaan, inclusief automatisch invullen; SHOULD: plakken toestaan |
| Mislukte pogingen | SHALL: het aantal beperken (rate limiting) |
| Afkappen | SHALL: het volledige ingevoerde wachtwoord controleren |
Waarom de oude regels zijn verdwenen
Samenstellingsregels en verplichte wissels voelen streng, maar ze duwen mensen naar voorspelbare patronen. Een gebruiker die Autumn2026! moet wijzigen, kiest al snel Winter2026! (van herfst naar winter), en een aanvaller die het oude wachtwoord heeft, kan het nieuwe raden.
NIST vertrouwt in plaats daarvan op lengte en een blokkeerlijst. Een lange wachtzin is makkelijker te onthouden dan een korte willekeurige reeks. Wisselen helpt alleen als een wachtwoord is uitgelekt, dus NIST koppelt wijzigingen aan bewijs van compromittering en niet aan de kalender.
De blokkeerlijst vervangt de samenstellingsregels als het echte filter. Die weigert de wachtwoorden die aanvallers als eerste proberen: populaire keuzes, woorden die met uw organisatie te maken hebben en wachtwoorden die al in datalekken zijn opgedoken.
Toetsen aan gelekte wachtwoorden
Met de dienst "Pwned Passwords" van Have I Been Pwned kunt u een wachtwoord toetsen aan gelekte gegevens zonder het wachtwoord te versturen. Uw systeem hasht het wachtwoord met SHA-1 en stuurt alleen de eerste vijf tekens van de hash. De dienst geeft elk hash-einde terug dat met die vijf tekens begint, met een aantal, en u vergelijkt lokaal.
# SHA-1 of "password" is 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
curl -s -H "Add-Padding: true" https://api.pwnedpasswords.com/range/5BAA6Door deze aanpak, k-anonimiteit genoemd, komt de dienst nooit te weten welk wachtwoord u hebt gecontroleerd. Een gemiddeld antwoord bevat enkele honderden hash-eindes, en de header Add-Padding verbergt de werkelijke grootte van het antwoord voor wie het verkeer meekijkt. Voor het opzoeken van wachtwoordbereiken is geen API-sleutel nodig.
Bouw deze controle in de schermen waar wachtwoorden worden ingesteld en gewijzigd. Kijk in Active Directory-omgevingen naar tools die een lijst met gelekte wachtwoorden toepassen op wachtwoordwijzigingen in het domein.
Laat mensen wachtwoordmanagers gebruiken
NIST verplicht verificateurs om wachtwoordmanagers en automatisch invullen toe te staan. Dat is logisch: met een manager zijn lange, unieke wachtwoorden goed te doen, en hij vult alleen in op het domein waar het wachtwoord is opgeslagen. Plakken blokkeren op inlogformulieren werkt dit tegen.
Bied medewerkers een zakelijke wachtwoordmanager aan, in plaats van iedereen zelf te laten kiezen. Bescherm de manager zelf met een sterke hoofdwachtzin en phishingbestendige MFA.
Niet alle MFA is gelijk
Met een tweede factor is een gestolen wachtwoord alleen niet meer genoeg, maar sommige methoden zijn nog steeds te phishen. De nep-inlogpagina van een aanvaller kan om een code vragen en die direct doorgeven. NIST definieert phishingbestendigheid als het vermogen van het protocol om te voorkomen dat geheimen worden prijsgegeven, zonder afhankelijk te zijn van de oplettendheid van de gebruiker.
| Methode | Phishingbestendig? | Opmerkingen van NIST |
|---|---|---|
| Code via sms of spraakoproep | Nee | Een "beperkte" authenticator; verificateurs moeten alternatieven bieden en horen alert te zijn op simswapping en nummerportering |
| Code uit een authenticator-app (TOTP) | Nee | Codes worden met de hand ingetypt, dus ze kunnen worden doorgegeven |
| Pushgoedkeuring of app via een apart kanaal | Nee | Out-of-band-methoden zijn niet phishingbestendig |
| Code of link per e-mail | Niet toegestaan als out-of-band-methode | E-mail SHALL NOT: niet gebruiken voor out-of-band-authenticatie |
| FIDO2/WebAuthn-beveiligingssleutel of passkey | Ja | Het antwoord is gebonden aan de geverifieerde naam van de site |
Op het middelste betrouwbaarheidsniveau van NIST, AAL2, moeten verificateurs (SHALL) minstens één phishingbestendige optie aanbieden. Op het hoogste niveau, AAL3, moet de authenticator phishingbestendig zijn en een privésleutel gebruiken die niet kan worden geëxporteerd.
Passkeys
Een passkey is een FIDO-inloggegeven dat op WebAuthn is gebaseerd. Uw apparaat maakt voor elke site een sleutelpaar aan. De site bewaart alleen de publieke sleutel, en de privésleutel blijft bij u. U ontgrendelt die op dezelfde manier als uw apparaat, bijvoorbeeld met een vingerafdruk, gezichtsherkenning of een pincode. De FIDO Alliance merkt op dat biometrische gegevens op het apparaat blijven en nooit naar de site worden gestuurd.
Omdat elke passkey aan één site is gekoppeld, werkt hij simpelweg niet op een phishingdomein dat op het echte lijkt. Er is op de server ook geen gedeeld geheim dat kan worden gestolen.
Passkeys zijn er in twee vormen:
- Gesynchroniseerde passkeys worden via de synchronisatiedienst van een aanbieder naar al uw apparaten gekopieerd. NIST noemt deze syncable authenticators en staat ze toe op AAL2. Omdat de sleutel kan worden geëxporteerd, mogen ze (SHALL NOT) niet op AAL3 worden gebruikt.
- Apparaatgebonden passkeys blijven op één apparaat, zoals een hardwarebeveiligingssleutel. Ze zijn geschikt voor beheerders en andere accounts met een hoog risico.
Denk ook aan accountherstel. Als iemand een account met een passkey kan resetten via een link per e-mail of een telefoontje naar de helpdesk, richten aanvallers zich gewoon op die route. Maak herstel minstens zo sterk als de inlogmethode die het vervangt.
Een beleid dat u kunt overnemen
- Minimaal 15 tekens waar een wachtwoord de enige factor is, en sta minstens 64 tekens toe.
- Geen samenstellingsregels en geen geplande vervaldatum.
- Toets elk nieuw wachtwoord aan een lijst met gelekte en veelgebruikte wachtwoorden.
- Dwing alleen een wijziging af bij bewijs van compromittering.
- Bied een wachtwoordmanager aan, en sta plakken en automatisch invullen toe.
- Eis MFA overal waar het beschikbaar is, en phishingbestendige MFA voor beheerders, e-mail en toegang op afstand.
- Voer passkeys in waar uw systemen dat ondersteunen, te beginnen bij accounts met een hoog risico.
- Beperk het aantal mislukte inlogpogingen en maak accountherstel even sterk als inloggen.
Waar u begint
Controleer met onze check op gelekte wachtwoorden of een wachtwoord al in gelekte gegevens voorkomt, en test met onze wachtwoordgenerator hoe lang een wachtzin moet zijn.
Werkt u aan een nieuw identiteitsbeleid of plant u de invoering van passkeys? Ons adviesteam helpt u bij de planning.
