Det ærlige svaret er "det kommer an på hva du beskytter" — en forumpålogging og en kryptovaluta-lommebok har ikke samme risiko hvis de blir kompromittert, så de trenger ikke samme passordlengde. Denne artikkelen gir konkrete lengdemål etter kontotype, og forklarer hvorfor gjeldende veiledning favoriserer lengde fremfor sammensetningsregler som tvungne symboler.
Kort oppsummert
- NIST SP 800-63B anbefaler å tillate (og oppmuntre til) lange passord fremfor å håndheve kompleksitetsregler som tvungne symboler.
- 16 tegn er et rimelig standardvalg for de fleste kontoer; 20+ for alt som beskytter penger eller identitet; 24-32+ for hovedpassordet til en passordbehandler.
- Lengde øker beskyttelsen din eksponentielt; hver tvungne tegntype-regel legger til forholdsvis lite. Se Passordentropi forklart for matematikken.
- Lengde hjelper kun hvis tegnene er genuint tilfeldige — et langt, men forutsigbart passord (en setning, et tastaturmønster) får ikke full nytte.
Kort svar
Bruk minst 16 tegn for de fleste kontoer, 20+ for finansielle eller identitetskritiske kontoer, og 24-32+ for hovedpassordet til passordbehandleren din eller andre kritiske enkeltpunkter. PassGenerate lar deg stille inn lengden direkte og bruker 16 som standard, noe som dekker det vanlige tilfellet; øk den for kontoer med høyere innsats.
Anbefalt lengde etter kontotype
| Kontotype | Foreslått lengde | Hvorfor |
|---|---|---|
| Lavrisiko forum- eller nyhetsbrevkonto | 12-16 tegn | Lav konsekvens hvis kompromittert; likevel verdt å unngå trivielle gjetninger |
| E-post og skylagring | 16-20 tegn | E-post er ofte gjenopprettingsveien for alt annet — kompromittering her sprer seg videre |
| Bank og finansielle tjenester | 20-24 tegn | Direkte økonomisk eksponering; institusjoner håndhever uansett stadig lengre minimumskrav |
| Admin-kontoer, kryptolommebøker, hovedpassord for passordbehandler | 24-32+ tegn | Kritisk enkeltpunkt — kompromittering her kan eksponere alt nedstrøms |
| Huskbar passfrase (når du ofte må skrive den utenat) | 4-6 tilfeldige ord | Sammenlignbar eller bedre entropi enn et kortere symboltungt passord, lettere å skrive nøyaktig |
Hvorfor NIST beveget seg bort fra tvungne kompleksitetsregler
Eldre passordpolicyer — en tvungen stor bokstav, et tvunget siffer, et tvunget symbol, tvungen rotasjon hver 90. dag — var velmente, men slo tilbake i praksis. Tvungen kompleksitet dytter folk mot forutsigbare mønstre (Sommer2024!, Passord1@) som tilfredsstiller regelen samtidig som de tilfører lite reell entropi, og tvungen rotasjon dytter folk mot å øke et siffer (Passord1, Passord2) fremfor å velge noe genuint nytt.
NIST formaliserte denne endringen i SP 800-63B revisjon 4, publisert i 2025: tjenester må tillate passord på minst 64 tegn og må akseptere mellomrom og hele spekteret av utskrivbare tegn; hvis et passord er den eneste autentiseringsfaktoren, setter NIST nå et minimum på 15 tegn, som synker til 8 tegn når det kombineres med flerfaktorautentisering. Revisjon 4 går lenger enn tidligere veiledning ved eksplisitt å forby tvungne sammensetningsregler (påkrevd store bokstaver, sifre, symboler) fremfor bare å fraråde dem, og den pålegger tjenester å sjekke nye passord mot lister over lekkede passord i stedet. Den fjerner også tvungen periodisk rotasjon helt — passord bør endres når det finnes faktiske bevis på kompromittering, ikke etter en fast kalender. Sikkerhetsspaken som faktisk fungerer, er lengde kombinert med genuin tilfeldighet, ikke en sjekkliste over påkrevde tegntyper.
Garanterer lengde alene sikkerhet?
Nei — lengde hjelper kun hvis den kommer sammen med ekte tilfeldighet. aaaaaaaaaaaaaaaaaaaa (20 tegn) er trivielt å gjette til tross for lengden, og en setning på 20 tegn hentet fra en kjent bok kan gjettes via ordboksangrep bygget på vanlige fraser. Lengdeanbefalingene ovenfor forutsetter at tegnene genereres av en kryptografisk sikker pseudotilfeldig tallgenerator (CSPRNG), slik PassGenerate gjør det, eller hentet fra en genuint tilfeldig ordliste for passfraser — ikke valgt for å være huskbare, noe som nesten alltid betyr mindre tilfeldig enn det ser ut til.
En praktisk måte å anvende dette på
Du trenger ikke å beregne entropi for hånd hver gang. Som en tommelfingerregel:
- Spør deg selv hva som skjer hvis akkurat denne kontoen blir kompromittert — er det irriterende, eller er det en kaskadeeffekt av katastrofer?
- Velg en lengde fra tabellen ovenfor basert på det svaret.
- Generer den tilfeldig fremfor å sette den sammen selv — lengde lønner seg kun med ekte tilfeldighet bak seg.
- For kontoer du ofte må skrive utenat, bruk en tilfeldig passfrase i stedet for en tilfeldig tegnstreng — sammenlignbar sikkerhet, merkbart lettere å skrive riktig.
De viktigste poengene
- Passordlengde bør skaleres etter hva som faktisk står på spill hvis kontoen blir kompromittert, ikke være ett fast tall for alt.
- NIST SP 800-63B favoriserer lengre minimumskrav og sjekk mot lekkasjelister fremfor tvungne tegnsammensetningsregler.
- Lengde alene er ikke tilstrekkelig — den må kombineres med genuin tilfeldighet (CSPRNG-generert eller en tilfeldig ordliste) for å levere sikkerheten den antyder.
- 16 tegn dekker de fleste hverdagskontoer; gå til 24-32+ spesifikt for hovedpassordet til passordbehandleren din.
Hvorfor du kan stole på PassGenerate
- Passord genereres lokalt i nettleseren din ved hjelp av Web Crypto API.
- Ingen passord overføres til servere.
- Bruker en kryptografisk sikker pseudotilfeldig tallgenerator (CSPRNG).
- Følger moderne beste praksis for sikkerhet, anbefalt av NIST og OWASP.
Kilder
- NIST SP 800-63B revisjon 4 (2025) – Digital Identity Guidelines
- OWASP Authentication Cheat Sheet
- CISA Password Guidance
Konklusjon
Det finnes ikke én riktig passordlengde — det finnes en riktig lengde for hver kontos risikonivå. Seksten tegn er et rimelig minimum for de fleste kontoer, finansielle og identitetskritiske kontoer fortjener 20+, og alt som fungerer som et kritisk enkeltpunkt (spesielt hovedpassordet til en passordbehandler) fortjener 24-32 eller mer. Ingenting av dette betyr noe, derimot, med mindre tegnene faktisk er tilfeldige — lengde er multiplikatoren, men tilfeldighet er det den multipliserer.