Hvorfor er bcrypt begrenset til 72 tegn?

Historisk implementeringsdetalj av det underliggende Blowfish-chifferet. Lengre innganger blir avkortet. De fleste brukere legger ikke merke til det; en tilfeldig passordfrase på 16 tegn er langt under grensen. For systemer som ønsker ubegrenset passordlengde, har Argon2 ingen slik begrensning.

Bør jeg salte og pepre passordene mine?

Salt er nødvendig (og ethvert anerkjent bibliotek gjør det automatisk). Pepper er valgfritt, men verdifullt for høysikkerhetssystemer. Avveiningen: å administrere pepperen som en langsiktig hemmelighet utenfor databasen gir operasjonell kompleksitet. De fleste apper lagrer salt + hasj; de største lagrer salt + hasj + pepper-avledet hasj.

Er Argon2 alltid bedre enn bcrypt?

For nye systemer, ja. Argon2 er minnehard (motstandsdyktig mot GPU/ASIC), har ingen grense på 72 tegn, og vant Password Hashing-konkurransen av gode grunner. bcrypt er fortsatt akseptabelt når Argon2 ikke er tilgjengelig eller organisatoriske begrensninger foretrekker den eldre standarden. For eldre systemer som bruker bcrypt med kostnad ≥ 10, haster det lite å migrere.

Hvor lang tid bør det ta å hash et passord?

OWASP foreslår rundt 100-500 ms på serverens maskinvare. Raskere betyr svakere mot angripere; tregere begynner å påvirke legitim innloggingsopplevelse. Det riktige antallet avhenger av trafikken din – høyvolumtjenester velger lavere kostnad; høysikkerhetstjenester med lave påloggingspriser kan velge høyere.

Kan jeg lagre passord kryptert i stedet for hash?

Ikke gjør det. Kryptering er reversibel, noe som betyr at krypteringsnøkkelen må eksistere et sted applikasjonen kan få tilgang til. Hvis databasen brytes, er nøkkelen det ofte også, og du har effektivt lagret ren tekst. Hashings irreversibilitet er poenget - selv din egen applikasjon kan ikke gjenopprette passordet, som er sikkerhetsegenskapen.

Passordhashing forklart: Hvorfor bcrypt, scrypt og Argon2 betyr noe

Lagring av brukerpassord er en av de verst mulige tingene du kan gjøre i klartekst, og en av de vanligste sikkerhetsfeilene. Løsningen har eksistert i flere tiår – passordhashing med langsomme, minneharde algoritmer – men forskjellen mellom gode og dårlige implementeringer er enorm, og de fleste datainnbrudd avslører dårlige valg.

Hele artikkelen er gitt på engelsk nedenfor.

Password hashing er praksisen med å lagre en enveis transformasjon av en brukers passord i stedet for selve passordet. Når brukeren logger på, blir den samme transformasjonen brukt på inndataene og sammenlignet med den lagrede verdien. Hvis den lagrede databasen brytes, har angriperen hashes, ikke passord – og gjenoppretting av originalene burde være beregningsmessig umulig.

Tdet er teorien. Praksisen spenner fra "fungerer som annonsert" til "kan like gjerne ha vært klartekst", avhengig av hvilken algoritme og parametere som ble valgt.

Hva en god passordhash trenger

Enveis. Å kjenne til hashen bør ikke avsløre noe nyttig om passord.
Salted. Hver bruker har et unikt tilfeldig salt blandet inn i hashen. Forhindrer forhåndsberegnet regnbuetabeller og sikrer at identiske passord produserer forskjellige hashes.
Slow. En enkelt hash-beregning bør ta en meningsfull brøkdel av et sekund på angripermaskinvare. Brute-force med milliarder per sekund er det som beseirer raske hashes.
Memory-hard. Hver hash bør kreve betydelig RAM, beseire GPU og ASIC-parallellisering som trives med lite minne per instans.
XFuture bør være kostnadssikre parametere7. oppover etter hvert som maskinvaren blir raskere.

Feil valg

Algorithmer du aldri må bruke for passordlagring:

MD5. Kryptografisk ødelagt siden 2004. Brutestyrker per sekund av forbruker har en bruttostyrke pr. hardware.
SHA-1, SHA-256. Raske kryptografiske hashes designet for integritetskontroll, ikke passordlagring. Brute-forceable med milliarder per sekund på GPUer.
Krypterte passord. Hvis du kan dekryptere dem tilbake til ren tekst, kan en angriper som stjeler nøkkelen også. Hashing er svaret; kryptering er ikke.
Plaintext. skjer fortsatt i 2026. Ethvert brudd på ren tekst-passord kan forebygges.

De riktige valgene

De tre moderne anbefalte Algoritmer:

bcrypt (1999). Justerbar kostnadsfaktor (beregningsrunder). Begrenset til 72-byte passord. Ikke minnehardt, så GPUer kan angripe det effektivt - men en rimelig kostnadsfaktor gjør angrep dyrere. Bred distribusjon, enkel å bruke riktig.
scrypt (2009). Minnehardt. Konfigurerbar minnekostnad, parallellitet og CPU-kostnad. Mer kompleks enn bcrypt; noen ganger feilkonfigurert.
Argon2 (vinner av Password Hashing Competition 2015). Tre varianter: Argon2d (dataavhengig, motstandsdyktig mot GPU-angrep, men sårbar for sidekanaler), Argon2i (datauavhengig, sidekanalsbestandig), Argon2id (hybrid – anbefalt standard). Moderne, godt undersøkt, det riktige valget for nye systemer.

OWASP anbefaler for øyeblikket Argon2id med minst 19 MB minne, iterasjonstall på 2 og parallellitet på 1. For systemer der Argon2 ikke er tilgjengelig, bcrypt med kostnad ≥ 10 eller scrypt som er akseptabelt med passende fallback-parametere PLZ7PLZWhat2XWh. "sakte" betyr i praksis

Kostnadsfaktor på 10 i bcrypt betyr omtrent 100 ms per hash på moderne maskinvare. For en legitim bruker som logger på, er dette umerkelig. For en angriper som prøver å brutt-force 100 millioner passord fra en lekket database, er det 100 millioner × 100 ms = 116 dager med GPU-tid per passering gjennom en rimelig ordliste. Kombinert med et unikt salt per bruker, er store regnbuebord ubrukelige.

For en rask hasj som usaltet SHA-256, tar den samme operasjonen noen minutter på samme maskinvare.

Salthåndtering

Salt genereres av brukeren av en bruker, opprettelse
16 byte er tilstrekkelig (128 bits tilfeldighet)
Salt lagres ved siden av hashen, ikke hemmelig – jobben er å være unik, ikke skjult
De fleste moderne hashingbiblioteker (bcrypt, Argon2-utganger i enkelt-algorith-formater, bundle agorith, saltstring, bunt-streng, og PHC-formater). string

Pepper: valgfri extra

A pepper er en hemmelig verdi for hele nettstedet lagt til hash-inndata, lagret separat fra databasen (i en HSM, nøkkelhvelv eller appkonfigurasjon). Hvis databasen er dumpet, men pepperen ikke er det, kan hashen ikke gjenopprettes selv med brukersalt - fordi angriperen ikke har pepper. Pepper er et nyttig belte-og-selertilskudd for høyverdisystemer.

Oppgrader hashes trygt

Når du endrer parametere eller migrerer algoritmer, kan du ikke hash på nytt uten det originale passordet. Standardtilnærmingen:

Hver brukerpost lagrer gjeldende hash-algoritme, parametere, salt og hash.
On-pålogging, verifiser mot den lagrede hashen med de opprinnelige parameterne.
Hvis verifiseringen lykkes og parameterne er utdaterte med gjeldende parametere og oppdaterer gjeldende parametere. record.

I løpet av noen få måneder med aktive brukere, går databasen over til nye parametere uten å tvinge tilbake tilbakestilling av passord.

Hva dette betyr for brukere

For sluttbrukere, den praktiske effekten: selv når en database brytes, har et sterkt unikt administratorpassord (administrert av et XXLZ16PLZ1passord) server betyr at passordet forblir hemmelig. Svake passord blir knekt selv fra velhashed databaser; brukeren er variabelen en utvikler ikke kan kontrollere.

Ofte stilte spørsmål

Hvorfor er bcrypt begrenset til 72 tegn?: Historisk implementeringsdetalj av det underliggende Blowfish-chifferet. Lengre innganger blir avkortet. De fleste brukere legger ikke merke til det; en tilfeldig passordfrase på 16 tegn er langt under grensen. For systemer som ønsker ubegrenset passordlengde, har Argon2 ingen slik begrensning.
Bør jeg salte og pepre passordene mine?: Salt er nødvendig (og ethvert anerkjent bibliotek gjør det automatisk). Pepper er valgfritt, men verdifullt for høysikkerhetssystemer. Avveiningen: å administrere pepperen som en langsiktig hemmelighet utenfor databasen gir operasjonell kompleksitet. De fleste apper lagrer salt + hasj; de største lagrer salt + hasj + pepper-avledet hasj.
Er Argon2 alltid bedre enn bcrypt?: For nye systemer, ja. Argon2 er minnehard (motstandsdyktig mot GPU/ASIC), har ingen grense på 72 tegn, og vant Password Hashing-konkurransen av gode grunner. bcrypt er fortsatt akseptabelt når Argon2 ikke er tilgjengelig eller organisatoriske begrensninger foretrekker den eldre standarden. For eldre systemer som bruker bcrypt med kostnad ≥ 10, haster det lite å migrere.
Hvor lang tid bør det ta å hash et passord?: OWASP foreslår rundt 100-500 ms på serverens maskinvare. Raskere betyr svakere mot angripere; tregere begynner å påvirke legitim innloggingsopplevelse. Det riktige antallet avhenger av trafikken din – høyvolumtjenester velger lavere kostnad; høysikkerhetstjenester med lave påloggingspriser kan velge høyere.
Kan jeg lagre passord kryptert i stedet for hash?: Ikke gjør det. Kryptering er reversibel, noe som betyr at krypteringsnøkkelen må eksistere et sted applikasjonen kan få tilgang til. Hvis databasen brytes, er nøkkelen det ofte også, og du har effektivt lagret ren tekst. Hashings irreversibilitet er poenget - selv din egen applikasjon kan ikke gjenopprette passordet, som er sikkerhetsegenskapen.