← Back to Blog

Hur långt ska ett lösenord vara? En praktisk längdguide efter kontotyp

2025-12-26

Det ärliga svaret är "det beror på vad du skyddar" — ett forumkonto och en kryptoplånbok bär inte samma risk om de komprometteras, så de behöver inte samma lösenordslängd. Den här artikeln ger konkreta längdmål efter kontotyp och förklarar varför nuvarande riktlinjer prioriterar längd framför sammansättningsregler som obligatoriska symboler.

Kort sagt

  • NIST SP 800-63B rekommenderar att tillåta (och uppmuntra) långa lösenord istället för att tvinga fram komplexitetsregler som obligatoriska symboler.
  • 16 tecken är ett rimligt standardvärde för de flesta konton; 20+ för allt som skyddar pengar eller identitet; 24-32+ för huvudlösenordet till din lösenordshanterare.
  • Längd ökar ditt skydd exponentiellt; varje obligatorisk teckentypsregel bidrar jämförelsevis lite. Se Lösenordsentropi förklarat för matematiken.
  • Längd hjälper bara om tecknen är genuint slumpmässiga — ett långt men förutsägbart lösenord (en mening, ett tangentbordsmönster) får inte hela fördelen.

Kort svar

Använd minst 16 tecken för de flesta konton, 20+ för finansiella eller identitetskritiska konton, och 24-32+ för huvudlösenordet till din lösenordshanterare eller någon annan enskild felpunkt. PassGenerate låter dig ställa in längden direkt och använder 16 som standard, vilket täcker det vanliga fallet; öka den för konton med högre risk.

Rekommenderad längd efter kontotyp

KontotypFöreslagen längdVarför
Lågriskforum eller nyhetsbrevskonto12-16 teckenLåg konsekvens vid komprometterande; ändå värt att undvika triviala gissningar
E-post och molnlagring16-20 teckenE-post är ofta återställningsvägen för allt annat — dess komprometterande får kaskadeffekt
Bank och finansiella tjänster20-24 teckenDirekt ekonomisk exponering; institutioner kräver ändå allt längre minimum
Administratörskonton, kryptoplånböcker, huvudlösenord för hanteraren24-32+ teckenEnskild felpunkt — dess komprometterande kan blottlägga allt som är beroende av den
Minnesvärd lösenfras (när du ofta måste skriva den utantill)4-6 slumpmässiga ordJämförbar eller bättre entropi än ett kortare, symboltungt lösenord, lättare att skriva korrekt

Varför NIST rört sig bort från påtvingade komplexitetsregler

Äldre lösenordspolicyer — en obligatorisk versal, en obligatorisk siffra, en obligatorisk symbol, obligatorisk rotation var 90:e dag — var välmenande men gav motsatt effekt i praktiken. Påtvingad komplexitet driver människor mot förutsägbara mönster (Sommar2024!, Losenord1@) som uppfyller regeln men tillför liten verklig entropi, och påtvingad rotation driver människor att öka en siffra (Losenord1, Losenord2) istället för att välja något genuint nytt.

NIST formaliserade denna förändring i SP 800-63B revision 4, publicerad 2025: tjänster måste tillåta lösenord på minst 64 tecken och måste acceptera mellanslag och hela intervallet av utskrivbara tecken; om ett lösenord är den enda autentiseringsfaktorn sätter NIST nu ett minimum på 15 tecken, som sjunker till 8 tecken när det kombineras med multifaktorautentisering. Revision 4 går längre än tidigare riktlinjer genom att uttryckligen förbjuda obligatoriska sammansättningsregler (krav på versaler, siffror, symboler) istället för att bara avråda från dem, och anvisar tjänster att istället kontrollera nya lösenord mot listor över läckta lösenord. Den slopar också obligatorisk periodisk rotation helt — lösenord bör bytas när det finns faktiska bevis för komprometterande, inte enligt en fast kalender. Säkerhetsspaken som faktiskt fungerar är längd kombinerat med genuin slumpmässighet, inte en checklista med krävda teckentyper.

Garanterar längd ensamt säkerhet?

Nej — längd hjälper bara om det åtföljs av verklig slumpmässighet. aaaaaaaaaaaaaaaaaaaa (20 tecken) är trivialt att gissa trots sin längd, och en 20 tecken lång mening hämtad från en välkänd bok är gissningsbar via ordboksattacker byggda på vanliga fraser. Längdrekommendationerna ovan förutsätter att tecknen genereras av en kryptografiskt säker pseudoslumptalsgenerator (CSPRNG), på det sätt PassGenerate gör det, eller för lösenfraser hämtas från en genuint slumpmässig ordlista — inte valda för att vara minnesvärda, vilket nästan alltid innebär mindre slumpmässighet än det verkar.

Ett praktiskt sätt att tillämpa detta

Du behöver inte räkna ut entropin för hand varje gång. Som en praktisk regel:

  1. Fråga dig själv vad som händer om just detta konto komprometteras — är det besvärligt, eller är det en kaskadkatastrof?
  2. Välj en längd från tabellen ovan baserat på det svaret.
  3. Generera det slumpmässigt istället för att komponera det själv — längd lönar sig bara med genuin slumpmässighet bakom.
  4. För konton du ofta måste skriva utantill, använd en slumpmässig lösenfras istället för en slumpmässig teckensträng — jämförbar säkerhet, betydligt lättare att skriva rätt.

Viktiga slutsatser

  • Lösenordslängden bör anpassas efter vad som faktiskt står på spel om kontot komprometteras, inte vara ett enda fast tal för allt.
  • NIST SP 800-63B föredrar längre minimum och kontroll mot läckagelistor framför obligatoriska teckensammansättningsregler.
  • Längd ensamt räcker inte — det måste kombineras med genuin slumpmässighet (genererad av CSPRNG eller en slumpmässig ordlista) för att leverera den säkerhet det utlovar.
  • 16 tecken täcker de flesta vardagliga konton; gå upp till 24-32+ specifikt för huvudlösenordet till din lösenordshanterare.

Varför du kan lita på PassGenerate

  • Lösenord genereras lokalt i din webbläsare med hjälp av Web Crypto API.
  • Inga lösenord skickas till servrar.
  • Använder en kryptografiskt säker pseudoslumptalsgenerator (CSPRNG).
  • Följer moderna säkerhetsrekommendationer från NIST och OWASP.

Källor

  • NIST SP 800-63B revision 4 (2025) – Digital Identity Guidelines
  • OWASP Authentication Cheat Sheet
  • CISA Password Guidance

Slutsats

Det finns ingen enskilt korrekt lösenordslängd — det finns en korrekt längd för varje kontos risknivå. Sexton tecken är ett rimligt golv för de flesta konton, finansiella och identitetskritiska konton förtjänar 20+, och allt som fungerar som en enskild felpunkt (särskilt huvudlösenordet till en lösenordshanterare) förtjänar 24-32 eller mer. Inget av detta spelar dock någon roll om inte tecknen faktiskt är slumpmässiga — längd är multiplikatorn, men slumpmässighet är det som multipliceras.