Argon2 vs bcrypt vs PBKDF2: Hvilken er Tryggest? [2026]

En passordbase på 100 millioner brukere lekker i snitt hvert år et sted i verden. Det som avgjør om lekkasjen blir en katastrofe eller en ikke-hendelse, er sjelden brannmuren. Det er hvilken hashfunksjon som lå bak passordfeltet. Bruker tjenesten fortsatt PBKDF2 med lav iterasjonstelling, kan en angriper med noen få GPU-rigger knekke millioner av passord på timer. Bruker den Argon2id med riktige parametere, tar den samme jobben år, om den i det hele tatt er praktisk mulig.

Denne artikkelen sammenligner de tre algoritmene som dominerer passordhashing i 2026: Argon2 (vinneren av Password Hashing Competition), bcrypt (industristandarden siden 1999) og PBKDF2 (NIST-anbefalingen som fortsatt kjører i utallige produksjonssystemer). Vi går gjennom spesifikasjoner, ytelsestall fra flere uavhengige kilder, kostnaden ved å kjøre dem i skyen, og hvilken algoritme du bør velge for akkurat ditt system.

Valget virker kanskje som en detalj som hører hjemme dypt inne i en autentiseringsmodul, noe utviklerne setter opp én gang og aldri tenker på igjen. I praksis er det en av de mest kostbare sikkerhetsbeslutningene et team tar, fordi feilen ikke viser seg før databasen allerede er stjålet. Da er det for sent å bytte algoritme for de hashene som allerede ligger der. Det er derfor verdt å bruke tid på å forstå forskjellene før neste system bygges, ikke etter at neste brudd er et faktum.

Hva er passordhashing, og hvorfor er det ikke det samme som kryptering

Kryptering er reversibelt: har du nøkkelen, kan du dekryptere. Hashing skal derimot være en enveisfunksjon. Når en bruker registrerer et passord, kjører serveren det gjennom en hashfunksjon og lagrer bare resultatet. Ved innlogging hashes det innsendte passordet på nytt, og de to hashene sammenlignes. Passordet i klartekst forlater aldri minnet lenger enn nødvendig, og det lagres aldri i databasen.

Problemet med vanlige hashfunksjoner som SHA-256 er at de er for raske. En moderne GPU kan regne ut milliarder av SHA-256-hasher i sekundet, noe som gjør brute force-angrep mot stjålne hash-databaser trivielt raskt. Derfor finnes det en egen klasse algoritmer bygget for å være trege med vilje, og som lar deg skru opp kostnaden etter hvert som maskinvaren blir raskere. Argon2, bcrypt og PBKDF2 er de tre som har overlevd testen av tid og fortsatt anbefales av OWASP sin Password Storage Cheat Sheet.

Alle tre bruker salting som standard, altså at hver passordhash får et unikt, tilfeldig tillegg før hashingen. Det stopper såkalte rainbow table-angrep, der en angriper på forhånd har regnet ut hasher for millioner av vanlige passord. Forskjellen mellom algoritmene ligger i hvor mye arbeid de krever per hash, og hvilken type maskinvare det arbeidet er dyrt på.

Det finnes to hovedkategorier med treghet en algoritme kan bygge på: tidshardhet og minnehardhet. Tidshard betyr at algoritmen krever mange sekvensielle regneoperasjoner, noe som gjør den treg på én kjerne, men som ikke nødvendigvis stopper en angriper fra å kjøre tusenvis av parallelle kjerner samtidig. Minnehard betyr at hver enkelt operasjon krever en betydelig mengde arbeidsminne, noe som setter en hard grense for hvor mange operasjoner som kan kjøre parallelt på én GPU eller ASIC, uansett hvor mange regnekjerner brikken har. Denne distinksjonen er selve kjernen i hvorfor Argon2, bcrypt og PBKDF2 oppfører seg så forskjellig under et reelt angrep, og den kommer til å gå igjen gjennom resten av artikkelen.

Kort historikk: fra Unix crypt() til Password Hashing Competition

Passordhashing som eget forskningsfelt startet med Unix sin opprinnelige crypt()-funksjon på 1970-tallet, basert på DES-chifferet og begrenset til åtte tegns passord. Den ble raskt for svak etter hvert som datamaskiner ble raskere, og på 1990-tallet dukket både MD5-crypt og bcrypt opp som forsøk på å bygge inn justerbar treghet direkte i algoritmen, i stedet for å stole på at underliggende maskinvare alltid ville være treg nok.

PBKDF2 kom i 2000 som en mer generell, NIST-vennlig løsning, opprinnelig tenkt for nøkkelderivasjon i kryptografiske protokoller like mye som for passordlagring. Det tok over ti år før bransjen for alvor innså at verken PBKDF2 eller bcrypt var godt nok rustet mot GPU-akselerert cracking, noe som direkte motiverte Password Hashing Competition (PHC). Konkurransen startet i 2013, samlet inn 24 kandidater fra kryptografimiljøer over hele verden, og kåret Argon2 som vinner i 2015. Målet var eksplisitt å finne en algoritme som var vanskelig å akselerere med spesialisert maskinvare, noe som er nøyaktig den egenskapen minnehardhet gir.

PBKDF2: NIST-standarden fra 2000-tallet som nekter å dø

PBKDF2 (Password-Based Key Derivation Function 2) ble definert i RFC 2898 allerede i 2000. Prinsippet er enkelt: den kjører en HMAC (typisk med SHA-256 eller SHA-512) om og om igjen, tusenvis av ganger, og bruker resultatet som nøkkelmateriale. Jo flere iterasjoner, jo dyrere blir det å regne ut hashen, både for den legitime serveren og for en angriper som prøver å knekke den.

Svakheten er strukturell: PBKDF2 er tidshard, men ikke minnehard. Den bruker nesten ingen RAM, noe som betyr at den er nesten fritt parallelliserbar på GPU-er, FPGA-er og spesialbygde ASIC-er. En angriper kan kjøre tusenvis av parallelle PBKDF2-forsøk samtidig på billig GPU-maskinvare, noe som gjør algoritmen vesentlig svakere mot maskinvareakselererte angrep enn Argon2, selv ved samme kjøretid.

NIST SP 800-63B krever fortsatt at PBKDF2 skal brukes med et iterasjonstall «så høyt som verifikasjonsserverens ytelse tillater». Nyere retningslinjer referert i bransjeverktøy peker mot minst 600 000 iterasjoner for PBKDF2-HMAC-SHA-256 og 210 000 for PBKDF2-HMAC-SHA-512 i 2024-oppdateringen av anbefalingene, en kraftig økning fra de gamle eksemplene på 10 000 iterasjoner. Grunnen til at PBKDF2 fortsatt lever videre, er ikke at den er den beste algoritmen. Det er fordi den er FIPS-godkjent og dypt forankret i eldre systemer, spesielt innen offentlig sektor og finans der compliance-krav ofte peker eksplisitt på NIST-godkjente primitiver.

Det gamle rådet om 10 000 iterasjoner stammer fra en tid da CPU-er var langt tregere og GPU-basert cracking ikke var allment tilgjengelig for vanlige angripere. I 2026 er 10 000 iterasjoner nærmest verdiløst som beskyttelse mot en angriper med tilgang til én enkelt gaming-GPU. Det er verdt å understreke at iterasjonstallet ikke er en engangsinnstilling: det bør økes jevnlig i takt med at maskinvaren blir raskere, akkurat som bcrypt sin cost factor. Et system som ble konfigurert riktig i 2015, er nesten garantert underkonfigurert i 2026 hvis ingen har rørt tallet siden.

bcrypt: Blowfish-arven som fortsatt er standard i Rails og Devise

bcrypt kom i 1999, bygget på Blowfish-chiffer av Niels Provos og David Mazières. Den introduserte «cost factor», en enkel eksponentiell skalering: hver økning på 1 i cost factor dobler tiden det tar å regne ut hashen. En cost factor på 10 gir typisk noen titalls millisekunder på moderne maskinvare, mens 12–14 er vanlig i produksjon i 2026.

bcrypt sin store fordel er at den bruker litt mer minne enn PBKDF2 gjennom sin nøkkelplan (key setup), noe som gjør den noe mer motstandsdyktig mot ren GPU-brute-force enn PBKDF2, uten å nærme seg Argon2 sitt nivå. Ulempen er at bcrypt har en hardkodet maksgrense på 72 byte for input-passordet, og bruker en egen, eldre variant av Base64-koding som har skapt kompatibilitetsbugs i flere populære biblioteker opp gjennom årene.

bcrypt er fortsatt standardvalget i Ruby on Rails (via Devise/has_secure_password) og svært utbredt i Node.js-økosystemet gjennom bcryptjs og bcrypt-pakkene. OWASP anbefaler at cost factor settes så høyt som mulig, tunet slik at en enkelt hash-verifikasjon tar mellom 0,5 og 1 sekund på target-serveren, samme prinsipp som for PBKDF2.

En ofte oversett detalj er hvordan ulike bcrypt-biblioteker håndterer selve 72-byte-grensen. Noen implementasjoner kutter passordet stille ved byte 72, uten å varsle utvikleren, noe som i praksis kan gjøre svært lange passfraser mindre unike enn brukeren tror. Andre biblioteker hasher passordet med SHA-256 først for å komprimere det til en fast lengde før det sendes videre til bcrypt, en løsning som løser lengdeproblemet, men som også introduserer en ny avhengighet og et nytt sted implementasjonen kan gjøres feil på. Dette er en av grunnene til at nyere prosjekter i økende grad velger Argon2, som ikke har noen praktisk øvre lengdegrense i det hele tatt.

Argon2: PHC-vinneren og OWASP sin foretrukne algoritme i 2026

Argon2 vant Password Hashing Competition (PHC) i 2015, en åpen, flerårig konkurranse designet etter samme modell som NIST brukte for å velge AES og SHA-3. Algoritmen finnes i tre varianter: Argon2d (maksimal motstand mot GPU-angrep, men sårbar for side-channel-angrep), Argon2i (optimalisert mot side-channel-angrep) og Argon2id, en hybrid som kombinerer begge. Argon2id er variansen OWASP og de fleste moderne rammeverk anbefaler som standard i 2026.

Det som skiller Argon2 fra både bcrypt og PBKDF2, er at den er minnehard på en helt annen skala. Der bcrypt bruker noen kilobyte, kan Argon2id konfigureres til å kreve titalls eller hundrevis av megabyte RAM per hash-operasjon. Det gjør den dramatisk dyrere å parallellisere på GPU og ASIC, siden minnebåndbredde, ikke regnekraft, blir flaskehalsen for en angriper.

Ifølge OWASP sin oppdaterte Password Storage Cheat Sheet er minimumskonfigurasjonen for Argon2id i 2026 satt til minnekostnad m = 19 456 KiB (om lag 19 MiB), tidskostnad t = 2, og parallellitet p = 1. Der ytelsesbudsjettet tillater det, anbefaler OWASP høyere minneprofiler, for eksempel rundt 46–64 MiB med færre iterasjoner. Argon2 er også standardisert av IETF gjennom RFC 9106, noe verken bcrypt eller PBKDF2 kan vise til på samme måte.

Den tredje parameteren, parallellitet (p), er unik for Argon2 blant de tre algoritmene. Den lar deg spesifisere hvor mange parallelle tråder selve hash-beregningen bruker internt på serveren din. Satt riktig kan den redusere effektiv ventetid for brukeren betydelig på en flerkjerne-server, uten å svekke sikkerheten, siden minnekravet og den totale regnemengden holdes konstant uansett hvor mange tråder som deler jobben. Det er nettopp denne fleksibiliteten, tre uavhengige knapper å skru på i stedet for én, som gjør Argon2id enklere å tilpasse presist til forskjellig maskinvare enn bcrypt sin enkle cost factor.

Spesifikasjonstabell: Argon2 vs bcrypt vs PBKDF2

Tabellen under samler kjernedata om alle tre algoritmene, hentet fra offisielle standarddokumenter og OWASP/NIST-retningslinjer.

Egenskap	Argon2id	bcrypt	PBKDF2
Standardisert av	PHC-vinner (2015), IETF RFC 9106	Uformell industristandard (1999)	RFC 2898, NIST SP 800-63B
Underliggende primitiv	Egendefinert (BLAKE2b-basert)	Blowfish-chiffer	HMAC (SHA-256/SHA-512)
Minnehard	Ja, konfigurerbar (MB-nivå)	Delvis, fast lavt nivå	Nei
Tidshard	Ja	Ja	Ja
Parallellitetsparameter	Ja (p)	Nei	Nei
Maks passordlengde	Ingen praktisk grense	72 byte	Ingen praktisk grense
OWASP-anbefalt minstenivå	m=19 456 KiB, t=2, p=1	Cost factor så høyt som mulig (0,5-1s)	Iterasjoner så høyt som mulig (0,5-1s)
GPU/ASIC-motstand	Høy	Middels	Lav
FIPS-godkjent	Nei	Nei	Ja
Typisk bruk 2026	Nye systemer, passordbehandlere	Rails, Devise, Node.js	Eldre systemer, offentlig sektor, WPA2/3
Sidekanalmotstand	God (id-varianten)	God	God
Krever ekstern minneallokering	Ja	Nei	Nei

Ytelse og benchmarks: hva koster en hash faktisk å regne ut

Tallene under er hentet fra sammenstilte benchmarks i nyere sammenligningsguider for passordhashing (2025–2026), samt akademisk arbeid som siterer eldre GPU-cracking-tester. De skal leses som indikative, ikke som eksakte tall for din egen maskinvare, siden faktisk ytelse varierer med CPU-generasjon og biblioteksimplementasjon.

Konfigurasjon	Omtrentlig tid per hash (server-CPU)	Kilde/kontekst
Argon2id, m=19 MiB, t=2, p=1 (OWASP-minimum)	~100–150 ms	Sammenstilt 2025-guide for passordhashing-parametere
Argon2id, m=64 MiB, t=3, p=1	~200 ms	Samme kilde, høyere sikkerhetsprofil
Argon2id, m=128 MiB, t=3, p=4	~150 ms (paralleliserbar internt)	Samme kilde, ytelsesoptimert profil
bcrypt, cost factor 12	~250–300 ms	Vanlig produksjonsverdi, tunet mot OWASP 0,5-1s-regel
PBKDF2-HMAC-SHA256, 600 000 iterasjoner	~100–200 ms	NIST 2024-oppdatert minstekrav

Det som virkelig skiller algoritmene, er ikke tiden på serveren, men tiden på angriperens maskinvare. En universitetsavhandling som siterer eldre GPU-cracking-forskning (Hallett mfl.) rapporterer at toppmoderne GPU-er kunne oppnå rundt 50 000 bcrypt-hasher per sekund, mot under 3 000 forsøk per sekund for Argon2id ved tilsvarende kjøretid, en forskjell på over 90 prosent i angriperens favør for bcrypt. En nyere sammenligning sitert i samme kilde beskriver at Argon2id med 1 GiB minne og 3 passeringer reduserer GPU-gjennomstrømningen for cracking med over 95 prosent sammenlignet med en SHA-512-basert PBKDF2-konfigurasjon med samme kjøretid. Dette illustrerer kjernepoenget: minnehardhet, ikke ren CPU-tid, er det som gjør en algoritme dyr å angripe i parallell.

En tredje, mer fersk datakilde bekrefter bildet fra et annet vinkel. Publiserte hashcat-benchmarks for Nvidia RTX 4090 (mode 3200, bcrypt) viser en gjennomstrømning på om lag 180 000 hasher i sekundet, ifølge Tech Tutorials sin hashcat-benchmarktabell for 2026. Til sammenligning klarer samme kort over 22 milliarder SHA-256-hasher i sekundet, ifølge Online Hash Crack sin GPU-benchmarkoversikt for 2025, en forskjell på over 120 000 ganger mellom en rå, ikke-passordtilpasset hashfunksjon og en algoritme spesifikt designet for å bremse angriperen. Selv innenfor de spesialiserte passordhashene er forskjellen tydelig: bcrypt sine 180 000 H/s på ett enkelt topp-GPU-kort er fortsatt en størrelsesorden raskere enn Argon2id sine under 3 000 H/s fra den akademiske kilden over, noe som samsvarer godt på tvers av begge datasettene til tross for at de er hentet fra forskjellige år og forskjellig maskinvare.

GPU- og ASIC-motstand: hvorfor minne slår regnekraft

En moderne GPU har tusenvis av regnekjerner, men delt minnebåndbredde. Det gjør GPU-er ekstremt gode på oppgaver som bruker lite minne per tråd, som PBKDF2 og til dels bcrypt, men dårligere egnet til oppgaver som krever store, uavhengige minneblokker per beregning. Argon2id utnytter nettopp dette gapet: hver hash-operasjon krever sin egen tildelte minneblokk, ofte titalls megabyte, som ikke kan deles mellom parallelle tråder på en GPU uten at ytelsen kollapser.

ASIC-er (spesialbygde brikker) kan i teorien bygges med mer minne, men kostnaden per brikke stiger brått med minnemengden, noe som gjør Argon2id vesentlig dyrere å angripe i stor skala enn algoritmer som primært krever regnekraft. Dette er også grunnen til at John the Ripper og andre passord-crackingverktøy fortsatt sliter mer med å skalere Argon2-angrep enn bcrypt- eller PBKDF2-angrep, selv med moderne GPU-klynger.

Vanlige implementeringsfeil, uansett hvilken algoritme du velger

Selv den beste algoritmen hjelper lite hvis den settes opp feil. Den vanligste feilen er å bruke standardverdiene fra et bibliotek uten å faktisk teste dem mot egen maskinvare og trafikkmengde. Standardverdier er ofte satt konservativt for å fungere greit på svak maskinvare, noe som betyr at de kan være langt lavere enn det OWASP faktisk anbefaler i 2026.

Den nest vanligste feilen er å gjenbruke samme salt for alle brukere, eller enda verre, å hardkode et globalt salt i applikasjonskoden. Da mister du hele poenget med salting, siden en angriper bare trenger å regne ut rainbow tables én gang for hele databasen. Alle moderne biblioteker for Argon2, bcrypt og PBKDF2 genererer et unikt, kryptografisk tilfeldig salt automatisk per hash, og det finnes sjelden god grunn til å overstyre denne oppførselen selv.

En tredje feil, mer subtil, er å blande sammen «pepper» (en hemmelig, applikasjonsbred nøkkel lagret separat fra databasen, for eksempel i en secrets manager) med salt. Pepper er et nyttig ekstra lag, siden det betyr at en angriper som bare får tak i databasen, fortsatt mangler en kritisk bit for å starte cracking-forsøk. Men pepper erstatter ikke behovet for en treg hashfunksjon i utgangspunktet, det er et tillegg, ikke en erstatning.

OWASP og NIST sine anbefalinger i 2026

De to viktigste referansepunktene i bransjen er fortsatt OWASP sin Password Storage Cheat Sheet og NIST SP 800-63B. De er ikke alltid samstemte, og forskjellen er verdt å forstå før du velger algoritme for et nytt system.

Kilde	Førstevalg	Andrevalg	Begrunnelse
OWASP Password Storage Cheat Sheet	Argon2id	bcrypt eller scrypt hvis Argon2 ikke er tilgjengelig	Minnehardhet gir best motstand mot maskinvareakselererte angrep
NIST SP 800-63B	PBKDF2 (påkrevd for FIPS-samsvar)	Minnehard funksjon anbefales, men ikke pålagt	PBKDF2 er så utbredt at et hardt krav om minnehard funksjon ikke er praktisk ennå, ifølge NIST sin egen FAQ

Denne todelingen forklarer hvorfor du fortsatt ser PBKDF2 dominere i offentlig sektor, bank og andre bransjer med strenge FIPS 140-krav, mens nyere forbrukerrettede tjenester og passordbehandlere i stor grad har gått over til Argon2id. NIST sitt eget FAQ-dokument beskriver Argon2 som «minne- og tidshard» og PBKDF2 som kun tidshard, og anerkjenner eksplisitt at minnehardhet gjør storskala cracking vanskeligere.

Kostnad ved skalering: hva koster hashingen i skyen

Ingen av de tre algoritmene koster penger i seg selv, de er alle åpen kildekode og gratis å bruke. Men prisen dukker opp indirekte, i CPU-tiden du betaler for i skyen hver gang en bruker logger inn. Tabellen under bruker offisielle, publiserte 2026-priser fra AWS Lambda (0,0000166667 USD per GB-sekund på x86) og Google Cloud Run (0,000024 USD per vCPU-sekund i standardtier) til å illustrere den relative kostnadsforskjellen ved 1 million innlogginger per måned, med 1 GB minne allokert per funksjonskall.

Algoritme/konfigurasjon	Est. tid per hash	Est. kostnad per 1M innlogginger (AWS Lambda, 1GB)	Est. kostnad per 1M innlogginger (Cloud Run)
PBKDF2-HMAC-SHA256, 600k iterasjoner	~0,15 s	~2,50 USD	~3,60 USD
bcrypt, cost factor 12	~0,25 s	~4,17 USD	~6,00 USD
Argon2id, m=19 MiB, t=2, p=1	~0,12 s	~2,00 USD	~2,88 USD
Argon2id, m=64 MiB, t=3, p=1 (høy sikkerhet)	~0,20 s	~3,33 USD	~4,80 USD

Estimatene er regnet ut fra kjøretidstallene i benchmark-tabellen over, koblet mot offentlig publiserte skyprisene, og er ment som en illustrasjon av størrelsesorden, ikke en nøyaktig fakturaprognose for ditt system. Poenget er at forskjellen mellom «billig» og «sikker» konfigurasjon typisk er noen få dollar per million innlogginger, en marginal kostnad sammenlignet med prisen på et faktisk passordbrudd.

Kostnadsbildet endrer seg litt hvis systemet ditt kjører på dedikerte servere i stedet for serverløs infrastruktur, siden du da betaler for kapasitet uansett, ikke per kall. Men logikken er den samme: en tregere hashfunksjon krever flere CPU-kjerner eller lengre køtid ved innloggingstopper, for eksempel rett etter en større markedsføringskampanje eller ved sesongstart for en abonnementstjeneste. Dette er grunnen til at mange team velger å legge passordverifikasjon i en egen tjeneste eller kø, adskilt fra resten av innloggingsflyten, slik at en plutselig økning i CPU-bruk fra hashingen ikke påvirker responstiden på resten av applikasjonen.

Fem virkelige eksempler på bruk i produksjon

Django bruker PBKDF2-HMAC-SHA256 som standard passordhasher, men tilbyr Argon2 som et innebygd, offisielt støttet alternativ for prosjekter som installerer argon2-cffi, dokumentert i Django sin egen autentiseringsdokumentasjon.
Ruby on Rails, gjennom has_secure_password og Devise-gemmet, bruker bcrypt som standard og har gjort det siden tidlig 2010-tall.
Bitwarden lar brukeren velge mellom PBKDF2 og Argon2id for det klientsidegenererte hovednøkkel-derivatet, med Argon2id som det nyere, sterkere alternativet i klientinnstillingene, se Bitwarden sin egen krypteringsdokumentasjon.
Node.js-økosystemet er delt mellom bcrypt/bcryptjs for eldre og enklere oppsett, og node-argon2 for nyere prosjekter som følger OWASP sine 2026-anbefalinger.
WPA3 og enkelte VPN-implementasjoner bruker fortsatt PBKDF2 for nøkkelderivasjon fra passfraser, delvis fordi standarden er FIPS-forankret og krever minimalt med minne på nettverksutstyr med begrensede ressurser.

Det som er verdt å merke seg på tvers av alle fem eksemplene, er at ingen av dem har valgt algoritme utelukkende basert på hva som er teoretisk sterkest. Django og Bitwarden tilbyr flere alternativer og lar utvikleren eller brukeren velge selv. Rails og WPA3 har blitt stående ved sine opprinnelige valg fordi migrering i stor skala er kostbart og risikofylt. Dette mønsteret, at eksisterende systemer beveger seg tregere enn anbefalingene, er selve grunnen til at både bcrypt og PBKDF2 fortsatt er relevante å forstå godt i 2026, selv om Argon2id er det tekniske førstevalget for nye prosjekter.

Bruksområder: hvilken algoritme passer til hvilket scenario

Valget av algoritme handler sjelden om hvilken som er «best» i vakuum. Det handler om hvilke begrensninger systemet ditt faktisk har.

Ny webapplikasjon uten legacy-krav: Argon2id med OWASP-baseline (m=19 MiB, t=2, p=1) eller høyere. Dette er standardanbefalingen for de aller fleste nye systemer i 2026.
Offentlig sektor eller finans med FIPS 140-krav: PBKDF2-HMAC-SHA256 med minst 600 000 iterasjoner, siden Argon2 foreløpig ikke er FIPS-godkjent.
Eksisterende Rails- eller Devise-basert system: Behold bcrypt, men øk cost factor jevnlig etter hvert som maskinvaren blir raskere, og vurder en migreringsplan til Argon2id ved neste større versjonsoppgradering.
Ressursbegrenset IoT- eller embedded-miljø: PBKDF2 eller lav-minne bcrypt, siden Argon2 sin minnehardhet kan være upraktisk på enheter med begrenset RAM.
Passordbehandlere og krypteringsnøkler avledet fra hovedpassord: Argon2id med høy minneprofil (64 MiB eller mer), siden trusselmodellen her ofte innebærer at en angriper allerede har en offline-kopi av den krypterte hvelvfilen.
API-autentisering med svært høy innloggingsfrekvens: Argon2id med lavere, men fortsatt OWASP-godkjent minneprofil (rundt 19 MiB), for å balansere sikkerhet mot CPU-kostnad i skyen.

Migreringsguide: fra PBKDF2 eller bcrypt til Argon2id

Du kan ikke bare bytte hashfunksjon og rehashe alle passord samtidig, siden du aldri lagrer passordene i klartekst. Standardmønsteret er «lazy migration»: du oppgraderer hver bruker sin hash først neste gang de logger inn.

Denne tilnærmingen har én praktisk konsekvens du bør planlegge for: brukere som sjelden logger inn, kan gå måneder eller år uten å bli migrert. For de fleste konsumentrettede tjenester er dette et akseptabelt kompromiss, siden inaktive kontoer generelt utgjør lavere risiko enn aktive kontoer. For systemer med strengere sikkerhetskrav kan det være verdt å kombinere lazy migration med en aktiv kampanje, for eksempel en e-post som ber langtidsinaktive brukere logge inn på nytt eller tilbakestille passordet innen en gitt frist, slik at den gamle, svakere hashen til slutt forsvinner helt fra databasen.

Installer et Argon2-bibliotek for språket ditt (argon2-cffi i Python, node-argon2 i Node.js, golang.org/x/crypto/argon2 i Go).
Legg til en ny kolonne eller et nytt felt i brukertabellen som identifiserer hvilken algoritme og hvilke parametere som ble brukt for hver hash (algoritme-prefiks er ofte innebygd i selve hash-strengen for Argon2 og bcrypt).
Behold eksisterende verifikasjonslogikk for gamle hasher uendret, slik at innlogging fortsatt fungerer for brukere som ikke har logget inn ennå.
Ved vellykket innlogging: sjekk om brukerens lagrede hash bruker gammel algoritme eller utdaterte parametere.
Hvis ja: hash passordet på nytt med Argon2id og OWASP-baseline-parametere, og oppdater databasen.
Sett en tidsfrist (typisk 6-12 måneder) for når inaktive kontoer med gammel hash tvinges gjennom passordtilbakestilling.
Overvåk andelen migrerte kontoer i et dashboard, slik at du vet når det er trygt å fjerne den gamle verifikasjonskoden.

Eksempelet under viser hvordan verifikasjons- og rehashing-logikken typisk ser ut i Node.js med biblioteket node-argon2, som også kan verifisere eksisterende bcrypt-hasher via et separat bibliotek i samme steg.

const argon2 = require('argon2');
const bcrypt = require('bcrypt');

async function verifyAndUpgrade(user, plainPassword) {
  let isValid = false;

  if (user.hashAlgo === 'bcrypt') {
    isValid = await bcrypt.compare(plainPassword, user.passwordHash);
    if (isValid) {
      // Lazy migration: rehash med Argon2id ved vellykket innlogging
      user.passwordHash = await argon2.hash(plainPassword, {
        type: argon2.argon2id,
        memoryCost: 19456, // KiB, OWASP-baseline
        timeCost: 2,
        parallelism: 1
      });
      user.hashAlgo = 'argon2id';
      await user.save();
    }
  } else if (user.hashAlgo === 'argon2id') {
    isValid = await argon2.verify(user.passwordHash, plainPassword);
  }

  return isValid;
}

Uansett hvilken vei du velger, bør migreringen testes grundig i et separat miljø først, med spesiell oppmerksomhet på tegnkoding. Passord som inneholder emoji, ikke-latinske tegn eller andre Unicode-tegn utenfor det vanlige ASCII-settet, har historisk vært en kilde til subtile bugs når kode flyttes mellom hashbiblioteker, siden ulike biblioteker noen ganger normaliserer Unicode-strenger forskjellig før hashing. En feil her kan i verste fall låse legitime brukere ute av egne kontoer uten at noe ser galt ut i loggene.

Fordeler og ulemper

Argon2id

Fordeler: Best motstand mot GPU/ASIC-cracking, PHC-vinner og IETF-standardisert (RFC 9106), tre justerbare parametere gir fin kontroll over sikkerhet vs. ytelse, aktivt anbefalt av OWASP som førstevalg i 2026.

Ulemper: Ikke FIPS 140-godkjent, krever mer RAM per operasjon (kan bli en flaskehals ved svært høy samtidighet), yngre enn bcrypt med noe kortere historikk i skarp produksjon.

bcrypt

Fordeler: 25+ år i produksjon uten kjente strukturelle svakheter, enkel å konfigurere med én parameter (cost factor), bredt støttet i nesten alle språk og rammeverk.

Ulemper: 72-byte input-grense kan skape sikkerhetshull hvis den ikke håndteres eksplisitt, svakere mot moderne GPU-klynger enn Argon2id, ikke offisielt standardisert av noen standardiseringsorgan.

PBKDF2

Fordeler: FIPS 140-godkjent og NIST-anbefalt, ekstremt bredt støttet inkludert i native kryptobiblioteker uten tredjepartsavhengigheter, forutsigbar ytelse.

Ulemper: Ikke minnehard, dermed svakest av de tre mot GPU/ASIC-akselererte angrep, krever svært høye iterasjonstall (600 000+) i 2026 for å holde tritt med maskinvareutviklingen.

Verdikt: hvilken algoritme bør du velge i 2026

For de fleste nye systemer uten harde compliance-krav er svaret enkelt: Argon2id. Den kombinerer PHC-seier, IETF-standardisering gjennom RFC 9106, og en dokumentert fordel på over 90 prosent redusert GPU-gjennomstrømning sammenlignet med bcrypt ved tilsvarende kjøretid. Den ekstra RAM-kostnaden, typisk noen få dollar ekstra per million innlogginger i skyen, er en lav pris å betale mot et passordbrudd som kan koste millioner i opprydding og omdømmetap.

Skal du sette ett konkret tall på beslutningen: hashcat-tallene i benchmarkseksjonen viser at bcrypt lar en enkelt RTX 4090 gjøre om lag 180 000 gjetteforsøk i sekundet, mens den akademiske Argon2id-referansen ligger på under 3 000 i sekundet ved sammenlignbar kjøretid. Det er over 60 ganger tregere å angripe, på identisk maskinvarebudsjett. For et system som lagrer passord for hundretusener eller millioner av brukere, er den forskjellen ikke marginal, den er ofte det som avgjør om et databrudd blir en footnote i et sikkerhetsvarsel eller en førsteside-nyhet.

bcrypt forblir et solid, forsvarlig valg for eksisterende systemer der en full migrering ikke er praktisk mulig med det samme. Den har ingen kjente kritiske svakheter, bare en relativt sett svakere posisjon mot moderne maskinvare enn Argon2id.

PBKDF2 er riktig valg når regelverket faktisk krever FIPS 140-samsvar, ikke fordi den er den tryggeste algoritmen på papiret. Utenfor den konteksten er den det svakeste av de tre alternativene, og bør oppgraderes til minst 600 000 iterasjoner umiddelbart hvis systemet ditt fortsatt bruker eldre, lavere iterasjonstall.

Hva skjer med passordhashing når passkeys tar over?

Passkeys og andre FIDO2/WebAuthn-baserte påloggingsmetoder er i ferd med å bli standard hos store forbrukertjenester, og målet på lang sikt er å fjerne passord fra likningen helt. Det betyr likevel ikke at Argon2, bcrypt og PBKDF2 blir irrelevante med det første. De fleste passkey-utrullinger er hybride: brukeren kan fortsatt falle tilbake til passord, spesielt på eldre enheter eller i bedriftssystemer som ikke har rukket å modernisere autentiseringen sin.

I tillegg finnes det et helt økosystem av systemer der passord ikke forsvinner uansett hva som skjer på forbrukersiden, som interne API-er, eldre integrasjoner, VPN-passfraser og krypteringsnøkler avledet fra hovedpassord i passordbehandlere. Så lenge disse systemene eksisterer, vil valget mellom Argon2, bcrypt og PBKDF2 fortsette å være en reell, praktisk beslutning utviklere må ta, ikke en historisk fotnote. Realistisk sett kommer alle tre til å være i aktiv bruk et godt stykke inn i neste tiår, selv om andelen nye systemer som velger passordbasert autentisering i utgangspunktet, gradvis vil synke etter hvert som passkeys modnes.

Vanlige spørsmål om Argon2, bcrypt og PBKDF2

Er Argon2 alltid bedre enn bcrypt?

I ren sikkerhetsmotstand, ja. Argon2id sin minnehardhet gjør den vesentlig dyrere å angripe med GPU eller ASIC enn bcrypt. Men bcrypt er fortsatt et forsvarlig valg, spesielt i systemer der Argon2 ikke er tilgjengelig eller der en migrering medfører uforholdsmessig risiko.

Hvorfor bruker banker og offentlige systemer fortsatt PBKDF2?

Fordi PBKDF2 er FIPS 140-godkjent og eksplisitt nevnt i NIST SP 800-63B. Mange finans- og offentlige systemer har juridiske eller kontraktsmessige krav om FIPS-samsvar, og Argon2 mangler foreløpig denne godkjenningen.

Hvilken Argon2-variant bør jeg bruke: Argon2d, Argon2i eller Argon2id?

Argon2id, for nesten alle bruksområder. Den kombinerer motstanden mot GPU-angrep fra Argon2d med motstanden mot sidekanalangrep fra Argon2i, og er variansen både OWASP og RFC 9106 anbefaler som standardvalg.

Hvor mye RAM trenger Argon2id egentlig?

OWASP sin minstekonfigurasjon krever om lag 19 MiB per hash-operasjon. Ved høy samtidighet (for eksempel 1000 innlogginger i sekundet) kan dette bety flere gigabyte total RAM-bruk på topp, noe som må dimensjoneres inn i infrastrukturen.

Kan jeg migrere fra bcrypt til Argon2id uten å tvinge alle brukere til å tilbakestille passordet?

Ja, gjennom lazy migration: du verifiserer mot den gamle hashen ved innlogging, og rehasher umiddelbart med Argon2id hvis passordet stemmer. Brukere som ikke logger inn på lenge, kan tvinges gjennom en tilbakestilling etter en definert frist.

Er PBKDF2 usikkert å bruke i 2026?

Ikke usikkert i seg selv, men svakere enn alternativene hvis iterasjonstallet er for lavt. Med minst 600 000 iterasjoner for SHA-256-varianten, slik NIST sin 2024-oppdatering anbefaler, er PBKDF2 fortsatt et forsvarlig valg, spesielt der FIPS-samsvar er et krav.

Hva skjer hvis jeg setter Argon2-parametere for høyt?

Da risikerer du at innloggingsserverne dine går tom for minne under lastspisser, eller at innloggingstiden blir merkbart treg for brukeren. OWASP sin 0,5-1 sekunds tommelfingerregel finnes nettopp for å balansere sikkerhet mot brukeropplevelse og infrastrukturkostnad. Last alltid parameterendringer gjennom en realistisk belastningstest før de går i produksjon, ikke bare en enkelt manuell test på en utviklermaskin med god CPU og ledig RAM.

Bruker passordbehandlere som Bitwarden og 1Password disse algoritmene på samme måte som en vanlig nettside?

Ikke helt. Passordbehandlere bruker gjerne PBKDF2 eller Argon2id til å avlede en krypteringsnøkkel fra hovedpassordet ditt, i tillegg til at selve hvelvet krypteres med en symmetrisk algoritme som AES-256. Trusselmodellen er også litt annerledes, siden angriperen ofte antas å allerede ha en offline kopi av den krypterte hvelvfilen. Det betyr at parametervalget for nøkkelderivasjonen der ofte settes enda strengere enn for en vanlig nettsides innloggingsfelt, siden konsekvensen av et vellykket angrep er langt større: hele passordarkivet, ikke bare én konto.

Argon2 vs bcrypt vs PBKDF2: 60x Tregere å Knekke [2026]