Hva hashing av et passord faktisk beskytter deg mot

Kortversjonen

Hashing av et passord beskytter brukere når passorddatabasen din blir stjålet.

Det er hovedoppgaven. Ikke den eneste detaljen, ikke hele sikkerhetsmodellen, men den sentrale grunnen til at vi hasher passord i stedet for å lagre dem direkte.

Et riktig hashet passord er vanskelig å reversere. Hvis en angriper får en kopi av brukertabellen din, skal de ikke umiddelbart kunne se at Alices passord er Spring2026!. I stedet får de en lagret hash som krever tid, penger og maskinvare å teste mot gjetninger.

Den forskjellen er viktig. Passordhashing er ikke ment å gjøre innlogging sikker alene. Det stopper ikke phishing. Det stopper ikke noen fra å prøve lekkede passord mot innloggingsskjemaet ditt. Det beskytter ikke en sesjonscookie etter innlogging. Det kjøper tid og reduserer skade etter én svært spesifikk feil: lagringen av passordverifikatorer blir eksponert.

Hvis du forstår denne grensen, tar du bedre beslutninger om algoritmer, arbeidsfaktorer, tilbakestillinger, logging og hendelseshåndtering.

Hva en passordhash er

En passordhash er resultatet av en enveisfunksjon brukt på et passord, vanligvis med en unik salt og en bevisst treg passordhashing-algoritme.

Når en bruker oppretter en konto, bør systemet omtrent gjøre dette:

1. Motta passordet over HTTPS.
2. Generere en tilfeldig, unik salt.
3. Kjøre passordet og saltet gjennom en passordhashing-funksjon som Argon2id, bcrypt, scrypt eller PBKDF2.
4. Lagre algoritmenavnet, parameterne, saltet og den resulterende hashen.
5. Forkaste det opprinnelige passordet.

Når brukeren logger inn senere, gjentar systemet den samme hashing-prosessen med det innsendte passordet og de lagrede parameterne. Hvis den resulterende hashen matcher den lagrede hashen, lykkes innloggingen.

Det viktige er: applikasjonen trenger ikke å kjenne det opprinnelige passordet. Den trenger bare å verifisere at det innsendte passordet gir det forventede resultatet.

Derfor er lagring av passord med reverserbar kryptering vanligvis feil modell. Hvis applikasjonen din kan dekryptere hvert passord, kan også alle som stjeler dekrypteringsnøkkelen gjøre det samme. Passord bør normalt være umulige å verifisere baklengs, ikke bare skjult.

Hva hashing beskytter deg mot

1. Umiddelbar passordavsløring etter et databaseinnbrudd

Hvis en angriper stjeler en database som inneholder passord i klartekst, er skaden øyeblikkelig. Alle passord er eksponert. Brukerne er utsatt ikke bare på nettstedet ditt, men alle steder der de har gjenbrukt passordet.

Hvis databasen inneholder godt hashede passord, har angriperen mer arbeid å gjøre. De må gjette kandidatpassord, hashe hver gjetning med riktig salt og riktige parametere, og sammenligne resultatet.

For svake passord kan dette fortsatt gå raskt. For sterke unike passord kan det være upraktisk.

Hashing gjør en katastrofal avsløring om til et kappløp: kan brukerne tilbakestille passord, og kan du begrense hendelsen før angriperne knekker mange av dem?

Det er ikke perfekt. Det er fortsatt et innbrudd. Men det er en dramatisk bedre feilsituasjon.

2. Masseangrep mot hele brukerbasen din

Salter er en nøkkeldel av passordlagring fordi de hindrer angripere i å angripe mange brukere effektivt samtidig med forhåndsberegnede tabeller.

En salt er ikke hemmelig. Den lagres sammen med hashen. Jobben dens er unikhet.

Hvis to brukere velger det samme passordet, sørger unike salter for at de lagrede hashene deres blir forskjellige. Det hindrer angripere i å se med et blikk at mange brukere deler samme passord. Det hindrer også klassiske rainbow table-angrep, der angripere bruker enorme forhåndsberegnede lister over koblinger mellom passord og hash.

Uten salter kan én knekt hash avsløre alle brukere med samme passord. Med salter må hver passordgjetning testes separat for hver bruker.

3. Rask offline-gjetting

Når angripere har en passorddatabase, kan de gjette offline. Det betyr at hastighetsbegrensninger for innlogging, CAPTCHA, IP-blokkering og overvåking ikke lenger betyr noe. Angriperen kan teste gjetninger på sin egen maskinvare.

Det er her valg av algoritme betyr noe.

Generelle hashfunksjoner som SHA-256 og SHA-512 er laget for å være raske. Det er bra for filintegritet og digitale signaturer. Det er dårlig for passordlagring.

Passordhashing-algoritmer er laget for å være trege, justerbare og noen ganger minneharde. Argon2id, bcrypt, scrypt og PBKDF2 lar deg alle justere kostnadsparametere slik at hver gjetning tar meningsfull tid.

Argon2id er bredt anbefalt for nye systemer fordi den kan konfigureres til å kreve både CPU-tid og minne, noe som gjør GPU-knekking i stor skala dyrere. bcrypt er fortsatt vanlig og akseptabel når den er godt konfigurert, selv om den har begrensninger som håndtering av passordlengde. PBKDF2 brukes fortsatt i noen compliance-drevne miljøer, særlig der FIPS-validerte komponenter kreves.

Prinsippet er enkelt: gjør legitime innlogginger akseptabelt raske, samtidig som milliarder av gjetninger blir dyre.

Hva hashing ikke beskytter deg mot

1. Phishing

Hvis en bruker skriver passordet sitt inn på en falsk innloggingsside, hjelper ikke hashing på serveren din. Angriperen mottar passordet før systemet ditt noen gang ser det.

Forsvarene her er andre: flerfaktorautentisering, passnøkler, brukeropplæring, god domenehygiene, phishing-resistent autentisering og forsiktige flyter for passordtilbakestilling.

Passordhashing er et sikkerhetsnett for lagrede hemmeligheter. Det er ikke et forsvar mot at brukere lures til å gi fra seg disse hemmelighetene.

2. Credential stuffing

Credential stuffing skjer når angripere tar brukernavn- og passordpar som er lekket fra én tjeneste, og prøver dem på en annen.

Passordhashene dine kan være utmerkede, og credential stuffing kan fortsatt fungere hvis brukere gjenbruker passord.

Dette er et online-angrep mot innloggingsskjemaet ditt, ikke et offline-angrep mot databasen din. Du trenger hastighetsbegrensning, avviksdeteksjon, sjekk mot lekkede passord, MFA og fornuftige kontosperrepolicyer som ikke skaper enkle muligheter for tjenestenekt.

Den samme praktiske tenkningen gjelder alle eksponerte skjemaer. Hvis du gjennomgår autentiseringsflaten din, er det verdt å lese om hvorfor kontaktskjemaet ditt er din største spam-risiko; mekanismene er forskjellige, men lærdommen er lik: offentlige inndata trenger misbrukskontroller, ikke bare ryddig backend-kode.

3. Passord fanget i logger eller analyseverktøy

Hashing hjelper bare hvis klartekstpassordet forkastes raskt og aldri kopieres andre steder.

Vanlige feil inkluderer:

• Logging av hele forespørselskropper ved mislykkede innloggingsforsøk.
• Sending av passord til feilovervåkingsverktøy.
• Opptak av passordfelt i produkter for sesjonsavspilling.
• Inkludering av innloggingsopplysninger i URL-er under dårlig utformede tilbakestillings- eller migreringsflyter.
• Lagring av midlertidige klartekstpassord under importer.

Disse feilene omgår passordhashing fullstendig. Hvis klartekst havner i logger, sikkerhetskopier, datavarehus eller tredjepartsverktøy, er hashfunksjonen din irrelevant.

Behandle passordfelt som giftige data. Rediger dem bort før logging. Utelukk dem fra analyseverktøy. Hold dem ute av URL-er. Begrens hvem som kan få tilgang til produksjonsspor.

4. Dårlig sesjonssikkerhet

Etter innlogging mottar brukerens nettleser vanligvis en sesjonscookie eller et token. Hvis dette tokenet blir stjålet, trenger angriperen kanskje ikke passordet i det hele tatt.

Passordhashing beskytter ikke mot cross-site scripting, usikre cookies, session fixation, svak token-generering eller altfor lange sesjonslevetider.

Sesjonscookies fortjener sin egen gjennomgang: HttpOnly, Secure, passende SameSite, kortlivede høyrisiko-sesjoner og serverstyrt ugyldiggjøring ved passordendringer. Det bredere personvern- og nettleserlandskapet fortsetter også å endre seg, som omtalt i hva som endret seg for cookies i 2026.

5. Svak passordtilbakestilling og kontogjenoppretting

Mange kontoovertakelser starter ikke med passordet. De starter med tilbakestillingsflyten.

Hvis tilbakestillingstokener er forutsigbare, langlivede, lekket gjennom referrer-headere eller sendt til kompromitterte e-postkontoer, vil ikke passordhashing redde deg.

Bruk tilbakestillingstokener med høy entropi, korte utløpsvinduer, engangsbruk og tydelige brukervarsler. Siden e-post ofte er gjenopprettingskanalen, er grunnleggende domeneautentisering også viktig. Hvis teamet ditt behandler DNS-oppføringer som mystisk seremoni, start med en utviklervennlig gjennomgang av MX, SPF, DKIM og DMARC.

Algoritmevalget: hva du bør bruke nå

For nye applikasjoner, bruk Argon2id hvis plattformen din støtter det godt. Den er vinneren av Password Hashing Competition og er laget for passordlagring, inkludert motstand mot GPU-tung knekking.

Et rimelig moderne hierarki ser slik ut:

1. Argon2id for nye systemer der det er tilgjengelig.
2. bcrypt når Argon2id ikke er praktisk og bcrypt-støtten er moden.
3. scrypt når minnehard konfigurasjon er godt støttet.
4. PBKDF2 der det kreves av plattform- eller compliance-begrensninger.

Unngå vanlig SHA-256, SHA-512, MD5 eller en hjemmesnekret kombinasjon som sha256(password + salt). Raske hashfunksjoner er ikke funksjoner for passordlagring. Smarte, egendefinerte konstruksjoner er som regel dårligere enn kjedelige standardløsninger.

Unngå også å finne opp din egen passordpolicy rundt algoritmedetaljer. Brukere har ikke nytte av en sjekkliste med 12 regler for passordsammensetning hvis den skyver dem mot forutsigbare mønstre. Lengre unike passord, passordhåndterere, screening mot lekkede passord og MFA betyr vanligvis mer.

Kostnadsfaktorer er ikke sett-og-glem

Passordhashing har parametere. Argon2id har minne, iterasjoner og parallellisme. bcrypt har en kostnadsfaktor. PBKDF2 har et iterasjonstall.

Disse verdiene bør velges basert på produksjonsmiljøet ditt. For lave, og angripere gjetter billig. For høye, og innloggingssystemet ditt blir tregt eller sårbart for tjenestenekt.

Et praktisk mål ligger ofte i området fra titalls til noen få hundre millisekunder per passordverifisering på de faktiske serverne dine, avhengig av trafikk og risiko. Høysikkerhetssystemer kan velge mer. Systemer i forbrukerskala kan trenge nøye kapasitetsplanlegging.

Ikke kopier en kostnadsfaktor fra et fem år gammelt blogginnlegg. Maskinvare endrer seg. Biblioteker endrer seg. Trafikken din endrer seg.

Gjennomgå parametere jevnlig og planlegg for rehashing. Et vanlig mønster er å lagre algoritmen og parameterne sammen med hver hash. Ved vellykket innlogging, hvis de lagrede parameterne er utdaterte, hashes det innsendte passordet på nytt med den nyere konfigurasjonen, og posten oppdateres.

Peppers: nyttige, men ingen erstatning

En pepper er en hemmelig verdi som legges til passordhashing-prosessen og lagres separat fra databasen, ofte i en secrets manager eller hardware security module.

I motsetning til en salt må en pepper forbli hemmelig.

Peppers kan redusere skade hvis databasen lekker, men applikasjonshemmeligheter ikke gjør det. De er mest nyttige i modne miljøer med god nøkkelhåndtering. De er mindre nyttige hvis den samme angriperen kan stjele både databasen og applikasjonskonfigurasjonen.

Hvis du bruker en pepper, planlegg rotasjon nøye. Rotasjon kan kreve at brukere logger inn på nytt eller tilbakestiller passord, avhengig av designet. En pepper er et ekstra lag, ikke en grunn til å svekke de underliggende hashinnstillingene.

Den operative sjekklisten

Hvis du har ansvar for et ekte system, er den praktiske sjekklisten kort:

• Lagre passord bare med en standard passordhashing-algoritme.
• Bruk en unik tilfeldig salt per passord.
• Foretrekk Argon2id for nye bygg.
• Finjuster kostnadsparametere på produksjonslignende maskinvare.
• Lagre algoritme og parametere sammen med hver hash.
• Rehash ved innlogging når parametere blir utdaterte.
• Logg aldri passord eller send dem til analyseverktøy.
• Bruk TLS overalt der innloggingsopplysninger sendes inn.
• Legg til MFA eller passnøkler der risikoen tilsier det.
• Beskytt tilbakestillingsflyter like seriøst som innloggingsflyter.
• Ha en hendelsesplan for tvungne tilbakestillinger og varsling av brukere.

Passordhashing er ikke glamorøst. Det er rørleggerarbeid. Men det er den typen rørleggerarbeid som avgjør om et innbrudd blir en smertefull hendelse eller en katastrofe for alle brukere.

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

💡 Prøv dette: Se hvordan samme inndata tilordnes ulike algoritmer med Hash Generator, som gjør forskjellen mellom raske hasher og hasher på passordnivå konkret.

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

Den ærlige mentale modellen

Den beste måten å tenke på passordhashing på er denne:

Hashing beskytter ikke passordet mens brukeren skriver det. Det beskytter ikke kontoen etter at brukeren er logget inn. Det beskytter ikke brukere som gjenbruker passord på tvers av nettet.

Det beskytter den lagrede verifikatoren.

Det høres snevert ut, men det er ekstremt viktig. Databaser lekker. Sikkerhetskopier lekker. Staging-systemer blir kopiert. Leverandører får tilgang de ikke burde ha. Gamle eksporter blir liggende i objektlagring lenger enn noen husker.

Når det skjer, blir passordlagringsdesignet ditt forskjellen mellom at angripere mottar passord og at angripere mottar et dyrt gjetteproblem.

Det er dette hashing av et passord faktisk beskytter deg mot.