Argon2 vant Password Hashing Competition i juli 2015, men konkurransen endte ikke med én algoritme. Den endte med tre varianter som løser ulike problemer: Argon2d, Argon2i og Argon2id. Mange utviklere velger variant på autopilot uten å vite hvorfor, og det kan koste dyrt hvis trusselbildet ikke passer til valget. Denne artikkelen går gjennom forskjellene i minnetilgang, ytelse og sidekanalmotstand, med tall fra IETF-spesifikasjonen, uavhengige benchmarker og en komparativ studie av nøkkelutledning i mobil databasekryptering. Har du ikke satt deg inn i grunnleggende kryptografiske hashfunksjoner fra før, er det greit å lese det som bakgrunn før du går videre her, siden Argon2 bygger videre på de samme prinsippene som SHA-familien, bare med et helt annet mål: å være treg og minnekrevende, ikke rask.

Kort oppsummert: Argon2id er hybridvarianten IETF anbefaler som førstevalg for de fleste, Argon2d gir best motstand mot GPU-kløyving men lekker informasjon gjennom tidsbruk, og Argon2i er den opprinnelige sidekanalsikre varianten som i praksis er forbigått av Argon2id til nesten alt nytt arbeid. Under ser du hvorfor det skillet ikke er kosmetisk, og hvilken variant som passer til hvilken jobb. Vi går gjennom spesifikasjonene, ekte benchmarktall fra tre uavhengige kilder, en praktisk migreringsguide og en liste over feil utviklere gjentatte ganger gjør når de setter opp Argon2 i produksjon.

Bakgrunn: fra Password Hashing Competition til IETF-standard

Password Hashing Competition startet i 2013 som svar på en rekke store passordlekkasjer der hashfunksjoner som MD5 og rå SHA-256 viste seg å knekkes altfor raskt med grafikkort. Målet var en minnehard funksjon som gjorde det dyrt å bygge spesialisert maskinvare for knekking. Argon2, laget av Alex Biryukov, Daniel Dinu og Dmitry Khovratovich, vant i juli 2015 og ble referansepunktet for moderne passordhashing.

Konkurransen samlet over tjue innsendte kandidatalgoritmer fra kryptografimiljøet internasjonalt, og juryen vurderte både motstand mot spesialisert knekkemaskinvare og praktisk ytelse på vanlig serverutstyr. At Argon2 gikk seirende ut, handlet ikke om at algoritmen var raskest, den var i mange konfigurasjoner tregere enn konkurrentene, men om at den ga utviklere finkornet kontroll over nøyaktig hvor mye minne, tid og parallellisme en angriper måtte matche for å knekke et passord. Den kontrollen er selve grunnen til at algoritmen fortsatt er relevant over ti år senere, mens flere av konkurrentene fra samme konkurranse i praksis er glemt. Se gjerne bakgrunnsstoffet om kryptografi for en bredere innføring i hvordan hashfunksjoner og nøkkelutledning henger sammen med resten av det kryptografiske verktøysettet.

Algoritmen ble ikke levert som én løsning, men som tre varianter med ulik minnetilgang. Det tok seks år før IETF formaliserte anbefalingen. I Internet-Draft for Argon2, utarbeidet av IETFs Crypto Forum Research Group (CFRG) og senere utgitt som RFC 9106, slås det fast: “Argon2 has one primary variant: Argon2id and two supplementary variants: Argon2d and Argon2i.” (Norsk: «Argon2 har én primær variant: Argon2id, og to supplerende varianter: Argon2d og Argon2i.») Kilde: IETF CFRG, Internet-Draft for Argon2. Det er dette skiftet, fra tre likestilte varianter til én anbefalt standard med to spesialtilfeller, som gjør at valget i 2026 ser annerledes ut enn i 2015.

Argon2d: datastyrt minnetilgang og GPU-motstand

Argon2d henter minneblokker basert på verdier utledet fra selve passordet og mellomregningene. Adressene som algoritmen slår opp, avhenger altså av dataene den behandler. Det gjør mønsteret uforutsigbart for en angriper som prøver å bygge en generisk krets for parallell knekking, siden hver kandidat følger en litt annen minnebane.

Argon2-prosjektets egen nettside oppsummerer styrken slik: “Argon2d provides the highest resistance against GPU cracking attacks.” (Norsk: «Argon2d gir høyest motstand mot GPU-baserte knekkeangrep.») Kilde: Argon2, offisiell prosjektside. Prisen for denne motstanden er at minnetilgangsmønsteret kan avsløre informasjon om input gjennom timing, cache-bruk eller strømforbruk, dersom en angriper får kjøre kode på samme maskinvare eller måle systemet direkte. Det gjør Argon2d mindre egnet der en lokal eller delt tjener kan overvåkes av en motpart, men svært egnet der det ikke finnes noen realistisk sidekanal, som i proof-of-work-systemer eller antibot-utfordringer der GPU-motstand er selve poenget og ingen tredjepart måler serverens interne tilstand.

Argon2i: dataubunden tilgang for sidekanalbeskyttelse

Argon2i går motsatt vei. Minneadressene bestemmes uavhengig av passordet og de hemmelige mellomverdiene, så tilgangsmønsteret ser identisk ut uansett hva som hashes. Det fjerner nesten hele grunnlaget for timing- og cache-baserte sidekanalangrep, siden en observatør ikke kan lese noe nyttig ut av hvilke minneadresser som besøkes.

Argon2-prosjektet formulerer det slik: “Argon2i is designed to resist side-channel attacks.” (Norsk: «Argon2i er designet for å motstå sidekanalangrep.») Kilde: Argon2, offisiell prosjektside. Kostnaden er at forutsigbare minneadresser gjør algoritmen mer sårbar for såkalte time-memory tradeoff-angrep (TMTO), der en angriper bevisst bruker mindre minne mot mer regnetid for å presse ned totalkostnaden. WorkOS’ utviklerveiledning fra 2026 peker på nøyaktig denne avveiningen: Argon2i var lenge anbefalt for passordhashing nettopp fordi sidekanaler var hovedbekymringen, men er i dag svakere mot time-memory-tradeoff-angrep sammenlignet med de andre variantene. Kilde: WorkOS, «Picking a password hash».

Argon2id: hybridmodellen bak dagens standardvalg

Argon2id kombinerer de to andre i én kjøring. Den bruker Argon2i-tilnærmingen i første halvdel av det første minnegjennomløpet, og bytter til Argon2d-tilnærmingen for resten. IETF CFRG beskriver mekanismen presist: “Argon2id works as Argon2i for the first half of the first pass over the memory, and as Argon2d for the rest, thus providing both side-channel attack protection and brute-force cost savings due to time-memory tradeoffs.” (Norsk: «Argon2id fungerer som Argon2i i første halvdel av det første gjennomløpet over minnet, og som Argon2d for resten, og gir dermed både beskyttelse mot sidekanalangrep og redusert kostnadsgevinst for angripere via time-memory-tradeoff.») Kilde: IETF CFRG, Internet-Draft for Argon2.

Logikken er at den mest sårbare fasen for sidekanallekkasje, tidlig i beregningen når mellomverdiene er mest forutsigbare, kjøres med Argon2is trygge mønster. Den senere fasen, der en angriper uansett har mindre å hente på timing, kjøres med Argon2ds datastyrte mønster for å presse opp kostnaden ved parallell maskinvareknekking. Resultatet er en variant som ikke er best i noen enkeltkategori, men som er godt sikret på begge fronter samtidig. Det er derfor OWASP, PHP, libsodium og de fleste moderne rammeverk har landet på Argon2id som forvalgt variant.

Argon2-parametere forklart: minne, tid og parallellisme

Uansett hvilken variant du velger, styres den faktiske sikkerheten og ytelsen av tre innstillbare parametere. Å velge riktig variant uten å forstå disse tre, gir liten gevinst, siden en svakt konfigurert Argon2id kan ende opp svakere enn en riktig konfigurert Argon2i.

Minnekost (m)

Minnekostnaden angir hvor mye arbeidsminne algoritmen skal allokere under beregningen, typisk oppgitt i kibibyte eller mebibyte. Dette er den viktigste parameteren for å hindre GPU- og ASIC-akselerert knekking, fordi spesialisert maskinvare har mye mindre minne per regneenhet enn en vanlig server-CPU. Jo mer minne som kreves per hashberegning, desto færre parallelle forsøk kan en angriper kjøre samtidig på samme maskinvarebudsjett. RFC 9106 opererer med to ytterpunkter: 2 GiB for miljøer med god kapasitet, og 64 MiB for ressursbegrensede miljøer.

Tidskost (t)

Tidskostnaden angir hvor mange ganger algoritmen går gjennom hele minneblokken. Flere gjennomløp øker regnetiden lineært, men gir mindre sikkerhetsgevinst per krone i infrastrukturkostnad enn å øke minnet, fordi ekstra iterasjoner er billige å parallellisere for en angriper med nok minne tilgjengelig. Derfor anbefaler de fleste 2026-guidene å prioritere minne først og bruke tidskost som finjustering for å treffe en ønsket svartid, typisk mellom 100 og 500 millisekunder for interaktiv innlogging.

Parallellisme (p)

Parallellisme bestemmer hvor mange uavhengige tråder eller “baner” algoritmen deler minnet mellom under beregningen. Høyere parallellisme lar en legitim server bruke flere CPU-kjerner til å redusere responstid for hver innlogging, men det gir samtidig en angriper som har tilgang til tilsvarende maskinvare, samme fordel. RFC 9106s anbefalte alternativer bruker begge p=4 som utgangspunkt, en verdi som balanserer serverytelse mot at parameteren ikke skal gjøre parallell knekking billigere enn nødvendig.

Spesifikasjonstabell: Argon2d, Argon2i og Argon2id side om side

Tabellen under samler egenskapene som faktisk avgjør hvilken variant som passer et gitt system, hentet fra IETF-spesifikasjonen, Argon2-prosjektets egen dokumentasjon og offentlig kjent implementasjonsstatus i utbredt programvare.

EgenskapArgon2dArgon2iArgon2id
MinnetilgangsmønsterDatastyrt (data-dependent)Dataubundet (data-independent)Hybrid: dataubundet først, datastyrt deretter
Motstand mot GPU/ASIC-knekkingHøyestLavere enn Argon2dNær Argon2d i andre halvdel
Motstand mot sidekanalangrepSvakestSterkestSterk i første halvdel av kjøringen
Sårbar for time-memory tradeoff (TMTO)Nei, i liten gradJa, mer enn de andreRedusert sammenlignet med Argon2i alene
Status i RFC 9106 (IETF CFRG)Supplerende variantSupplerende variantPrimær, anbefalt variant
Del av Password Hashing Competition-vinneren (2015)JaJaJa
Standard i libsodium crypto_pwhashNeiNei (eldre standard før v1.0.15)Ja, siden libsodium 1.0.15
Tilgjengelig i PHP password_hash()NeiJa, PASSWORD_ARGON2I (PHP 7.2+)Ja, PASSWORD_ARGON2ID (PHP 7.3+)
OWASP-anbefaling for passordlagringIkke førstevalgIkke førstevalgFørstevalg
Typisk bruksområdeProof-of-work, mining, antibot uten sidekanaltrusselHistorisk passordhashing, sidekanalfølsomme miljøerPassordhashing, nøkkelutledning for kryptering, generell KDF
Anbefalt av Argon2-prosjektet for de flesteNei, spesialtilfelleNei, spesialtilfelleJa

Ytelse og benchmarks: sykluser per byte og minnekostnad

Rå hastighet er ikke poenget med Argon2, poenget er at algoritmen skal koste nok CPU- og minnetid til å gjøre masseknekking uøkonomisk. Likevel er ytelsestall nyttige for å forstå hvordan de tre variantene faktisk oppfører seg under identiske forhold. UnitWorks’ offentlige Argon2-benchmarkrepo har målt Argon2d og Argon2i under flere minnestørrelser og trådtall, med resultater i sykluser per byte (cpb, lavere er raskere):

Konfigurasjon (minne, iterasjoner, tråder)Argon2d (cpb)Argon2i (cpb)
1 MiB, 1 iterasjon, 1 tråd5,914,64
1 MiB, 1 iterasjon, 2 tråder2,762,87
4 096 MiB, 1 iterasjon, 2 tråder2,152,15
4 096 MiB, 1 iterasjon, 4 tråder1,792,72

Kilde: UnitWorks, Argon2-benchmarkrepo på GitHub. Legg merke til at forholdet mellom variantene snur avhengig av oppsettet. Ved lite minne og én tråd er Argon2i faktisk raskere enn Argon2d, mens ved store minnemengder og fire tråder er Argon2d raskere. Det bekrefter et poeng utviklerguiden fra Deepak Gupta gjentar for 2026-anbefalinger: resultater fra Argon2-benchmarker avhenger av CPU-modell, implementasjon, kompilator, minnebåndbredde, trådtall, operativsystem og parametervalg, og bør derfor aldri leses som en universell fasit uten at maskinvaren er spesifisert. Kilde: Deepak Gupta, «The Complete Guide to Password Hashing» (2026).

En tredje kilde bekrefter mønsteret fra en annen vinkel. En komparativ studie av nøkkelutledningsfunksjoner i SQLCipher, som brukes til databasekryptering i mobilapper, målte hvordan Argon2id-latens endrer seg når minnekostnaden økes med fast tidskostnad (t=1). Ved å heve minnet fra 46 MiB til 64 MiB steg beregningstiden fra 39,494 ms til 55,599 ms, en økning på om lag 40,8 prosent for en drøy tredjedels økning i minne. Kilde: «A Comparative Analysis of PBKDF2 and Argon2id as Key Derivation Functions in SQLCipher», akademisk studie fra 2026. Det illustrerer at minnekostnaden, ikke iterasjonstallet, er den dominerende bremsen i Argon2-familien, noe som er selve designintensjonen bak minneharde funksjoner.

Ressurs- og driftskostnad: hva parameterne faktisk koster

Argon2 er gratis og åpen kildekode, så det finnes ingen lisenskostnad å sammenligne. Den reelle kostnaden ligger i minnet og CPU-tiden hver hashberegning legger beslag på, og det er en driftskostnad som skalerer direkte med antall innlogginger. Gupta-guiden fra 2026 gir konkrete referansepunkter for Argon2id ved ulike parametersett:

ParametersettMinneIterasjoner (t)Målt latensRessurskostnad
Minimum (OWASP-terskel)19 MiB2ca. 100–150 msLav
Anbefalt for de fleste46 MiB1ca. 150–200 msMiddels
Testet middelsoppsett64 MiB3ca. 250 msMiddels til høy
Høy sikkerhet128 MiB3ca. 300–500 msHøy
RFC 9106, første anbefalte alternativ2 GiB (2^21 KiB)1, p=4Avhenger av maskinvareSvært høy, krever dedikert serverkapasitet
RFC 9106, andre anbefalte alternativ (ressursbegrenset)64 MiB (2^16 KiB)3, p=4Avhenger av maskinvareMiddels, egnet for delt hosting

Kilde: Deepak Gupta, «The Complete Guide to Password Hashing» (2026) og IETF CFRG, Internet-Draft for Argon2. Den praktiske konsekvensen: hver innlogging med RFC 9106s førstevalg krever 2 GiB minne allokert et kort øyeblikk. På en autentiseringstjeneste med mange samtidige innlogginger blir dette raskt en kapasitetsplanleggingssak, ikke bare et sikkerhetsvalg. Derfor lander de fleste produksjonssystemer på 46–128 MiB, som holder svartiden under et halvt sekund uten å kreve spesialtilpasset serverkapasitet.

Sikkerhet: sidekanalangrep, GPU-er og time-memory-tradeoff

De tre truslene som faktisk skiller variantene fra hverandre er verdt å holde fra hverandre. Sidekanalangrep utnytter at en angriper kan observere systemet mens det regner, gjennom cache-timing, strømforbruk eller delt CPU i sky-miljøer med flere leietakere. Dette er trusselen Argon2i er bygget for å nøytralisere, fordi minnemønsteret aldri avslører noe om input.

GPU- og ASIC-basert masseknekking er en annen trussel, der angriperen ikke observerer den ekte serveren, men i stedet bygger sin egen maskinvare for å prøve millioner av kandidatpassord parallelt. Her er datastyrt minnetilgang en fordel, fordi spesialisert maskinvare ikke lenger kan forhåndsberegne eller cache minnemønstre effektivt på tvers av forsøk. Det er derfor Argon2d topper GPU-motstand i praktisk testing.

Time-memory-tradeoff er den tredje og mest tekniske trusselen. En angriper reduserer minnebruken bevisst mot å bruke mer regnetid, og håper totalkostnaden blir lavere enn den tiltenkte kostnaden. Forutsigbare minnemønstre, som i Argon2i, gjør denne typen optimalisering enklere for en angriper å regne ut på forhånd. Argon2ds datastyrte tilgang gjør TMTO-angrep vesentlig dyrere å planlegge, siden angriperen ikke vet hvilke minneblokker som trengs før beregningen faktisk kjører. Argon2id arver denne beskyttelsen for den datastyrte halvdelen av kjøringen, noe som er hovedgrunnen til at IETF fremhever hybridvariantens reduserte kostnadsgevinst for angripere via time-memory-tradeoff.

I praksis møter de fleste utviklere alle tre truslene i varierende grad gjennom systemets levetid, ikke bare én av dem isolert. Et system som starter som en enkel intern applikasjon uten delt infrastruktur, kan noen år senere flyttes til en delt skyplattform der sidekanaltrusselen plutselig blir reell. Det er en av grunnene til at Argon2id, som dekker begge trusler samtidig, har blitt et tryggere standardvalg enn å optimalisere hardt for kun én av dem fra start. Det er verdt å skille mellom trusselen mot systemet og trusselen mot brukeren. Et system som lagrer passordhasher, bør uansett aldri stå alene som forsvarslinje. God passordsikkerhet handler like mye om lange, unike passord og tofaktorautentisering som om hvilken hashalgoritme baksystemet bruker. Argon2-variantene beskytter systemet mot hva som skjer etter et databaseinnbrudd, altså hvor dyrt det blir for angriperen å gå fra stjålne hasher til klartekstpassord. De erstatter ikke behovet for grunnleggende sikkerhetshygiene på applikasjonsnivå, som hastighetsbegrensning på innloggingsforsøk og varsling ved mistenkelig aktivitet.

Reelle eksempler: hvem bruker hvilken variant

Valget mellom variantene er ikke bare teoretisk. Flere store, offentlig dokumenterte systemer har allerede tatt stilling:

  • OWASP Password Storage Cheat Sheet peker på Argon2id som førstevalg for passordlagring, med konkrete minimumsparametere for produksjonsbruk. Anbefalingen er bevisst formulert som et gulv, ikke et tak, og oppfordrer team med kapasitet til overs om å øke minnekostnaden utover minimum. Kilde: OWASP Cheat Sheet Series.
  • RFC 9106, utarbeidet av IETFs Crypto Forum Research Group, formaliserer Argon2id som primær variant og plasserer Argon2d og Argon2i som supplerende spesialtilfeller for henholdsvis GPU-tunge og sidekanalfølsomme scenarier. Dokumentet er den kilden implementasjoner i praksis følger når de skal avgjøre standardvariant.
  • PHP har hatt innebygd støtte for PASSWORD_ARGON2I i den native funksjonen password_hash() siden PHP 7.2, og la til PASSWORD_ARGON2ID i PHP 7.3. I praksis anbefaler PHP-dokumentasjonen ID-varianten for nye prosjekter, og eldre kodebaser som fortsatt spesifiserer ARGON2I eksplisitt, gjør det stort sett av historiske årsaker snarere enn en aktiv sikkerhetsvurdering.
  • Libsodium, kryptobiblioteket som brukes i alt fra meldingsapper til passordbehandlere, har latt crypto_pwhash() bruke Argon2id som standardalgoritme siden versjon 1.0.15, etter tidligere å ha brukt Argon2i. Byttet skjedde uten at de fleste kallere av API-et måtte endre egen kode, siden biblioteket abstraherer bort variantvalget bak et enkelt funksjonskall.
  • Mobil databasekryptering, som i SQLCipher-studien nevnt over, bruker Argon2id spesifikt som nøkkelutledningsfunksjon for å utlede krypteringsnøkler fra brukerens passord før selve databasen låses opp. Her spiller batteriforbruk og enhetens ofte begrensede minne inn som en ekstra avveining sammenlignet med en server i et datasenter.
  • Proof-of-work- og antibot-systemer uten reell sidekanaleksponering, der målet primært er å gjøre GPU-basert automatisering dyr, er blant de få gjenværende områdene der ren Argon2d fortsatt gir mening fremfor hybridvarianten, nettopp fordi hele designmålet er maksimal maskinvaremotstand og ingen ekstern part kan måle systemets interne tilstand.

Hva standardene og prosjektet selv sier

Fremfor å tolke variantene ut fra sekundærkilder, er det verdt å gå til de to primærkildene direkte: Argon2-prosjektets egen dokumentasjon og IETF-spesifikasjonen som senere ble til RFC 9106.

“Argon2d provides the highest resistance against GPU cracking attacks.”

Argon2, offisiell prosjektside (argon2.com)

Norsk oversettelse: «Argon2d gir høyest motstand mot GPU-baserte knekkeangrep.»

“Argon2i is designed to resist side-channel attacks.”

Argon2, offisiell prosjektside (argon2.com)

Norsk oversettelse: «Argon2i er designet for å motstå sidekanalangrep.»

“Argon2 has one primary variant: Argon2id and two supplementary variants: Argon2d and Argon2i.”

IETF CFRG, Internet-Draft for Argon2 (datatracker.ietf.org)

Norsk oversettelse: «Argon2 har én primær variant: Argon2id, og to supplerende varianter: Argon2d og Argon2i.» Denne formuleringen fra selve spesifikasjonsteksten er trolig den klareste offisielle bekreftelsen på hvordan status har endret seg siden 2015, da alle tre variantene ble presentert som likeverdige valg.

“Argon2id works as Argon2i for the first half of the first pass over the memory, and as Argon2d for the rest, thus providing both side-channel attack protection and brute-force cost savings due to time-memory tradeoffs.”

IETF CFRG, Internet-Draft for Argon2 (datatracker.ietf.org)

Norsk oversettelse: «Argon2id fungerer som Argon2i i første halvdel av det første gjennomløpet over minnet, og som Argon2d for resten, og gir dermed både beskyttelse mot sidekanalangrep og redusert kostnadsgevinst for angripere via time-memory-tradeoff.» Denne enkeltsetningen er trolig den mest siterte forklaringen på hvorfor Argon2id har blitt normen fremfor de to opprinnelige variantene.

Bruksområder: når bør du velge hver variant

Med spesifikasjonene og kildene på plass, er spørsmålet hvilken variant som faktisk passer til et konkret system. Her er seks scenarier og anbefalt valg for hvert av dem:

  • Passordlagring i webapplikasjoner: Argon2id, med minst 19 MiB minne og t=2 som absolutt bunnlinje, gjerne 46–64 MiB i produksjon. Dette er standardbruken OWASP, PHP og libsodium alle peker mot, og det er scenarioet flest team faktisk står overfor.
  • Proof-of-work eller antibot-utfordringer uten ekstern måling av serveren: Argon2d, fordi GPU-motstanden er selve funksjonen og det ikke finnes noen realistisk sidekanal å beskytte mot. Her vil et bytte til Argon2id gi unødvendig kompleksitet uten en tilsvarende sikkerhetsgevinst.
  • Databasekryptering i mobilapper (nøkkelutledning fra passord): Argon2id, tunet mot enhetens tilgjengelige minne og batteribudsjett, slik SQLCipher-studien demonstrerer med målbare millisekundtall. Parameterne bør testes på det svakeste enhetsutvalget appen faktisk støtter, ikke bare på et utviklerflaggskip.
  • Autentiseringstjenester på delt eller flerleietaker skyinfrastruktur: Argon2id, fordi delt CPU-kapasitet øker risikoen for sidekanalobservasjon fra naboprosesser, noe ren Argon2d ikke beskytter mot. Dette gjelder særlig for team som kjører på delte kubernetes-noder eller rimelige delte VM-er.
  • Høyverdimål som hemmelighetsforvaltning og finansielle systemer: Argon2id konfigurert etter RFC 9106s første anbefalte alternativ (2 GiB, t=1, p=4), forutsatt at infrastrukturen tåler minnekostnaden per verifisering. Slike systemer verifiserer typisk langt sjeldnere enn en vanlig innloggingsside, så den høyere kostnaden per kall er lettere å forsvare.
  • Ressursbegrensede miljøer som IoT-enheter eller delt hosting: Argon2id etter RFC 9106s andre anbefalte alternativ (64 MiB, t=3, p=4), som gir mesteparten av sikkerhetsgevinsten uten å kreve gigabyte-store minneallokeringer som enheten eller hostingplanen rett og slett ikke har tilgjengelig.

Mønsteret er tydelig. I fem av seks scenarier vinner Argon2id. Argon2d forblir relevant kun når sidekanaltrusselen reelt sett er fraværende, og ren Argon2i har i praksis ingen scenarier igjen der den slår Argon2id, siden hybridvarianten arver mesteparten av sidekanalbeskyttelsen uten å arve hele TMTO-svakheten.

Migreringsguide: fra Argon2i eller Argon2d til Argon2id

Mange systemer bygget før 2020 kjører fortsatt ren Argon2i, eller i sjeldnere tilfeller Argon2d, fordi det var standardvalget i biblioteker den gangen. Å bytte til Argon2id krever ikke en massiv rearkitektur, men bør gjøres gradvis for å unngå å låse ute eksisterende brukere. Den vanligste fellen er å bytte variant i koden og anta at eksisterende hasher automatisk blir sikrere, noe de ikke gjør. En lagret Argon2i-hash forblir en Argon2i-hash helt til brukeren faktisk logger inn på nytt og trigger en rehash, uansett hva applikasjonskoden skriver for nye passord fra og med i dag.

  1. Kartlegg hvilken Argon2-variant og hvilke parametere (m, t, p) som er i bruk i dag, direkte fra koden eller konfigurasjonen, ikke fra antakelser.
  2. Bekreft at kryptobiblioteket støtter Argon2id. Libsodium 1.0.15 og nyere, samt PHP 7.3 og nyere, gjør det som standard.
  3. Velg målparametere basert på RFC 9106s andre anbefalte alternativ (64 MiB, t=3, p=4) som et forsvarlig utgangspunkt for de fleste webtjenester.
  4. Implementer et rehash-on-login-mønster: behold eksisterende hasher som de er, men når en bruker logger inn med riktig passord, regn ut en ny Argon2id-hash og lagre den i stedet.
  5. Merk hver lagret hash med hvilken variant og hvilke parametere den ble laget med, slik at systemet vet om en rehash er nødvendig ved neste innlogging.
  6. Test ytelsespåvirkningen i et separat miljø før produksjon. Mål p95- og p99-latens for innloggingsendepunktet, ikke bare gjennomsnitt.
  7. Rull ut endringen til en liten andel av trafikken først, og overvåk CPU- og minnebruk på autentiseringstjenerne under reell last.
  8. Øk andelen gradvis mens du følger med på feilrater og responstider, spesielt under samtidige innloggingstopper som etter et strømbrudd eller en større utsendelse.
  9. Sett en tidsfrist for når gamle Argon2i- eller Argon2d-hasher tvangsoppgraderes, for eksempel ved neste passordbytte, selv for brukere som sjelden logger inn.
  10. Oppdater dokumentasjon, sikkerhetsrevisjonsrapporter og interne retningslinjer slik at Argon2id står som gjeldende standard, ikke bare i koden.

For team som fortsatt bruker eldre algoritmer som bcrypt eller PBKDF2, gjelder samme rehash-on-login-mønster, men da bør Argon2id velges direkte som mål fra start. Det er unødvendig å gå innom Argon2i eller Argon2d som mellomsteg.

Et enkelt eksempel i PHP viser hvor lite kode selve byttet krever:

// Hash med Argon2id og RFC 9106s andre anbefalte alternativ
$hash = password_hash($passord, PASSWORD_ARGON2ID, [
    'memory_cost' => 65536, // 64 MiB
    'time_cost'   => 3,
    'threads'     => 4,
]);

// Verifiser og rehash automatisk ved behov
if (password_verify($passord, $lagretHash)) {
    if (password_needs_rehash($lagretHash, PASSWORD_ARGON2ID, [
        'memory_cost' => 65536, 'time_cost' => 3, 'threads' => 4,
    ])) {
        $nyHash = password_hash($passord, PASSWORD_ARGON2ID, [
            'memory_cost' => 65536, 'time_cost' => 3, 'threads' => 4,
        ]);
        // lagre $nyHash i databasen
    }
}

Tilsvarende finnes i libsodium for andre språk, der crypto_pwhash() med standardparametere allerede peker mot Argon2id uten at utvikleren trenger å spesifisere variant manuelt. For Node.js-team som migrerer fra eldre KDF-er, finnes det tilsvarende oppskrifter for scrypt-passordhashing i Node.js som kan brukes som mal for hvordan et rehash-on-login-mønster settes opp i praksis, selv om selve algoritmen byttes ut med Argon2id.

Argon2id mot bcrypt, scrypt og PBKDF2: hvor Argon2-familien står i 2026

Argon2-variantene konkurrerer ikke bare mot hverandre. De konkurrerer også mot eldre nøkkelutledningsfunksjoner som fortsatt er i utbredt bruk. Bcrypt er CPU-hard, men i praksis lite minnekrevende, noe som gjør den mer sårbar for spesialisert GPU- og FPGA-maskinvare enn Argon2. PBKDF2 stiller knapt noen minnekrav i det hele tatt, og regnes i dag som den svakeste av de fire mot moderne knekkemaskinvare, selv om den fortsatt kreves i enkelte eldre compliance-standarder. Scrypt var det første utbredte forsøket på en minnehard funksjon og ligner Argon2 i designfilosofi, men manglet den finjusterte kontrollen over minne, tid og parallellisme hver for seg som Argon2-familien introduserte.

For lesere som vil se disse sammenligningene i detalj med egne benchmarktall, dekker Argon2 vs bcrypt vs PBKDF2 forskjellene mellom algoritmefamiliene, mens scrypt vs Argon2 går dypere inn i forskjellen mellom de to minneharde tilnærmingene. Poenget i denne artikkelen er snevrere: gitt at du allerede har bestemt deg for Argon2 som algoritmefamilie, hvilken av de tre interne variantene bør du faktisk bruke. Svaret endrer seg ikke av at Argon2 vinner mot bcrypt, scrypt og PBKDF2, det er fortsatt Argon2id som bør stå bak det svaret i nesten alle tilfeller.

Fordeler og ulemper ved hver variant

Ingen av de tre variantene er objektivt “best”. Hver av dem er et bevisst kompromiss mellom to trusler som sjelden er like alvorlige samtidig i et gitt system. Oppsummeringen under er ment å brukes sammen med spesifikasjonstabellen lenger opp, ikke som en frittstående fasit.

Argon2d

  • Fordel: Best målt GPU- og ASIC-motstand blant de tre variantene.
  • Fordel: Sterkest beskyttelse mot time-memory-tradeoff-angrep.
  • Ulempe: Svakest mot sidekanalangrep, siden minnemønsteret avslører informasjon om input.
  • Ulempe: Ikke anbefalt av OWASP eller RFC 9106 som førstevalg for passordlagring.

Argon2i

  • Fordel: Sterk beskyttelse mot sidekanalangrep gjennom hele kjøringen.
  • Fordel: Historisk anbefalt og fortsatt støttet av eldre systemer og biblioteker.
  • Ulempe: Mer sårbar for time-memory-tradeoff-angrep enn de andre variantene.
  • Ulempe: Forbigått av Argon2id i nesten alle offisielle anbefalinger etter RFC 9106.

Argon2id

  • Fordel: Kombinerer sidekanalbeskyttelse og GPU-motstand i samme kjøring.
  • Fordel: Offisielt anbefalt av IETF (RFC 9106) og OWASP, og standard i libsodium og PHP.
  • Fordel: Bredest bibliotekstøtte av de tre variantene i 2026.
  • Ulempe: Ikke like sterk mot ren GPU-knekking som Argon2d isolert sett, siden bare halve kjøringen bruker det datastyrte mønsteret.
  • Ulempe: Krever like mye minneplanlegging som de andre variantene. Hybridkonstruksjonen gjør den ikke billigere å kjøre.

Konklusjon: hvilken Argon2-variant vinner i 2026

Basert på IETF-spesifikasjonen, Argon2-prosjektets egen dokumentasjon og de uavhengige benchmarkene gjennomgått over, er svaret entydig for de fleste: Argon2id. RFC 9106 plasserer den som primær variant, OWASP anbefaler den som førstevalg for passordlagring, og både PHP og libsodium har gjort den til standardvalg i sine kjernebiblioteker. Ingen av kildene i denne gjennomgangen peker på et scenario der ren Argon2i er å foretrekke fremfor Argon2id i nytt arbeid, og forskjellen mellom variantene handler i 2026 mest om hvor bevisst man er på hvorfor man eventuelt velger noe annet enn standardanbefalingen.

Argon2d beholder en smal, men reell nisje: systemer der GPU-motstand er hele poenget og ingen tredjepart kan observere serverens interne tilstand, som visse proof-of-work-mekanismer. For alt annet, passordhashing, nøkkelutledning til kryptering, autentisering på delt infrastruktur, er hybridvariantens kombinasjon av sidekanalbeskyttelse og time-memory-tradeoff-motstand vanskelig å argumentere mot. Velg Argon2id med minst RFC 9106s andre anbefalte alternativ (64 MiB, t=3, p=4) som et forsvarlig minimum, og skaler opp minnekostnaden dersom infrastrukturen tåler det.

Vanlige feil ved implementering av Argon2

Selv med riktig variant valgt, ser man de samme implementasjonsfeilene gå igjen i kodegjennomganger, uavhengig av om teamet har landet på Argon2d, Argon2i eller Argon2id. Å velge riktig algoritme løser lite hvis konfigurasjonen rundt den er svak. Disse er verdt å sjekke uavhengig av hvilken variant systemet bruker:

  • Gjenbruk av samme salt for alle brukere. Argon2 krever et unikt, tilfeldig salt per hash. Et delt eller forutsigbart salt gjør det mulig å bygge en forhåndsberegnet oppslagstabell (rainbow table) for hele brukerbasen samtidig, noe som opphever nesten hele poenget med minnehard hashing.
  • For lave parametere for å “spare CPU”. Å senke minnekostnaden under OWASPs anbefalte minimum på 19 MiB for å kutte serverlast, flytter i praksis kostnaden fra egen infrastruktur til angriperens fordel, siden lavere minnekrav gjør parallell knekking billigere per forsøk.
  • Ingen plan for rehash-on-login. Systemer som velger parametere én gang og aldri oppdaterer dem, sitter igjen med stadig svakere beskyttelse etter hvert som maskinvare blir billigere. Uten et mønster for å oppgradere eksisterende hasher gradvis, krever en fremtidig oppgradering enten et fullstendig passordnullstillingsvarsel til alle brukere eller at man lever med utdaterte parametere på ubestemt tid.
  • Feil variant valgt av vane fremfor trusselbilde. Å kopiere Argon2i-kode fra et gammelt eksempel uten å vurdere om Argon2id nå er tilgjengelig i biblioteket, er en av de vanligste årsakene til at systemer henger igjen på en supplerende variant lenge etter at hovedanbefalingen endret seg.
  • Å måle ytelse kun på utviklermaskinen. Latenstall varierer betydelig mellom en bærbar utviklermaskin og en delt, virtualisert produksjonsserver. Parametere som gir 200 millisekunder lokalt, kan gi vesentlig lengre svartid under reell samtidig last i produksjon.
  • Å ignorere parallellisme-parameteren helt. Mange implementasjoner setter p=1 som standard uten å vurdere om serverens tilgjengelige kjerner kunne vært brukt til å redusere brukeropplevd ventetid uten å svekke sikkerheten, siden p også påvirker hvor mye samlet arbeid en angriper må gjøre.

Ofte stilte spørsmål

Hva er den viktigste forskjellen på Argon2d, Argon2i og Argon2id?
Forskjellen ligger i minnetilgangsmønsteret. Argon2d bruker datastyrt tilgang for maksimal GPU-motstand, Argon2i bruker dataubundet tilgang for maksimal sidekanalbeskyttelse, og Argon2id kombinerer begge i én kjøring.

Hvilken Argon2-variant bør jeg bruke til passordhashing?
Argon2id, som anbefalt av RFC 9106 og OWASP. Det er også standardvalget i libsodium siden versjon 1.0.15 og i PHPs password_hash() siden versjon 7.3.

Er Argon2id tregere enn Argon2d eller Argon2i?
Ikke nødvendigvis. UnitWorks’ benchmarker viser at forholdet mellom Argon2d og Argon2i i sykluser per byte snur avhengig av minnestørrelse og trådtall, og Argon2id arver ytelseskarakteristikken til begge i sine respektive faser av kjøringen.

Støtter PHP og Python Argon2id?
Ja. PHP har hatt PASSWORD_ARGON2ID i password_hash() siden PHP 7.3. Python-økosystemet støtter Argon2id gjennom biblioteker som argon2-cffi, som flere webrammeverk bruker til passordhashing.

Hvordan migrerer jeg fra Argon2i eller Argon2d til Argon2id?
Bruk et rehash-on-login-mønster: behold eksisterende hasher urørt, men regn ut en ny Argon2id-hash hver gang en bruker logger inn med riktig passord, og lagre den nye hashen i stedet. Se migreringsguiden over for full steg-for-steg-prosess.

Er Argon2d fortsatt relevant i 2026?
Ja, men i en smal nisje. Den passer systemer der GPU-motstand er hovedmålet og det ikke finnes noen realistisk sidekanaltrussel, som enkelte proof-of-work-mekanismer. For passordlagring generelt er Argon2id å foretrekke.

Hvor mye minne bør jeg sette av til Argon2id?
RFC 9106 anbefaler enten 2 GiB (t=1, p=4) for systemer med god kapasitet, eller 64 MiB (t=3, p=4) som et ressursbegrenset alternativ. OWASPs absolutte minimum ligger på 19 MiB med t=2.

Er Argon2 fortsatt sikrere enn bcrypt og PBKDF2?
Argon2, spesielt Argon2id, regnes som den mest minneharde og dermed mest maskinvareresistente av de utbredte algoritmene, fordi bcrypt og PBKDF2 ikke stiller like høye krav til minne under beregningen. Det er hovedgrunnen til at Argon2 vant Password Hashing Competition i 2015 og senere ble IETF-standardisert gjennom RFC 9106. En mer detaljert gjennomgang av tallene finner du i sammenligningen mellom Argon2, bcrypt og PBKDF2 lenger opp i artikkelen.

Kan jeg fortsette å bruke Argon2d hvis systemet mitt allerede kjører det i produksjon?
Det avhenger av trusselbildet. Hvis systemet lagrer passord eller andre hemmeligheter der en angriper realistisk kan observere serveren, bør du planlegge en overgang til Argon2id. Hvis bruksområdet er et proof-of-work- eller antibot-scenario uten sidekanaleksponering, er det ingen umiddelbar grunn til å bytte bare for byttets skyld.

Hva skjer hvis jeg velger feil Argon2-variant for systemet mitt?
Konsekvensen er sjelden et umiddelbart brudd, men en svekket sikkerhetsmargin. Å bruke Argon2d på en tjeneste eksponert for sidekanalmåling, øker risikoen for at en angriper med lokal tilgang eller delt infrastruktur kan lese ut informasjon om passordforsøk gjennom timing. Å bruke ren Argon2i der GPU-motstand er avgjørende, gir en angriper med spesialisert maskinvare en billigere vei inn enn nødvendig. Begge feilene er langt mindre alvorlige enn å bruke en algoritme uten minnehardhet i det hele tatt, men begge er unødvendige gitt at Argon2id er tilgjengelig i nesten alle moderne biblioteker.