Hvad hashing af en adgangskode faktisk beskytter dig imod

Den korte version

Hashing af en adgangskode beskytter brugere, når din adgangskodedatabase bliver stjålet.

Det er hovedopgaven. Ikke den eneste detalje, ikke hele sikkerhedsmodellen, men den centrale grund til, at vi hasher adgangskoder i stedet for at gemme dem direkte.

En korrekt hashet adgangskode er vanskelig at vende tilbage til sin oprindelige form. Hvis en angriber får en kopi af din brugertabel, bør de ikke straks kunne se, at Alices adgangskode er Spring2026!. I stedet får de en gemt hash, som kræver tid, penge og hardware at teste mod gæt.

Den forskel er vigtig. Password hashing er ikke beregnet til at gøre login sikkert i sig selv. Det stopper ikke phishing. Det stopper ikke nogen i at prøve lækkede adgangskoder mod din loginformular. Det beskytter ikke en sessionscookie efter login. Det køber tid og reducerer skade efter en meget specifik fejl: dit lager for adgangskodeverifikatorer bliver eksponeret.

Hvis du forstår den grænse, vil du træffe bedre beslutninger om algoritmer, work factors, nulstillinger, logging og incident response.

Hvad en adgangskodehash er

En adgangskodehash er outputtet fra en envejsfunktion anvendt på en adgangskode, normalt med et unikt salt og en bevidst langsom password-hashing-algoritme.

Når en bruger opretter en konto, bør systemet omtrent gøre dette:

1. Modtage adgangskoden over HTTPS.
2. Generere et tilfældigt, unikt salt.
3. Køre adgangskoden og saltet gennem en password-hashing-funktion såsom Argon2id, bcrypt, scrypt eller PBKDF2.
4. Gemme algoritmenavnet, parametre, salt og den resulterende hash.
5. Kassere den oprindelige adgangskode.

Når brugeren logger ind senere, gentager systemet den samme hashingproces med den indsendte adgangskode og de gemte parametre. Hvis den resulterende hash matcher den gemte hash, lykkes login.

Det vigtige er: applikationen behøver ikke at kende den oprindelige adgangskode. Den skal kun verificere, at den indsendte adgangskode producerer det forventede resultat.

Derfor er lagring af adgangskoder med reversibel kryptering som regel den forkerte model. Hvis din applikation kan dekryptere alle adgangskoder, kan enhver, der stjæler dekrypteringsnøglen, gøre det samme. Adgangskoder bør normalt være umulige at verificere baglæns, ikke blot skjulte.

Hvad hashing beskytter dig imod

1. Øjeblikkelig afsløring af adgangskoder efter et databasebrud

Hvis en angriber stjæler en database med adgangskoder i klartekst, er skaden øjeblikkelig. Alle adgangskoder er eksponeret. Brugere er i risiko ikke kun på dit site, men alle steder hvor de har genbrugt adgangskoden.

Hvis databasen indeholder velhashende adgangskoder, har angriberen mere arbejde at gøre. De skal gætte kandidatadgangskoder, hashe hvert gæt med det korrekte salt og de korrekte parametre og sammenligne resultatet.

For svage adgangskoder kan dette stadig være hurtigt. For stærke unikke adgangskoder kan det være upraktisk.

Hashing forvandler en katastrofal afsløring til et kapløb: kan brugerne nulstille adgangskoder, og kan du inddæmme hændelsen, før angribere knækker mange af dem?

Det er ikke perfekt. Det er stadig et brud. Men det er en dramatisk bedre fejltilstand.

2. Masseangreb mod hele din brugerbase

Salts er en central del af adgangskodelagring, fordi de forhindrer angribere i effektivt at angribe mange brugere på én gang med præberegnede tabeller.

Et salt er ikke hemmeligt. Det gemmes sammen med hashen. Dets opgave er unikhed.

Hvis to brugere vælger den samme adgangskode, sikrer unikke salts, at deres gemte hashes er forskellige. Det forhindrer angribere i med et hurtigt blik at se, at mange brugere deler den samme adgangskode. Det forhindrer også klassiske rainbow table-angreb, hvor angribere bruger enorme præberegnede lister over mappings fra adgangskode til hash.

Uden salts kan én knækket hash afsløre alle brugere med den samme adgangskode. Med salts skal hvert adgangskodegæt testes separat for hver bruger.

3. Hurtig offline-gætning

Når angribere har en adgangskodedatabase, kan de gætte offline. Det betyder, at dine login-rate limits, CAPTCHA, IP-blokering og overvågning ikke længere betyder noget. Angriberen kan teste gæt på sin egen hardware.

Det er her, valg af algoritme betyder noget.

Generelle hashes som SHA-256 og SHA-512 er designet til at være hurtige. Det er godt til filintegritet og digitale signaturer. Det er dårligt til adgangskodelagring.

Password-hashing-algoritmer er designet til at være langsomme, justerbare og nogle gange memory-hard. Argon2id, bcrypt, scrypt og PBKDF2 lader dig alle justere cost-parametre, så hvert gæt tager meningsfuld tid.

Argon2id anbefales bredt til nye systemer, fordi den kan konfigureres til at kræve både CPU-tid og hukommelse, hvilket gør cracking i stor skala med GPU dyrere. bcrypt er fortsat almindelig og acceptabel, når den konfigureres godt, selvom den har begrænsninger såsom håndtering af adgangskodelængde. PBKDF2 bruges stadig i nogle compliance-drevne miljøer, især hvor FIPS-validerede komponenter er påkrævet.

Princippet er enkelt: gør legitime logins acceptabelt hurtige, mens milliarder af gæt bliver dyre.

Hvad hashing ikke beskytter dig imod

1. Phishing

Hvis en bruger indtaster sin adgangskode på en falsk login-side, hjælper hashing på din server ikke. Angriberen modtager adgangskoden, før dit system nogensinde ser den.

Forsvarene her er anderledes: multifaktorgodkendelse, passkeys, brugeruddannelse, domænehygiejne, phishing-resistent godkendelse og omhyggelige flows til nulstilling af adgangskoder.

Password hashing er en sidste skanse for lagrede hemmeligheder. Det er ikke et forsvar mod, at brugere bliver narret til at opgive disse hemmeligheder.

2. Credential stuffing

Credential stuffing sker, når angribere tager brugernavn- og adgangskodepar lækket fra én tjeneste og prøver dem på en anden.

Dine adgangskodehashes kan være fremragende, og credential stuffing kan stadig virke, hvis brugere genbruger adgangskoder.

Dette er et onlineangreb mod din loginformular, ikke et offlineangreb mod din database. Du har brug for rate limiting, anomalidetektion, kontrol mod kendt lækkede adgangskoder, MFA og fornuftige lockout-politikker, som ikke skaber lette muligheder for denial-of-service.

Den samme praktiske tankegang gælder for enhver eksponeret formular. Hvis du gennemgår din autentificeringsflade, er det værd at læse om, hvorfor din kontaktformular er din største spam-risiko; mekanikken er forskellig, men læren er den samme: offentlige inputs har brug for misbrugskontrol, ikke kun ren backend-kode.

3. Adgangskoder fanget i logs eller analytics

Hashing hjælper kun, hvis adgangskoden i klartekst hurtigt kasseres og aldrig kopieres andre steder hen.

Almindelige fejl omfatter:

• Logging af fulde request bodies ved mislykkede loginforsøg.
• At sende adgangskoder til værktøjer til fejlovervågning.
• At opsamle adgangskodefelter i session replay-produkter.
• At inkludere credentials i URLs under dårligt designede nulstillings- eller migreringsflows.
• At gemme midlertidige adgangskoder i klartekst under importer.

Disse fejl omgår password hashing fuldstændigt. Hvis klartekst ender i logs, backups, data warehouses eller tredjepartsværktøjer, er din hashfunktion irrelevant.

Behandl adgangskodefelter som giftige data. Rediger dem væk før logging. Udeluk dem fra analytics. Hold dem ude af URLs. Begræns, hvem der kan tilgå produktionstraces.

4. Dårlig sessionssikkerhed

Efter login modtager brugerens browser som regel en sessionscookie eller token. Hvis den token bliver stjålet, behøver angriberen måske slet ikke adgangskoden.

Password hashing beskytter ikke mod cross-site scripting, usikre cookies, session fixation, svag tokengenerering eller alt for lange sessionslevetider.

Sessionscookies fortjener deres egen gennemgang: HttpOnly, Secure, passende SameSite, kortlivede højrisikosessioner og server-side invalidering ved ændringer af adgangskoder. Det bredere privatlivs- og browserlandskab bliver også ved med at flytte sig, som beskrevet i hvad der ændrede sig for cookies i 2026.

5. Svag nulstilling af adgangskoder og kontogendannelse

Mange kontoovertagelser starter ikke med adgangskoden. De starter med nulstillingsflowet.

Hvis nulstillingstokens er forudsigelige, langlivede, lækket gennem referrer-headers eller sendt til kompromitterede emailkonti, vil password hashing ikke redde dig.

Brug reset tokens med høj entropi, korte udløbsvinduer, engangsbrug og tydelige brugernotifikationer. Da email ofte er gendannelseskanalen, betyder grundlæggende domæneautentificering også noget. Hvis dit team behandler DNS records som et mystisk ritual, så begynd med en udviklervenlig gennemgang af MX, SPF, DKIM og DMARC.

Algoritmevalget: hvad du bør bruge nu

Til nye applikationer bør du bruge Argon2id, hvis din platform understøtter den godt. Den er vinderen af Password Hashing Competition og er designet til adgangskodelagring, inklusive modstandsdygtighed mod GPU-tung cracking.

Et rimeligt moderne hierarki ser sådan ud:

1. Argon2id til nye systemer, hvor den er tilgængelig.
2. bcrypt når Argon2id ikke er praktisk, og bcrypt-understøttelsen er moden.
3. scrypt når memory-hard-konfiguration er godt understøttet.
4. PBKDF2 hvor det kræves af platform- eller compliance-begrænsninger.

Undgå almindelig SHA-256, SHA-512, MD5 eller en hjemmelavet kombination såsom sha256(password + salt). Hurtige hashes er ikke funktioner til adgangskodelagring. Smarte specialbyggede konstruktioner har det med at være dårligere end kedelige standardløsninger.

Undgå også at opfinde din egen adgangskodepolitik omkring algoritmetrivielle detaljer. Brugere får ikke gavn af en tjekliste med 12 regler for adgangskodesammensætning, hvis den skubber dem mod forudsigelige mønstre. Længere unikke adgangskoder, password managers, screening mod kendt lækkede adgangskoder og MFA betyder som regel mere.

Cost factors er ikke set-and-forget

Password hashing har parametre. Argon2id har hukommelse, iterationer og parallelisme. bcrypt har en cost factor. PBKDF2 har et iterationstal.

Disse værdier bør vælges ud fra dit produktionsmiljø. For lave, og angribere kan gætte billigt. For høje, og dit loginsystem bliver langsomt eller sårbart over for denial-of-service.

Et praktisk mål ligger ofte i intervallet fra titusinder til nogle få hundrede millisekunder per adgangskodeverifikation på dine faktiske servere, afhængigt af trafik og risiko. Højsikkerhedssystemer kan vælge mere. Systemer i forbrugerskala kan have brug for omhyggelig kapacitetsplanlægning.

Kopiér ikke en cost factor fra et fem år gammelt blogindlæg. Hardware ændrer sig. Biblioteker ændrer sig. Din trafik ændrer sig.

Gennemgå parametre periodisk, og planlæg rehashing. Et almindeligt mønster er at gemme algoritmen og parametrene sammen med hver hash. Ved succesfuldt login, hvis de gemte parametre er forældede, rehashes den indsendte adgangskode med den nyere konfiguration, og posten opdateres.

Peppers: nyttige, men ikke en erstatning

En pepper er en hemmelig værdi, der føjes til password-hashing-processen og gemmes separat fra databasen, ofte i en secrets manager eller hardware security module.

I modsætning til et salt skal en pepper forblive hemmelig.

Peppers kan reducere skaden, hvis databasen lækker, men applikationshemmeligheder ikke gør. De er mest nyttige i modne miljøer med god nøglehåndtering. De er mindre nyttige, hvis den samme angriber kan stjæle både databasen og applikationskonfigurationen.

Hvis du bruger en pepper, skal du planlægge rotation omhyggeligt. Rotation af den kan kræve, at brugere logger ind igen eller nulstiller adgangskoder, afhængigt af designet. En pepper er et ekstra lag, ikke en grund til at svække de underliggende hashindstillinger.

Den operationelle tjekliste

Hvis du er ansvarlig for et rigtigt system, er den praktiske tjekliste kort:

• Gem kun adgangskoder med en standard password-hashing-algoritme.
• Brug et unikt tilfældigt salt per adgangskode.
• Foretræk Argon2id til nye builds.
• Finjustér cost-parametre på produktionslignende hardware.
• Gem algoritme og parametre sammen med hver hash.
• Rehash ved login, når parametre bliver forældede.
• Log aldrig adgangskoder, og send dem ikke til analytics-værktøjer.
• Brug TLS overalt, hvor credentials indsendes.
• Tilføj MFA eller passkeys, hvor risikoen berettiger det.
• Beskyt nulstillingsflows lige så seriøst som loginflows.
• Hav en incident plan for tvungne nulstillinger og brugernotifikation.

Password hashing er ikke glamourøst. Det er VVS. Men det er den slags VVS, der afgør, om et brud bliver en smertefuld hændelse eller en katastrofe for hele brugerbasen.

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

💡 Prøv dette: Se, hvordan det samme input mappes til forskellige algoritmer med Hash Generator, som gør forskellen mellem hurtige hashes og hashes i adgangskodekvalitet konkret.

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

Den ærlige mentale model

Den bedste måde at tænke på password hashing er denne:

Hashing beskytter ikke adgangskoden, mens brugeren skriver den. Det beskytter ikke kontoen, efter brugeren er logget ind. Det beskytter ikke brugere, der genbruger adgangskoder på tværs af nettet.

Det beskytter den gemte verifikator.

Det lyder snævert, men det er ekstremt vigtigt. Databaser lækker. Backups lækker. Staging-systemer bliver kopieret. Leverandører får adgang, de ikke burde have. Gamle exports ligger i object storage længere, end nogen kan huske.

Når det sker, bliver dit design for adgangskodelagring forskellen mellem, at angribere modtager adgangskoder, og at angribere modtager et dyrt gætteproblem.

Det er, hvad hashing af en adgangskode faktisk beskytter dig imod.