Wachtwoorden en inloggen veilig bouwen: wat NIST en OWASP adviseren

Veilig inloggen bouwen betekent: lange wachtwoorden toestaan in plaats van ingewikkelde regels afdwingen, controleren of een wachtwoord niet al is gelekt, en voor gevoelige acties extra verificatie vragen. Dat is, kort gezegd, wat NIST in SP 800-63B en OWASP in de Authentication Cheat Sheet adviseren. Per 11 oktober 2026 zijn dit de teksten die op de sites van beide organisaties staan. In dit artikel lees je wat ze letterlijk zeggen, wat dat in een klantportaal betekent en wat jij als opdrachtgever aan je bouwer kunt vragen.

Wat adviseert NIST over wachtwoorden?

De eisen in NIST SP 800-63B, onderdeel van de 800-63-4-reeks, zijn gericht aan verifiers en CSP's (credential service providers). In onze woorden: de partijen die bij het inloggen controleren of iemand is wie hij zegt, en die inloggegevens uitgeven en beheren. Over de lengte staat daar dat wachtwoorden die als enige factor worden gebruikt minimaal 15 tekens lang moeten zijn. Wachtwoorden die alleen deel zijn van multi-factor authenticatie mogen korter zijn, maar moeten minimaal acht tekens tellen. Verder zou een maximale wachtwoordlengte van minstens 64 tekens moeten worden toegestaan. Voor een klantportaal betekent dat: stel een ondergrens in en een ruime bovengrens, en laat lange zinnen toe.

NIST schrijft ook wat je niet moet afdwingen. Er mogen geen andere samenstellingsregels worden opgelegd, zoals het vereisen van verschillende tekensoorten. Gebruikers mogen niet worden verplicht hun wachtwoord periodiek te wijzigen. Daar tegenover staat een controle: een nieuw wachtwoord wordt vergeleken met een blocklist die veelgebruikte, verwachte of gelekte wachtwoorden bevat. Het idee is dat lengte en uniekheid meer opleveren dan een verplichte hoofdletter of een wisseling om de zoveel weken, en dat zulke regels gebruikers naar voorspelbare patronen duwen. Dat laatste is een toelichting, geen citaat van NIST.

Twee regels gaan over het gemak van de gebruiker. Verifiers moeten het gebruik van wachtwoordmanagers en autofill toestaan. En verifiers mogen gebruikers niet vragen om kennisgebaseerde authenticatie of beveiligingsvragen, zoals "Wat was de naam van je eerste huisdier?", bij het kiezen van wachtwoorden. Ons advies: blokkeer in het inlogformulier niets wat een wachtwoordmanager nodig heeft, en bouw geen geheime vragen als vangnet in. Laat je bouwer dit testen met een gangbare wachtwoordmanager, want een formulier dat automatisch invullen verstoort, werkt de regel tegen.

Wat staat er in de OWASP Authentication Cheat Sheet?

De OWASP Authentication Cheat Sheet is een praktische handleiding voor wie inlogfunctionaliteit bouwt. OWASP schrijft dat de minimale wachtwoordlengte door de applicatie moet worden afgedwongen. Ook staat erin dat wachtwoorden korter dan 15 tekens als zwak worden beschouwd als multi-factor authenticatie niet is ingeschakeld. OWASP verwijst daarbij naar NIST SP 800-63B. Beide bronnen komen dus op hetzelfde getal uit. Vraag je bouwer waar de lengteregel wordt gecontroleerd. Ons advies: laat de server haar afdwingen, want een controle die alleen in de browser zit, kan worden omzeild.

Twee andere regels uit de cheat sheet raken het ontwerp van het formulier. Inlogfunctionaliteit moet altijd een generieke foutmelding geven, ongeacht of de gebruiker bestaat, het wachtwoord onjuist is of het account is geblokkeerd. Zo kan niemand door te proberen achterhalen welke e-mailadressen een account hebben, wat gebruikersenumeratie heet. En OWASP adviseert een extra laag verificatie te vragen voor gevoelige acties of gebeurtenissen. Dat sluit aan bij de categorie Authentication Failures, die per 11 oktober 2026 als A07:2025 op plek 7 van de OWASP Top 10:2025 staat.

Hoe komt dit terug in een klantportaal?

Wat betekent dit voor een klantportaal? Eerst het registratieformulier en het inlogscherm: een duidelijke lengte-eis, een ruime maximumlengte, geen verplichte tekensoorten en een controle tegen lekkenlijsten. Dan de foutmeldingen: één neutrale tekst voor elke mislukte poging, ook bij het opvragen van een nieuw wachtwoord, zodat de pagina niet verklapt of een adres bestaat. Dit is een vertaling van de bronnen naar een portaal, geen norm die letterlijk zo in NIST of OWASP staat. Een bouwer die de bronnen kent, kan per scherm aanwijzen welke regel erachter zit.

Voor gevoelige acties vraag je een extra stap. Welke acties dat in jouw portaal zijn, bepaal je zelf; de voorbeelden hieronder zijn onze eigen uitleg en geen lijst van OWASP. In een portaal kun je denken aan het wijzigen van een e-mailadres, een betaalgegeven of een wachtwoord, en aan het downloaden van een volledig dossier. Dat is een voorbeeld, geen vaste lijst. Bepaal samen met je bouwer welke handelingen bij jouw portaal gevoelig zijn, leg die vast in het ontwerp en laat het testen. Bij een portaal waar klanten persoonsgegevens inzien, hoort dat bij de basis. Meer over de rest van de beveiliging staat in de klantportaal-checklist.

Het NCSC wijst erop dat veel webapplicaties persoonsgegevens of andere gevoelige informatie verwerken. Volgens het NCSC op 11 oktober 2026 zijn de maatregelen in de richtlijnen voor webapplicaties aangepast om meer te sturen op phishingbestendige, wachtwoordloze authenticatie. De precieze maatregelen staan in de richtlijn zelf; die hebben we niet gelezen en werken we hier niet uit. Wat je wel kunt meenemen: vraag je bouwer of het portaal nu of later andere inlogmethoden dan alleen een wachtwoord kan ondersteunen. Een ontwerp dat inloggen als aparte laag bouwt, is daar beter op voorbereid dan een ontwerp waarin het wachtwoord overal doorheen is geweven.

Wat vraag je aan je bouwer?

Vragen die je aan je bouwer kunt stellen, op basis van de bronnen. Wat is de minimale en de maximale lengte van een wachtwoord, en wordt dat op de server afgedwongen? Worden nieuwe wachtwoorden vergeleken met een blocklist van veelgebruikte of gelekte wachtwoorden? Zijn er geen verplichte tekensoorten, geen verplichte periodieke wijzigingen en geen beveiligingsvragen? Werkt het formulier met wachtwoordmanagers en autofill? Is de foutmelding bij inloggen generiek? En voor welke acties wordt extra verificatie gevraagd? Elk antwoord moet je kunnen terugvinden in het ontwerp of de testresultaten.

Let op wat een goede aanbieder niet doet. Een bouwer die jou aanraadt om periodiek een nieuw wachtwoord af te dwingen, of die ingewikkelde samenstellingsregels als beveiliging presenteert, volgt op die punten NIST SP 800-63B niet. NIST schrijft namelijk voor dat verifiers en CSP's geen andere samenstellingsregels opleggen en gebruikers niet verplichten hun wachtwoord periodiek te wijzigen (SHALL NOT). Dat maakt zo'n bouwer niet meteen onbetrouwbaar, maar het is een goede reden om door te vragen naar de bron van de eis. Vraag dus altijd om de bron: een norm, een richtlijn of een eigen keuze met een motivatie. Dat voorkomt dat eigen gewoonten als norm worden gepresenteerd.

Wat blijft een eigen keuze per portaal?

Niet alles staat in de bronnen. Hoeveel mislukte pogingen leiden tot een blokkade, hoe lang een sessie open blijft, hoe een vergeten wachtwoord wordt hersteld en welke tweede factor je aanbiedt: die keuzes zijn per portaal anders en vragen om een afweging tussen gemak en risico. We geven hier bewust geen getallen, omdat de feiten die we voor dit artikel hebben nagelezen ze niet bevatten. Een goede bouwer legt zijn keuze uit en noemt de bron of het risico waarop de keuze rust. Zet de keuzes in het ontwerpdocument zodat een latere beheerder weet waarom het zo is gebouwd.

Een klantportaal met veilig inloggen laten bouwen

Digitaalnu bouwt klantportalen als webapplicatie tegen een vaste prijs, vanaf €2.000 per project. De code en de data zijn voor 100% van jou. Gebruik de vragen uit dit artikel als agenda bij een intake, ook als je een bestaand portaal wilt laten beoordelen. Voor het onderhoud van WordPress-sites met een inlogomgeving, zoals een ledengedeelte, kijk je bij WordPress-onderhoud. Wil je zien hoe inloggen past in een bredere aanpak van gegevens en rechten, lees dan de gids over een klantportaal laten bouwen.

Laatst bijgewerkt op 11 oktober 2026