- NIST SP 800-63B-4 er den gjeldende revisjonen, publisert i juli 2025.
- Den foretrekker lange passord fremfor regler om sammensetning, og dropper tvungne periodiske bytter.
- Den ber om sjekk mot kjente lekkede passord, og om en annen faktor på nivå 2.
Special Publication 800-63B er den delen av Digital Identity Guidelines fra det amerikanske National Institute of Standards and Technology som dekker autentisering: hvordan en person ved innlogging beviser at de er kontoinnehaveren. Den gjeldende revisjonen er SP 800-63B-4, med tittelen Digital Identity Guidelines: Authentication and Authenticator Management. NISTs publikasjonsside daterer den juli 2025 og oppgir at den erstatter den tidligere SP 800-63B.
Retningslinjen er skrevet for amerikanske føderale etater, men rådene om passord leses også utenfor forvaltningen, og det kan være dette dokumentet en sikkerhetsgransker har i tankene når de spør hvordan produktet ditt håndterer innlogging. Ingenting nedenfor er juridisk råd eller sikkerhetsråd, og ingenting her sier om produktet ditt oppfyller retningslinjen. Å følge den gjør ikke i seg selv et produkt sikkert. Det som følger, er hva teksten sier, forklart enkelt, med avsnittet lenket ved siden av hvert punkt. Hele teksten ligger på NISTs nettsted, som HTML og som PDF.
Lengde betyr mer enn regler om sammensetning
Retningslinjen ber om lange passord og forbyr de kjente reglene om å blande tegntyper.
Avsnitt 3.1.1.2, Password Verifiers, sier at et passord som brukes som eneste faktor, må ha minst 15 tegn. Et passord som brukes sammen med en annen faktor, kan være kortere, men minst åtte tegn. Det sier at største tillatte lengde bør være minst 64 tegn, og at “Verifiers and CSPs SHALL NOT impose other composition rules”. Det betyr ingen krav om stor bokstav, et siffer og et symbol.
Det samme avsnittet ber om at hele passordet sjekkes, ikke avkortes, og at passordbehandlere, autoutfylling og innliming er tillatt. Det utelukker også passordhint som noen som ikke er logget inn, kan se, og oppfordringer til å bruke kunnskapsbaserte spørsmål når man velger passord.
For en produktleder er dette ofte delen der produktets eget registreringsskjema og retningslinjen er uenige. Et skjema som avviser en lang frase av vanlige ord, eller som setter et lavt tak på lengden, ber om det motsatte av det teksten sier.
Ingen tvungne periodiske bytter
Retningslinjen ber tjenester slutte å tvinge folk til å bytte passord etter en tidsplan.
I avsnitt 3.1.1.2 er teksten tydelig: “Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically.” Unntaket er kompromittering. Et bytte må tvinges frem “if there is evidence that the authenticator has been compromised.”
Hvis produktet ditt fortsatt lar passord utløpe med noen måneders mellomrom, er det en policy noen valgte på et tidspunkt. Det er verdt å spørre hvem som eier det valget nå, og om det noen gang ble skrevet ned.
Sjekk av nye passord mot kjente lekkede passord
Når en person setter et passord, ber retningslinjen om at det sammenlignes med en liste over passord som ikke bør brukes.
Avsnitt 3.1.1.2 kaller dette en blokkeringsliste, en “that contains known commonly used, expected, or compromised passwords”, og ber om at hele passordet sammenlignes med den. Hvis passordet står på listen, blir personen bedt om å velge et annet.
Retningslinjen navngir ingen liste eller tjeneste for dette. Hvilken liste teamet ditt bruker, og hvordan den holdes oppdatert, er en beslutning for dem og for den som har ansvaret for sikkerhet i selskapet ditt.
En annen faktor
På retningslinjens mellomste sikkerhetsnivå er ikke et passord alene nok.
Avsnitt 2.2 beskriver Authentication Assurance Level 2. Under Permitted Authenticator Types skal autentisering på dette nivået “SHALL use either a multi-factor authenticator or a combination of two separate authentication factors.” Under Authenticator and Verifier Requirements legger den til at verifikatorer “SHALL offer at least one phishing-resistant authentication option at AAL2.”
Hvilket sikkerhetsnivå som passer produktet ditt, er ikke noe retningslinjen bestemmer for deg. Det er en vurdering av risikoen for at feil person kommer inn på en konto, og den hører hjemme hos dem som eier den risikoen.
Spørsmålene en leder kan stille teamet sitt
Du trenger ikke lese hele retningslinjen for å vite hvor du står. En kort samtale med teamet ditt forteller deg det meste.
Hva er minste og største passordlengde hos oss, og har vi regler om sammensetning? Sammenlign svaret med avsnitt 3.1.1.2. En kort maksimallengde eller en regel om symboler er raskt å finne.
Tvinger vi noen gang folk til å bytte passord etter en tidsplan? Hvis ja, spør hva den policyen beskytter mot, og om et tvunget bytte ved tegn på kompromittering ville dekke det.
Sjekker vi nye passord mot en blokkeringsliste? Spør hvilken liste, hvem som holder den oppdatert, og hva en person ser når valget deres blir avvist.
Kan brukerne våre slå på en annen faktor, og er ett av alternativene phishing-resistent? Spør også hvilke kontoer som bør være pålagt å bruke en.
Kan folk lime inn passord og bruke en passordbehandler i innloggingsskjemaet vårt? Retningslinjen ber om begge, og de er lette å ødelegge ved et uhell.
Hvilket sikkerhetsnivå har vi bestemt at vi arbeider etter, og hvor står det skrevet? Et uttalt mål lar teamet ditt si ja eller nei til et innloggingsdesign før det bygges.
Avklar disse én gang, så kan du løfte blikket fra innloggingsskjemaet og tilbake til produktet det beskytter.
Der vi kommer inn
Vi sertifiserer, reviderer eller vurderer ikke produkter mot NIST-retningslinjene, og vi lover ikke at det å følge dem gjør et produkt sikkert. Det vi kan gjøre, er å ta på oss innloggingsarbeidet du velger for produktet ditt, fra en høyere grense for passordlengde til en annen faktor.
Arbeidet havner i ditt eget kodelager. Koden vi bygger for deg, er din. Du bestemmer hva som leveres. Ingenting når brukerne dine uten din godkjenning.
Det starter med en samtale, helt uforpliktende. Hvordan sikkerhetsarbeid for produktet ditt ser ut før en kundes spørreskjema kommer, står i Harden security before the questionnaire arrives (på engelsk).
