De eisen van de richtlijn gaan wél over wachtwoordlengte, synchroniseerbare authenticators, e-mail, codes via telefoon en sms, en sessietime-outs. Het materiaal dat voor dit artikel is beoordeeld, definieert echter niet wat als phishingbestendig geldt. Deze uitleg beperkt zich daarom tot wat de tekst van de richtlijn zegt, en waar we zelf een interpretatie geven, vermelden we dat expliciet.
Wat de NIST-richtlijn voor authenticatie is en voor wie ze geldt
Volgens de documentgeschiedenis op de NIST-publicatiepagina op csrc.nist.gov is de definitieve versie van SP 800-63B-4 gedateerd op 31 juli 2025. Wanneer dit artikel een eis aanhaalt, vermelden we ook wie eraan moet voldoen, want de richtlijn legt haar verplichtingen bij specifieke partijen neer.
Veel eisen gelden voor verifiers en CSP's, de partijen die worden genoemd in het NIST-hoofdstuk over authenticators op pages.nist.gov. Andere eisen richten zich op federale overheidsinstanties. Zo staat in de NIST-richtlijntekst op pages.nist.gov dat federale instanties minimaal AAL2 moeten kiezen wanneer persoonsgegevens online beschikbaar worden gesteld.
Onze eigen lezing: deze regels zijn geschreven voor de organisaties die inlogsystemen beheren, niet als instructies voor mensen met een rekening bij een broker, een exchange of een e-mailaccount. Toch kunnen ze lezers helpen begrijpen welke inlogopties een dienst aanbiedt en waarom. Op zichzelf laten ze niet zien hoe een bepaalde dienst zijn gebruikers beschermt.
Wachtwoord versus MFA: wat de tekst van wachtwoorden eist
De duidelijkste wachtwoordregel in de beoordeelde beweringen gaat over wachtwoorden die op zichzelf worden gebruikt. Volgens het NIST-hoofdstuk over authenticators op pages.nist.gov moeten verifiers en CSP's eisen dat wachtwoorden die als authenticatiemechanisme met één factor worden gebruikt, minstens 15 tekens lang zijn.
Ter historische vergelijking beschrijft de NIST-FAQ over digitale identiteit het oudere LOA-model. Daarin was, wat authenticators betreft, het grootste verschil tussen LOA1 en LOA2 dat de minimale wachtwoordlengte steeg van zes naar acht tekens.
| Regel in de beoordeelde beweringen | Bron |
|---|---|
| Wachtwoorden als enige factor: minstens 15 tekens, verplicht gesteld door verifiers en CSP's | NIST-hoofdstuk over authenticators |
| Oud LOA-model: minimale wachtwoordlengte ging tussen LOA1 en LOA2 van zes naar acht tekens | NIST-FAQ |
Onze eigen lezing: als een wachtwoord de enige factor is, vraagt de huidige tekst om een veel langer minimum dan de oude LOA-waarden. De beoordeelde beweringen noemen geen specifieke lengte voor wachtwoorden die als één van de factoren binnen MFA worden gebruikt, dus dit artikel geeft die ook niet.
Passkeys, synchroniseerbare authenticators en AAL3
Het woord "passkey" komt in de beoordeelde beweringen nergens voor. Wel behandelen ze een verwante categorie: synchroniseerbare authenticators (syncable authenticators). Volgens de NIST-richtlijntekst op pages.nist.gov mogen synchroniseerbare authenticators niet op AAL3 worden gebruikt, omdat ze vereisen dat de private key exporteerbaar is.
Die zin bevat zowel een regel als de opgegeven reden:
- De regel: synchroniseerbare authenticators zijn uitgesloten op AAL3.
- De opgegeven reden: ze vereisen dat de private key exporteerbaar is.
Wat dit artikel op basis van de beoordeelde beweringen niet kan beslechten:
- Of een specifiek product dat als passkey wordt verkocht of aangeduid, een synchroniseerbare authenticator is.
- Hoe de richtlijn synchroniseerbare authenticators behandelt op andere niveaus dan AAL3.
- Of een passkey voldoet aan een definitie van phishingbestendigheid.
Onze eigen lezing: wie een passkey vergelijkt met een wachtwoord plus MFA, doet er goed aan eerst uit te zoeken of de betreffende passkey zijn sleutel synchroniseert. Dat is precies de eigenschap waar deze regel om draait. Omdat de beweringen daar ophouden, laten we de indeling van specifieke passkeys bewust open.
Codes via e-mail, sms en telefoon bij inloggen met meerdere factoren
Verschillende gangbare tweede stappen komen in de beoordeelde beweringen aan bod. Het NIST-hoofdstuk over authenticators op pages.nist.gov stelt dat e-mail niet mag worden gebruikt voor out-of-band-authenticatie. Hetzelfde hoofdstuk zegt dat out-of-band-authenticatie als ongeldig moet worden beschouwd, tenzij ze binnen 10 minuten is afgerond.
Codes via telefoon en sms worden behandeld in de NIST-FAQ over digitale identiteit. Daar staat dat authenticators die gebruikmaken van het openbare geschakelde telefoonnetwerk, waaronder eenmalige codes (OTP's) via telefoon en sms, aan beperkingen onderworpen zijn ("restricted"). Wat die beperking in de praktijk inhoudt, leggen de beoordeelde beweringen niet uit, dus ook dit artikel gaat daar niet verder op in.
| Methode | Wat de beoordeelde beweringen zeggen |
|---|---|
| E-mail voor out-of-band-authenticatie | Mag niet worden gebruikt |
| Out-of-band-authenticatie in het algemeen | Ongeldig tenzij binnen 10 minuten afgerond |
| OTP's via telefoon en sms | Beperkt ("restricted") |
Onze eigen lezing: "MFA" omvat verschillende soorten tweede stappen, en de richtlijn behandelt die niet allemaal hetzelfde. Wie de inlogopties van een e-mailaccount of een rekening bij een broker of exchange bekijkt, kan dit onderscheid nuttig vinden. Maar deze regels vertellen je niet welke optie een bepaalde dienst gebruikt of hoe goed die werkt.
Time-outs voor herauthenticatie op AAL2 en AAL3
Ook voor sessies verschillen de regels per niveau. Volgens de NIST-richtlijntekst op pages.nist.gov moet op AAL2 een vaste, algehele time-out voor herauthenticatie worden ingesteld, en die zou niet langer dan 24 uur moeten zijn. Op AAL3 mag de algehele time-out voor herauthenticatie niet langer zijn dan 12 uur.
| Niveau | Algehele time-out voor herauthenticatie |
|---|---|
| AAL2 | Moet worden ingesteld; zou niet langer dan 24 uur moeten zijn |
| AAL3 | Mag niet langer zijn dan 12 uur |
Let goed op de formulering. Bij AAL2 gebruikt de grens het woord "should" (zou moeten), bij AAL3 het woord "must" (moet). Dit artikel houdt dat verschil aan, in plaats van beide als even bindend voor te stellen.
Onze eigen lezing: als een dienst je na verloop van tijd opnieuw laat inloggen, kan dat voortkomen uit een time-outbeleid van deze soort. De beweringen zeggen niet hoe een individuele dienst zijn time-outs instelt.
Wat is phishingbestendig, en hoe weeg je beweringen daarover?
De beoordeelde beweringen uit de NIST-richtlijntekst op pages.nist.gov bevatten geen definitie van phishingbestendigheid. Ze zeggen ook niet of passkeys, synchroniseerbare authenticators of een andere methode aan zo'n definitie voldoen. Dit artikel laat die vraag bewust open en leent geen definitie uit secundaire samenvattingen die niet in de bronbeoordeling zijn meegenomen.
Die voorzichtigheid geldt voor beweringen over beveiliging in het algemeen. De snelle-tipsgids van CERT.br stelt dat een gerucht doorgaans een alarmerende toon heeft, gaat over onderwerpen die op dat moment veel aandacht krijgen, en geen informatiebron noemt of naar onbekende bronnen verwijst. Een verwante gewoonte, in onze eigen lezing: als een bericht of post beweert dat een inlogmethode veilig of onveilig is, zoek dan de primaire tekst op waarop die bewering steunt, en controleer of de oorspronkelijke formulering "must", "should" of iets zwakkers gebruikt.
Dit kan dit artikel wel en niet beantwoorden over de centrale vraag:
- Beantwoord op basis van de beweringen: regels over de lengte van wachtwoorden als enige factor, e-mail en de tijdslimiet voor out-of-band-authenticatie, codes via telefoon en sms, synchroniseerbare authenticators op AAL3, en time-outs voor herauthenticatie.
- Open gelaten: een definitie van phishingbestendigheid, en hoe specifieke passkeys daarin passen.
Beperkingen van dit artikel
Dit artikel biedt educatieve informatie over gepubliceerde richtlijnen voor authenticatie. Het is geen beleggingsadvies en beveelt geen product, broker, exchange of dienst aan. Het behandelt geen onderdelen van de NIST-richtlijn buiten de hier genoemde beweringen en definieert geen phishingbestendigheid. Het beoordeelt niet hoe een specifiek account of een specifieke dienst zijn gebruikers beschermt.