Vad hashning av ett lösenord faktiskt skyddar dig mot

Den korta versionen

Hashning av ett lösenord skyddar användare när din lösenordsdatabas blir stulen.

Det är huvuduppgiften. Inte den enda detaljen, inte hela säkerhetsmodellen, men den centrala anledningen till att vi hashar lösenord i stället för att lagra dem direkt.

Ett korrekt hashat lösenord är svårt att återskapa. Om en angripare får en kopia av din användartabell ska de inte omedelbart kunna se att Alices lösenord är Spring2026!. I stället får de en lagrad hash som kräver tid, pengar och hårdvara för att testas mot gissningar.

Den skillnaden spelar roll. Lösenordshashning är inte avsett att göra inloggning säker på egen hand. Det stoppar inte phishing. Det stoppar inte någon från att prova läckta lösenord mot ditt inloggningsformulär. Det skyddar inte en sessionscookie efter inloggning. Det köper tid och minskar skadan efter ett mycket specifikt fel: lagringen av dina lösenordsverifierare blir exponerad.

Om du förstår den gränsen fattar du bättre beslut om algoritmer, arbetsfaktorer, återställningar, loggning och incidenthantering.

Vad en lösenordshash är

En lösenordshash är resultatet av en envägsfunktion som tillämpas på ett lösenord, vanligtvis med ett unikt salt och en avsiktligt långsam lösenordshashningsalgoritm.

När en användare skapar ett konto bör systemet ungefär göra detta:

1. Ta emot lösenordet över HTTPS.
2. Generera ett slumpmässigt, unikt salt.
3. Köra lösenordet och saltet genom en lösenordshashningsfunktion som Argon2id, bcrypt, scrypt eller PBKDF2.
4. Lagra algoritmens namn, parametrar, salt och den resulterande hashen.
5. Kasta det ursprungliga lösenordet.

När användaren senare loggar in upprepar systemet samma hashning med det inskickade lösenordet och de lagrade parametrarna. Om den resulterande hashen matchar den lagrade hashen lyckas inloggningen.

Det viktiga: applikationen behöver inte känna till det ursprungliga lösenordet. Den behöver bara verifiera att det inskickade lösenordet ger det förväntade resultatet.

Det är därför lagring av lösenord med reversibel kryptering oftast är fel modell. Om din applikation kan dekryptera varje lösenord kan alla som stjäl dekrypteringsnyckeln göra samma sak. Lösenord bör normalt vara omöjliga att verifiera baklänges, inte bara dolda.

Vad hashning skyddar dig mot

1. Omedelbart avslöjande av lösenord efter ett databasintrång

Om en angripare stjäl en databas som innehåller lösenord i klartext är skadan omedelbar. Varje lösenord är exponerat. Användare är i riskzonen inte bara på din webbplats, utan överallt där de har återanvänt samma lösenord.

Om databasen innehåller välhashade lösenord har angriparen mer arbete att göra. De måste gissa möjliga lösenord, hasha varje gissning med rätt salt och parametrar och jämföra resultatet.

För svaga lösenord kan detta fortfarande gå snabbt. För starka unika lösenord kan det vara opraktiskt.

Hashning förvandlar ett katastrofalt avslöjande till ett lopp: hinner användare återställa lösenord och hinner du begränsa incidenten innan angripare knäcker många av dem?

Det är inte perfekt. Det är fortfarande ett intrång. Men det är ett dramatiskt bättre felläge.

2. Massattacker mot hela din användarbas

Salter är en central del av lösenordslagring eftersom de hindrar angripare från att effektivt attackera många användare samtidigt med förberäknade tabeller.

Ett salt är inte hemligt. Det lagras tillsammans med hashen. Dess uppgift är unikhet.

Om två användare väljer samma lösenord ser unika salter till att deras lagrade hashar skiljer sig åt. Det hindrar angripare från att direkt se att många användare delar samma lösenord. Det förhindrar också klassiska rainbow table-attacker, där angripare använder enorma förberäknade listor med mappningar från lösenord till hash.

Utan salter kan en knäckt hash avslöja varje användare med samma lösenord. Med salter måste varje lösenordsgissning testas separat för varje användare.

3. Snabb offlinegissning

När angripare väl har en lösenordsdatabas kan de gissa offline. Det betyder att dina hastighetsbegränsningar för inloggning, CAPTCHA, IP-blockering och övervakning inte längre spelar någon roll. Angriparen kan testa gissningar på sin egen hårdvara.

Det är här algoritmvalet spelar roll.

Generella hashfunktioner som SHA-256 och SHA-512 är utformade för att vara snabba. Det är bra för filintegritet och digitala signaturer. Det är dåligt för lösenordslagring.

Lösenordshashningsalgoritmer är utformade för att vara långsamma, justerbara och ibland minneshårda. Argon2id, bcrypt, scrypt och PBKDF2 låter dig alla justera kostnadsparametrar så att varje gissning tar meningsfull tid.

Argon2id rekommenderas brett för nya system eftersom den kan konfigureras för att kräva både CPU-tid och minne, vilket gör storskalig GPU-knäckning dyrare. bcrypt är fortfarande vanlig och acceptabel när den är välkonfigurerad, även om den har begränsningar som hantering av lösenordslängd. PBKDF2 används fortfarande i vissa compliance-drivna miljöer, särskilt där FIPS-validerade komponenter krävs.

Principen är enkel: gör legitima inloggningar acceptabelt snabba, samtidigt som miljarder gissningar blir dyra.

Vad hashning inte skyddar dig mot

1. Phishing

Om en användare skriver sitt lösenord på en falsk inloggningssida hjälper inte hashning på din server. Angriparen tar emot lösenordet innan ditt system någonsin ser det.

Försvaren här är andra: multifaktorautentisering, passkeys, användarutbildning, domänhygien, phishingresistent autentisering och noggrant utformade flöden för lösenordsåterställning.

Lösenordshashning är ett skyddsnät för lagrade hemligheter. Det är inte ett försvar mot att användare luras att lämna ifrån sig dessa hemligheter.

2. Credential stuffing

Credential stuffing sker när angripare tar användarnamn och lösenord som har läckt från en tjänst och provar dem på en annan.

Dina lösenordshashar kan vara utmärkta, och credential stuffing kan ändå fungera om användare återanvänder lösenord.

Detta är en onlineattack mot ditt inloggningsformulär, inte en offlineattack mot din databas. Du behöver hastighetsbegränsning, avvikelsedetektering, kontroller mot läckta lösenord, MFA och rimliga låsningspolicyer som inte skapar enkla möjligheter till överbelastningsattacker.

Samma praktiska tänkande gäller alla exponerade formulär. Om du granskar din autentiseringsyta är det värt att läsa om varför ditt kontaktformulär är din största spamrisk; mekaniken skiljer sig åt, men lärdomen är liknande: publika inmatningar behöver skydd mot missbruk, inte bara ren backendkod.

3. Lösenord som fångas i loggar eller analysverktyg

Hashning hjälper bara om lösenordet i klartext snabbt kastas och aldrig kopieras någon annanstans.

Vanliga misstag är:

• Att logga fullständiga begäranskroppar vid misslyckade inloggningsförsök.
• Att skicka lösenord till verktyg för felövervakning.
• Att fånga lösenordsfält i produkter för sessionsuppspelning.
• Att inkludera inloggningsuppgifter i URL:er under dåligt utformade återställnings- eller migreringsflöden.
• Att lagra tillfälliga lösenord i klartext under importer.

Dessa misstag kringgår lösenordshashning helt. Om klartext hamnar i loggar, säkerhetskopior, datalager eller tredjepartsverktyg är din hashfunktion irrelevant.

Behandla lösenordsfält som giftiga data. Maskera dem innan loggning. Exkludera dem från analysverktyg. Håll dem borta från URL:er. Begränsa vem som kan komma åt produktionsspårningar.

4. Dålig sessionssäkerhet

Efter inloggning får användarens webbläsare vanligtvis en sessionscookie eller token. Om den token stjäls kanske angriparen inte behöver lösenordet alls.

Lösenordshashning skyddar inte mot cross-site scripting, osäkra cookies, session fixation, svag tokengenerering eller alltför långa sessionslivslängder.

Sessionscookies förtjänar en egen granskning: HttpOnly, Secure, lämplig SameSite, kortlivade högrisksessioner och ogiltigförklaring på serversidan vid lösenordsändringar. Det bredare integritets- och webbläsarlandskapet fortsätter också att förändras, vilket beskrivs i vad som förändrades för cookies 2026.

5. Svag lösenordsåterställning och kontoåtervinning

Många kontoövertaganden börjar inte med lösenordet. De börjar med återställningsflödet.

Om återställningstokens är förutsägbara, långlivade, läcker genom Referer-headers eller skickas till komprometterade e-postkonton kommer lösenordshashning inte att rädda dig.

Använd återställningstokens med hög entropi, korta utgångstider, engångsanvändning och tydliga användaraviseringar. Eftersom e-post ofta är återställningskanalen spelar grundläggande domänautentisering också roll. Om ditt team behandlar DNS-poster som mystiska ceremonier, börja med en utvecklarvänlig rundtur i MX, SPF, DKIM och DMARC.

Algoritmvalet: vad du bör använda nu

För nya applikationer, använd Argon2id om din plattform har bra stöd för det. Den vann Password Hashing Competition och är utformad för lösenordslagring, inklusive motståndskraft mot GPU-tung knäckning.

En rimlig modern hierarki ser ut så här:

1. Argon2id för nya system där den finns tillgänglig.
2. bcrypt när Argon2id inte är praktiskt och stödet för bcrypt är moget.
3. scrypt när minneshård konfiguration stöds väl.
4. PBKDF2 där plattform eller compliance-krav kräver det.

Undvik ren SHA-256, SHA-512, MD5 eller en hemmabyggd kombination som sha256(password + salt). Snabba hashfunktioner är inte funktioner för lösenordslagring. Smarta egenkonstruerade lösningar tenderar att vara sämre än tråkiga standardlösningar.

Undvik också att uppfinna en egen lösenordspolicy kring algoritmdetaljer. Användare gynnas inte av en checklista med 12 regler för lösenordssammansättning om den driver dem mot förutsägbara mönster. Längre unika lösenord, lösenordshanterare, screening mot läckta lösenord och MFA spelar oftast större roll.

Kostnadsfaktorer är inte något man ställer in och glömmer

Lösenordshashning har parametrar. Argon2id har minne, iterationer och parallellism. bcrypt har en kostnadsfaktor. PBKDF2 har ett iterationsantal.

Dessa värden bör väljas utifrån din produktionsmiljö. För låga, och angripare gissar billigt. För höga, och ditt inloggningssystem blir långsamt eller sårbart för överbelastningsattacker.

Ett praktiskt mål ligger ofta i intervallet tiotals till några hundra millisekunder per lösenordsverifiering på dina faktiska servrar, beroende på trafik och risk. Högsäkerhetssystem kan välja mer. System i konsumentskala kan behöva noggrann kapacitetsplanering.

Kopiera inte en kostnadsfaktor från ett fem år gammalt blogginlägg. Hårdvara förändras. Bibliotek förändras. Din trafik förändras.

Granska parametrar regelbundet och planera för omhashning. Ett vanligt mönster är att lagra algoritmen och parametrarna med varje hash. Vid lyckad inloggning, om de lagrade parametrarna är föråldrade, hasha om det inskickade lösenordet med den nyare konfigurationen och uppdatera posten.

Peppers: användbara, men ingen ersättning

En pepper är ett hemligt värde som läggs till i lösenordshashningsprocessen och lagras separat från databasen, ofta i en secrets manager eller hardware security module.

Till skillnad från ett salt måste en pepper förbli hemlig.

Peppers kan minska skadan om databasen läcker men applikationshemligheterna inte gör det. De är mest användbara i mogna miljöer med god nyckelhantering. De är mindre användbara om samma angripare kan stjäla både databasen och applikationskonfigurationen.

Om du använder en pepper, planera rotation noggrant. Att rotera den kan kräva att användare loggar in igen eller återställer lösenord, beroende på designen. En pepper är ett extra lager, inte ett skäl att försvaga de underliggande hashinställningarna.

Den operativa checklistan

Om du ansvarar för ett verkligt system är den praktiska checklistan kort:

• Lagra lösenord endast med en standardiserad lösenordshashningsalgoritm.
• Använd ett unikt slumpmässigt salt per lösenord.
• Föredra Argon2id för nya byggen.
• Finjustera kostnadsparametrar på produktionslik hårdvara.
• Lagra algoritm och parametrar med varje hash.
• Hasha om vid inloggning när parametrar blir föråldrade.
• Logga aldrig lösenord och skicka dem aldrig till analysverktyg.
• Använd TLS överallt där inloggningsuppgifter skickas.
• Lägg till MFA eller passkeys där risken motiverar det.
• Skydda återställningsflöden lika seriöst som inloggningsflöden.
• Ha en incidentplan för tvingade återställningar och användaravisering.

Lösenordshashning är inte glamoröst. Det är rördragning. Men det är den typ av rördragning som avgör om ett intrång blir en smärtsam incident eller en katastrof för hela användarbasen.

<!-- tool-cta:start -->

💡 Prova detta: Se hur samma indata mappas till olika algoritmer med Hash Generator, som gör skillnaden mellan snabba hashar och hashar på lösenordsnivå konkret.

<!-- tool-cta:end -->

Den ärliga mentala modellen

Det bästa sättet att tänka på lösenordshashning är detta:

Hashning skyddar inte lösenordet medan användaren skriver det. Det skyddar inte kontot efter att användaren har loggat in. Det skyddar inte användare som återanvänder lösenord på webben.

Det skyddar den lagrade verifieraren.

Det låter snävt, men det är oerhört viktigt. Databaser läcker. Säkerhetskopior läcker. Staging-system kopieras. Leverantörer får åtkomst de inte borde ha. Gamla exporter ligger kvar i objektlagring längre än någon minns.

När det händer blir din design för lösenordslagring skillnaden mellan att angripare får lösenord och att angripare får ett dyrt gissningsproblem.

Det är vad hashning av ett lösenord faktiskt skyddar dig mot.