Passordhashing er en av de tingene utviklere setter opp én gang og så aldri rører igjen. Problemet er at “én gang” ofte betyr et bibliotek som var moderne i 2016, med parametre ingen har justert siden. To algoritmer dominerer fortsatt diskusjonen om hvordan passord skal lagres trygt i 2026: scrypt, laget av Colin Percival i 2009, og Argon2, vinneren av Password Hashing Competition i 2015. Begge er minneharde, begge er gratis og åpen kildekode, og begge dukker opp i OWASP sin Password Storage Cheat Sheet. Men de er ikke likestilte lenger. Denne artikkelen går gjennom hva som faktisk skiller dem, med tall fra OWASP, IETF-standarden RFC 9106 og Colin Percivals egen scrypt-artikkel, pluss en konkret migreringsguide for team som fortsatt kjører eldre oppsett.

Hva er scrypt og Argon2 – kort fortalt

Begge algoritmene løser samme grunnproblem: en rask hashfunksjon som SHA-256 er elendig til å beskytte passord, fordi en angriper med en GPU-rigg kan prøve milliarder av kombinasjoner i sekundet. Løsningen er å gjøre hashingen bevisst treg og, viktigere, bevisst minnekrevende. Det er her begrepet “minnehard” kommer inn. En algoritme som krever 64 MiB RAM per hash-operasjon er langt vanskeligere å parallellisere på spesialbygd maskinvare enn en som bare krever CPU-sykluser, fordi minne er dyrt å skalere opp i tusenvis av parallelle enheter på en ASIC eller FPGA.

Dette skillet mellom “raske” og “trege, minneharde” hashfunksjoner er selve fundamentet i moderne passordlagring. En generisk kryptografisk hashfunksjon som SHA-256 eller MD5 er designet for å være så rask som mulig, fordi den brukes til ting som integritetssjekk av filer og digitale signaturer, der hastighet er en fordel. Brukt direkte på passord blir den samme hastigheten en sikkerhetsrisiko: en enkelt moderne GPU kan regne ut milliarder av SHA-256-hasher i sekundet, noe som gjør et ordbokangrep eller brute-force-forsøk mot en stjålet hash-database til en jobb på timer i stedet for år. Scrypt og Argon2id løser dette ved å gjøre selve beregningen avhengig av store mengder tilfeldig minneaksess, noe som ikke lar seg akselerere på samme måte med enkel, masseparallell maskinvare.

Scrypt ble designet av Colin Percival, opprinnelig for backup-tjenesten Tarsnap, og beskrevet i hans papir “Stronger Key Derivation via Sequential Memory-Hard Functions”. Målet var å gjøre det økonomisk ulønnsomt å bygge egendefinert maskinvare for å knekke passord, ved å tvinge angriperen til å bruke like mye minne som den legitime brukeren. Algoritmen ble senere standardisert av IETF som RFC 7914 i 2016.

Argon2 kom seks år senere og vant Password Hashing Competition i 2015, en åpen konkurranse der kryptografimiljøet sammen skulle finne etterfølgeren til bcrypt og PBKDF2. Algoritmen har tre varianter: Argon2d (rask, sårbar for sidekanalangrep, brukt til proof-of-work), Argon2i (motstandsdyktig mot sidekanalangrep, men svakere mot rene brute-force-angrep) og Argon2id, en hybrid som bruker Argon2i-tilnærmingen i første halvdel av minnegjennomgangen og Argon2d i resten. Argon2 ble senere formalisert av IETFs Crypto Forum Research Group som RFC 9106 i 2021. I praksis er det Argon2id som er relevant i 2026 – både OWASP og RFC 9106 sier eksplisitt at det er denne varianten man skal bruke til passordlagring.

Spesifikasjonstabell: scrypt mot Argon2id

Tabellen under samler de tekniske egenskapene som faktisk betyr noe når man skal velge algoritme for et nytt system, eller vurdere om et gammelt oppsett bør oppgraderes.

EgenskapscryptArgon2id
DesignerColin PercivalAlex Biryukov, Daniel Dinu, Dmitry Khovratovich
Utgitt20092015
KonkurransehistorikkIngen formell konkurranseVinner av Password Hashing Competition, 2015
IETF-standardRFC 7914 (2016)RFC 9106 (2021)
Antall varianterÉn (ingen undervarianter)Tre: Argon2d, Argon2i, Argon2id
OWASP-status 2026Fallback når Argon2id ikke er tilgjengeligFørstevalg for passordlagring
Justerbare parametreN (minnekost), r (blokkstørrelse), p (parallellitet)m (minne), t (iterasjoner), p (parallellitet)
OWASP anbefalt minne (ett alternativ)N=2^16, r=8, p=2 (64 MiB)m=19456 KiB, t=2, p=1 (19 MiB)
RFC-anbefalt “førstevalg”Ikke definert i RFC 7914t=1, p=4, m=2 GiB (RFC 9106)
SidekanalresistensIkke designet for detteJa, hybrid-design fra Argon2i-delen
Motstand mot GPU/ASICGod, ren minnehard konstruksjonGod, minnehard med justerbar parallellitet
Brukt til proof-of-work i kryptovalutaJa (Litecoin, Dogecoin)Nei, ingen større kryptovaluta bruker Argon2id som PoW
Innebygd i Node.jsJa, via crypto.scrypt()Nei, krever npm-pakken argon2
Støtte i PHPIkke innebygd i password_hash()Ja, PASSWORD_ARGON2ID siden PHP 7.3.0

OWASP sine anbefalte parametre i 2026

OWASP sin Password Storage Cheat Sheet er den mest siterte praktiske referansen for hvordan man faktisk skal konfigurere disse algoritmene, og teksten er tydelig på rangeringen: “Argon2id should be the best choice for password hashing” og “scrypt should be used when the former is not available.” Det er ikke en nyansert anbefaling – Argon2id er default, scrypt er reserveløsningen.

For Argon2id gir OWASP fem likeverdige parametersett, der forskjellen er en avveining mellom CPU og RAM-bruk, ikke sikkerhetsnivå:

  • m=47104 (46 MiB), t=1, p=1
  • m=19456 (19 MiB), t=2, p=1
  • m=12288 (12 MiB), t=3, p=1
  • m=9216 (9 MiB), t=4, p=1
  • m=7168 (7 MiB), t=5, p=1

For scrypt gir cheatsheeten et tilsvarende sett med fem alternativer:

  • N=2^17 (128 MiB), r=8, p=1
  • N=2^16 (64 MiB), r=8, p=2
  • N=2^15 (32 MiB), r=8, p=3
  • N=2^14 (16 MiB), r=8, p=5
  • N=2^13 (8 MiB), r=8, p=10

Legg merke til at scrypt-alternativene generelt krever mer minne (8–128 MiB) enn de fleste Argon2id-alternativene (7–46 MiB) for et sammenlignbart forsvarsnivå ifølge cheatsheeten. Det er en direkte konsekvens av at Argon2id fordeler arbeidet mer effektivt mellom minnebruk og iterasjoner. RFC 9106 går enda lenger og foreslår, for de som ikke vil skreddersy noe selv, enten t=1, p=4, m=2 GiB (kalt “FIRST RECOMMENDED option” i teksten) for backend-tjenere med god maskinvare, eller t=3, p=4, m=64 MiB (“SECOND RECOMMENDED option”) når minne er mer begrenset. Det er betydelig tyngre enn OWASP sine laveste alternativer, og viser at IETF-standarden er skrevet med tanke på servere som håndterer autentisering som eneste jobb, ikke delte containere med trangt minnebudsjett. Den fullstendige teksten finnes i RFC 9106 hos RFC Editor, mens scrypt sin opprinnelige spesifikasjon ligger i RFC 7914, som aldri fikk et like detaljert sett med bruksscenario-anbefalinger.

Ytelse og beregningstid: hva koster en innlogging?

Tallene fra RFC 9106 gir et konkret bilde av hva “treg nok” faktisk betyr i praksis. IETF-dokumentet beskriver en referansekonfigurasjon for “backend server authentication” som tar 0,5 sekunder på en 2 GHz CPU med 4 kjerner, ved bruk av Argon2id med 8 lanes og 4 GiB RAM. For “frontend server authentication” er tallet også 0,5 sekunder, men med bare 2 kjerner og 1 GiB RAM. Til sammenligning beskriver samme dokument en kryptomining-konfigurasjon (Argon2d, ikke Argon2id) på 0,1 sekunder med 2 lanes og 250 MB RAM – lavere krav fordi trusselmodellen der er en annen.

For scrypt finnes det ikke et tilsvarende offisielt tidsbudsjett i RFC 7914, men bransjeguider som refererer til OWASP-parametrene i 2026 oppgir typisk 100–150 millisekunder per hash ved de vanligste konfigurasjonene, mens Argon2id på tilsvarende maskinvare typisk lander et sted mellom titalls millisekunder og rundt 100 ms, avhengig av hvilket av de fem OWASP-alternativene som velges. Poenget er ikke at det ene tallet er dramatisk lavere enn det andre – begge algoritmene er designet for å ligge i et område der en legitim bruker knapt merker forsinkelsen, mens en angriper som prøver millioner av passord blir kraftig bremset. Forskjellen ligger heller i hvor forutsigbart og finjusterbart tidsbudsjettet er: Argon2id sine tre uavhengige parametre (minne, tid, parallellitet) gir mer presis kontroll over hvor kostnaden legges, enn scrypt sine tre parametre (N, r, p), der N øker eksponentielt og gjør finjustering brattere.

Kostnadstabell: lisens, drift og skalering

Ingen av algoritmene koster penger i lisens – begge er åpen kildekode og patentfrie. Den reelle kostnaden ligger i CPU- og minnebruk på autentiseringsserverne, som skalerer direkte med antall innlogginger. Tabellen under viser hvordan dette henger sammen med praktisk drift.

KostnadsfaktorscryptArgon2id
LisenskostnadIngen (åpen kildekode)Ingen (åpen kildekode)
Minneoverhead per hash (laveste OWASP-alternativ)8 MiB7 MiB
Minneoverhead per hash (RFC/høyeste sikkerhetsnivå)128 MiB (høyeste OWASP-alternativ)Opptil 4 GiB (RFC 9106, backend-server)
Typisk CPU-tid per innlogging~100–150 ms~titalls ms – 100 ms (OWASP), 0,5 s (RFC 9106 backend-profil)
Native avhengighet nødvendig?Nei i Node.js (innebygd i crypto), ja i mange andre språkJa, som regel via C-bindinger (argon2 npm, argon2-cffi)
Kostnad ved skyskaleringLav ekstra kompleksitet, men høyere minnebruk per instans ved høye sikkerhetsnivåerLavere minnebruk ved sammenlignbar sikkerhet, men krever byggeverktøy for native moduler i CI/CD

For team som kjører store containerflåter i Norden, med instanser i AWS eu-north-1 (Stockholm) eller Azures Norge-regioner, er minneforbruk per prosess ofte den reelle kostnadsdriveren, siden det påvirker hvor mange autentiseringsforespørsler som kan kjøre parallelt per node uten å presse opp instansstørrelsen. Argon2id sin finere kontroll over minneparameteren gjør det lettere å holde seg innenfor et fast minnebudsjett per pod i Kubernetes, mens scryptens N-parameter dobler minnebruken for hvert trinn oppover og gir mindre presise steg.

Sidekanalsikkerhet og designfilosofi

Her ligger den klareste tekniske forskjellen. Scrypt har ett minneaksessmønster som ikke ble designet med tanke på timing-sidekanaler – det var ikke en del av trusselmodellen i 2009. Argon2 derimot ble bygget med tre varianter nettopp for å gi utviklere et valg: Argon2d for rå ytelse mot GPU/ASIC uten sidekanalhensyn (typisk for kryptovaluta-mining der angriperen ikke deler maskinvare med offeret), Argon2i for miljøer der en angriper kan observere cache-tilgangsmønstre, og Argon2id som en hybrid RFC 9106 beskriver slik: “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 trade-offs.”

RFC 9106 er også eksplisitt om når man bør velge det ene over det andre: “Argon2d is optimized for settings where the adversary does not get regular access to system memory or CPU… These settings are more typical for backend servers and cryptocurrency minings,” mens “Argon2id is optimized for more realistic settings, where the adversary can possibly access the same machine, use its CPU, or mount cold-boot attacks.” For de aller fleste webapplikasjoner, der passordhashen lagres på en server en angriper i verste fall får delvis tilgang til, er det nettopp denne “mer realistiske” trusselmodellen som gjelder – og det er derfor Argon2id, ikke Argon2d eller scrypt, er standardanbefalingen i 2026.

Hvor kommer tallene fra: tre uavhengige kilder

Én vanlig svakhet i artikler om kryptografiske algoritmer er at alle tallene stammer fra én eneste bloggpost som siterer en annen bloggpost. Denne sammenligningen bygger i stedet på tre uavhengige, primære kilder som sjelden er uenige med hverandre, men som dekker forskjellige deler av bildet. Den første er OWASP sin Password Storage Cheat Sheet, som er praktikerens referanse – den sier ikke hvorfor tallene er som de er, bare hvilke parametersett som gir et forsvarlig sikkerhetsnivå i dag. Den andre er RFC 9106, IETF sin formelle standardisering av Argon2, som gir den teoretiske begrunnelsen og konkrete tidsbudsjetter for ulike trusselmodeller (frontend, backend, diskkryptering, kryptomining). Den tredje er Colin Percivals opprinnelige forskningsartikkel om scrypt, “Stronger Key Derivation via Sequential Memory-Hard Functions”, som la det matematiske grunnlaget for hvorfor minnehardhet i det hele tatt gir en økonomisk fordel mot spesialbygd angrepsmaskinvare.

Det er verdt å merke seg hvor lite disse tre kildene faktisk strides om. Ingen av dem hevder at scrypt er usikkert eller at Argon2id har en kjent svakhet. Uenigheten, i den grad man kan kalle det det, handler utelukkende om presisjon og fleksibilitet i parameterkontroll, samt hvor godt algoritmen er tilpasset moderne trusselbilder som cold-boot-angrep og delt CPU-tilgang i skymiljøer. Det er nettopp derfor bransjen har landet på Argon2id som anbefalt førstevalg uten at scrypt av den grunn blir avskrevet som utrygt.

Kort om bcrypt og PBKDF2: hvorfor de ikke er med i hovedsammenligningen

Lesere som har fulgt passordhashing-debatten en stund vil legge merke til at bcrypt og PBKDF2 ikke er hovedtema her, selv om begge også nevnes i OWASP sin cheatsheet. Grunnen er enkel: verken bcrypt eller PBKDF2 er minneharde i noen reell forstand. Bcrypt bruker en fast, liten mengde minne uansett hvor høyt man skrur work factor-parameteren, mens PBKDF2 ikke bruker minne som forsvarsmekanisme i det hele tatt – den er ren CPU-iterasjon. Det gjør begge langt mer sårbare for GPU- og ASIC-akselererte angrep enn scrypt og Argon2id, som begge tvinger angriperen til å bruke betydelige mengder RAM per gjettet passord. OWASP plasserer da også bcrypt som en løsning kun for “legacy systems where Argon2 and scrypt are not available.” Vi har gått grundig gjennom nettopp den treveis-sammenligningen mellom Argon2, bcrypt og PBKDF2 i en tidligere analyse, og denne artikkelen bygger videre på den ved å sette Argon2id opp mot det andre reelt minnaeharde alternativet: scrypt.

Personvern og regelverk: hvorfor algoritmevalget har juridisk vekt i Norden

Valg av hashingalgoritme er sjelden noe som havner direkte i en juridisk tekst, men det har likevel praktisk betydning for hvordan norske og nordiske virksomheter oppfyller kravene i personvernforordningen (GDPR) og NIS2-direktivet, som ble innført som digitalsikkerhetsloven i Norge. Begge regelverkene krever at virksomheter implementerer “passende tekniske og organisatoriske tiltak” for å beskytte personopplysninger, og et passord er i praksis den mest sensitive personopplysningen de fleste tjenester lagrer i det hele tatt. Datatilsynet og tilsvarende nordiske tilsynsmyndigheter ser i praksis til anerkjente bransjestandarder som OWASP når de vurderer om en virksomhet har gjort nok etter et datainnbrudd. Å kunne dokumentere at man følger OWASP sin anbefalte konfigurasjon for Argon2id, fremfor en egendefinert eller utdatert hashingløsning, er dermed ikke bare en teknisk detalj – det er også et konkret bevis på aktsomhet dersom en virksomhet noen gang må redegjøre for sikkerhetsrutinene sine etter et brudd.

For virksomheter som allerede har gjennomført en risikovurdering av autentiseringsløsningen sin som en del av NIS2-arbeidet, er algoritmevalg og parameterkonfigurasjon for passordhashing et konkret, avgrenset punkt som er relativt billig å rette opp sammenlignet med mye annet sikkerhetsarbeid. Det krever verken ny maskinvare eller organisasjonsendringer – bare et bevisst valg av bibliotek og en migreringsplan for eksisterende brukerdata, slik vi beskriver senere i denne artikkelen.

Reelle eksempler på bruk i produksjon

Teori er fint, men det er bruken i faktiske systemer som viser hvor de to algoritmene faktisk lander i praksis.

Litecoin og Dogecoin: scrypt som proof-of-work

Litecoin, lansert i 2011 som en “lettere” avlegger av Bitcoin, valgte scrypt som proof-of-work-algoritme nettopp for å gjøre spesialbygd mining-maskinvare (ASIC-er) dyrere å bygge enn for Bitcoins SHA-256. Dogecoin, som ble forket fra Litecoins kodebase, arvet det samme valget. Dette er den mest kjente storskala-bruken av scrypt utenfor passordhashing, og illustrerer godt hvorfor algoritmen fortsatt lever videre selv om den ikke lenger er OWASP sitt førstevalg til nye passordsystemer – den gjør fortsatt jobben sin som minnehard proof-of-work-funksjon i et helt annet bruksområde.

Django: Argon2 som anbefalt hasher

Django, et av de mest brukte webrammeverkene i Python-økosystemet, tilbyr Argon2PasswordHasher som en innebygd klasse for utviklere som ønsker å bruke Argon2 til passordlagring, og dokumentasjonen beskriver den som det anbefalte valget når den underliggende argon2-cffi-pakken er installert. Dette er et konkret eksempel på hvordan Argon2id har flyttet fra forskningsmiljøet og inn i standard webutvikling.

PHP: PASSWORD_ARGON2ID i password_hash()

PHP la til støtte for PASSWORD_ARGON2ID i password_hash() i versjon 7.3.0, ifølge PHPs offisielle dokumentasjon. Det gjorde Argon2id tilgjengelig som et innebygd alternativ ved siden av bcrypt, uten at utviklere trengte tredjeparts-biblioteker. Scrypt har aldri fått en tilsvarende plass i PHPs kjernefunksjon for passordhashing.

Node.js: innebygd scrypt mot ekstern Argon2

Node.js sin innebygde crypto-modul har hatt scrypt som en native funksjon (crypto.scrypt()) i mange versjoner, dokumentert i det offisielle Node.js API-referanseverket. Argon2 er derimot ikke innebygd i Node.js core – utviklere må installere en ekstern pakke som krever en native C++-binding kompilert mot systemets byggeverktøy, i motsetning til Node sin egen crypto-modul som fungerer rett ut av boksen. For prosjekter med strenge krav til minimale avhengigheter eller vanskelige CI/CD-miljøer uten kompileringsverktøy, er dette en praktisk grunn til at scrypt fortsatt velges i Node.js-baserte backends selv i 2026. Den offisielle referanseimplementasjonen av Argon2 selv, vedlikeholdt av vinnerteamet fra Password Hashing Competition, ligger åpent tilgjengelig på GitHub og er grunnlaget de fleste språkbindinger bygger videre på.

Kryptovaluta-lommebøker basert på Litecoin-kodebasen

Programvare som er forket fra eller kompatibel med Litecoin og Dogecoins nodeimplementasjoner arver scrypt-avhengigheten direkte i konsensuslaget, siden hele nettverkets sikkerhet hviler på at mining-noder bruker samme proof-of-work-funksjon. Det gjør scrypt til en algoritme som ikke bare lever videre i nisje-passordsystemer, men er dypt forankret i infrastrukturen til flere aktive blokkjeder.

Fordeler og ulemper

scrypt

  • Fordel: Innebygd i Node.js sin crypto-modul, ingen ekstra avhengighet nødvendig.
  • Fordel: Lang fartstid (siden 2009) og bred implementasjonsstøtte i mange språk og biblioteker, inkludert OpenSSL.
  • Fordel: Bevist i storskala gjennom bruk som proof-of-work i Litecoin og Dogecoin siden 2011.
  • Ulempe: Ikke designet med sidekanalresistens som mål.
  • Ulempe: OWASP klassifiserer den nå som fallback, ikke førstevalg.
  • Ulempe: Grovere justeringssteg siden N-parameteren skalerer eksponentielt.

Argon2id

  • Fordel: OWASP sitt uttalte førstevalg for ny passordlagring i 2026.
  • Fordel: Hybrid sidekanalresistens gjennom design (Argon2i-del + Argon2d-del).
  • Fordel: Standardisert i IETF RFC 9106 med klare, testede referansekonfigurasjoner.
  • Fordel: Innebygd støtte i PHP (siden 7.3.0) og som anbefalt hasher i Django.
  • Ulempe: Ikke innebygd i Node.js core – krever ekstern npm-pakke med native bindinger.
  • Ulempe: Byggekompleksitet i enkelte CI/CD- og container-miljøer på grunn av native avhengigheter.

Bruksområder: når bør du velge hva

Valget avhenger i stor grad av hva slags system som skal beskyttes og hvilke tekniske begrensninger som allerede finnes i stacken.

  • Nye webapplikasjoner og SaaS-produkter: Argon2id, i tråd med OWASP sin førsteanbefaling. Dette bør være standardvalget for ethvert prosjekt som starter fra scratch i 2026.
  • Eldre systemer uten tilgang til Argon2-biblioteker: scrypt som fallback, nøyaktig slik OWASP-cheatsheeten anbefaler når Argon2id ikke er tilgjengelig i miljøet.
  • Kryptovaluta-nettverk og proof-of-work: scrypt, etter modell fra Litecoin og Dogecoin, der målet er å gjøre spesialbygd mining-maskinvare dyrere.
  • Node.js-prosjekter uten native byggeverktøy i produksjonsmiljøet: scrypt via den innebygde crypto-modulen, for å unngå avhengighet av kompilerte native moduler.
  • Systemer med strenge krav til sidekanalresistens (for eksempel identitetsplattformer i offentlig sektor eller finanssektoren): Argon2id, på grunn av det hybride designet.
  • Nøkkelderivering for diskkryptering: RFC 9106 gir en egen referansekonfigurasjon for dette (Argon2id, 4 lanes, 6 GiB RAM, ca. 3 sekunder), som viser at Argon2 er designet fleksibelt nok til å dekke mer enn bare innloggingssider.
  • Legacy Java- eller .NET-systemer der Argon2-biblioteker mangler modenhet: scrypt kan fortsatt være et pragmatisk mellomsteg før full migrering.

Migreringsguide: fra scrypt til Argon2id

De fleste team kan ikke bare bytte hash-algoritme over natten, siden eksisterende passordhasher i databasen ikke kan konverteres uten at brukeren skriver inn passordet sitt på nytt. Løsningen er en gradvis migrering som skjer i takt med at brukerne logger inn.

  1. Kartlegg dagens scrypt-parametre (N, r, p) og hvor mange brukere som har passord lagret med det gamle skjemaet.
  2. Velg et Argon2-bibliotek som passer stacken: argon2-cffi for Python, argon2 npm-pakken for Node.js, eller PHPs innebygde PASSWORD_ARGON2ID.
  3. Sett OWASP-anbefalte startparametre, for eksempel m=19456 (19 MiB), t=2, p=1, og juster etter faktisk serverkapasitet.
  4. Legg til et versjonsfelt i databasen slik at hver lagret hash vet hvilken algoritme og parametersett den ble generert med.
  5. Ved innlogging: verifiser først mot det gamle scrypt-skjemaet dersom hash-feltet indikerer det, og hvis passordet stemmer, regner du umiddelbart ut en ny Argon2id-hash og lagrer den i stedet (“lazy migration”).
  6. Last-test den nye Argon2id-konfigurasjonen under realistisk samtidighet før den rulles ut i produksjon, siden minnekravet påvirker hvor mange parallelle innlogginger en instans tåler.
  7. Overvåk innloggingslatens og feilrate de første ukene, og juster t- eller m-parameteren om nødvendig.
  8. Sett en frist for gjenværende scrypt-hasher, for eksempel seks til tolv måneder, og tving passordtilbakestilling for kontoer som ikke har logget inn innen fristen.

Denne fremgangsmåten unngår tvungen passordtilbakestilling for hele brukermassen samtidig, og sprer beregningskostnaden av migreringen ut over tid i stedet for å skape en lastpigg.

Rollback-plan hvis noe går galt

Enhver migrering av autentiseringslogikk bør ha en definert reverseringsvei. Fordi lazy migration bevarer det opprinnelige scrypt-skjemaet for brukere som ikke har logget inn ennå, er den enkleste rollback-strategien rett og slett å slå av skrivingen av nye Argon2id-hasher og la verifiseringslogikken falle tilbake til å kun sjekke mot scrypt-feltet, uten å slette noe. Det er derfor kritisk at man aldri fjerner det gamle scrypt-hash-feltet fra databaseskjemaet før alle aktive brukere har fått en ny Argon2id-hash generert, og gjerne ikke før man har hatt minst én full faktureringssyklus eller driftsperiode uten insidenter etter at migreringen ble aktivert. Et enkelt trafikklys-flagg i konfigurasjonen, som lar teamet slå Argon2id-skriving av og på uten en ny utrulling, gjør denne typen rollback til et spørsmål om minutter i stedet for timer.

Kodeeksempel: Argon2id i Node.js

Et enkelt eksempel på hvordan Argon2id kan implementeres med npm-pakken argon2, med parametre i tråd med OWASP sitt anbefalte alternativ på 19 MiB minne:

const argon2 = require('argon2');

async function hashPassord(passord) {
  return await argon2.hash(passord, {
    type: argon2.argon2id,
    memoryCost: 19456, // 19 MiB, jf. OWASP-anbefaling
    timeCost: 2,
    parallelism: 1
  });
}

async function verifiserPassord(hash, passord) {
  return await argon2.verify(hash, passord);
}

Og det tilsvarende scrypt-eksempelet med Node.js sin innebygde crypto-modul, med et av OWASP sine anbefalte parametersett:

const crypto = require('crypto');

function hashPassordScrypt(passord, salt) {
  return new Promise((resolve, reject) => {
    crypto.scrypt(passord, salt, 64, {
      N: 2 ** 16, // 64 MiB
      r: 8,
      p: 2
    }, (err, derivedKey) => {
      if (err) reject(err);
      resolve(derivedKey.toString('hex'));
    });
  });
}

Biblioteker og språkstøtte i 2026

Hvor moden støtten for hver algoritme er i det språket teamet ditt allerede bruker, avgjør ofte valget mer enn den rene sikkerhetsanalysen gjør. Tabellen under oppsummerer situasjonen for de mest brukte språkene og rammeverkene i 2026.

Språk/rammeverkscrypt-støtteArgon2id-støtte
Node.jsInnebygd via crypto.scrypt()Ekstern pakke med native C++-binding
PHPIkke innebygd i password_hash()Innebygd via PASSWORD_ARGON2ID siden PHP 7.3.0
PythonInnebygd i hashlib siden Python 3.6Tredjepartspakken argon2-cffi
Gogolang.org/x/crypto/scryptgolang.org/x/crypto/argon2
JavaTilgjengelig via Bouncy CastleArgon2PasswordEncoder i Spring Security
Django (Python)Ikke standard hasherArgon2PasswordHasher, anbefalt siden Django 2.0
.NETTilgjengelig via tredjepartsbibliotekerTilgjengelig via tredjepartsbiblioteker, ikke i standardbiblioteket

Mønsteret som går igjen er at scrypt oftere er innebygd i språkets kjernebibliotek (Node.js, Python), mens Argon2id oftere krever et eksternt, men svært mye brukt, tredjepartsbibliotek. Det er ikke et sikkerhetsargument i seg selv, men det påvirker hvor mye ekstra oppsett og avhengighetshåndtering et team må ta stilling til før algoritmen kan tas i bruk i produksjon.

Vanlige feil ved implementasjon

Selv med riktig algoritme valgt, går mange systemer galt på detaljer rundt implementasjonen. Det vanligste feilgrepet er å kopiere parametre fra en artikkel eller et Stack Overflow-svar uten å teste dem mot egen serverkapasitet – et parametersett som er trygt på en dedikert server med 8 GiB ledig RAM, kan velte en delt container med strengt minnebudsjett. Et annet gjentakende problem er å glemme unik salt per passord; både scrypt og Argon2id krever en tilfeldig, unik salt for hver hash, ellers mister man beskyttelsen mot precomputed rainbow-tables som er hele poenget med saltingen. Team bør også unngå å lagre passordhashen uten et versjonsfelt som identifiserer hvilken algoritme og hvilke parametre som ble brukt – uten det blir en fremtidig migrering langt vanskeligere å gjennomføre trygt.

En fjerde fallgruve er å sette parallellitetsparameteren (p) høyere enn antall tilgjengelige CPU-kjerner på autentiseringsserveren. Både scrypt og Argon2id bruker p til å dele arbeidet mellom flere kjerner samtidig, men hvis serveren bare har to virtuelle kjerner tilgjengelig og parameteren er satt til åtte, får man ikke den forventede tidsbruken – man får bare kø og unødvendig ventetid for brukeren. En femte, mer subtil feil er å bruke variabel sammenligningstid når man verifiserer om en innsendt hash matcher den lagrede. Standardbibliotekene for både scrypt og Argon2 håndterer dette riktig internt, men egenskrevne verifiseringsrutiner som bruker en vanlig strengsammenligning (som `==` i stedet for en konstant-tid-sammenligning) kan lekke informasjon om hvor mange tegn som stemte, gjennom hvor lang tid sammenligningen tok.

Skalering i skyen: hva betyr valget for Kubernetes og containere i Norden

Norske og nordiske team som kjører autentiseringstjenester i Kubernetes, enten på AWS, Azure eller Google Cloud sine nordiske regioner, må sette minnegrenser (memory limits) på hver pod. Dette er der forskjellen mellom scrypt og Argon2id blir konkret operasjonell, ikke bare teoretisk. Hvis en pod har en minnegrense på for eksempel 512 MB og skal håndtere flere samtidige innlogginger, må utvikleren regne ut verste-fall minnebruk: antall samtidige forespørsler multiplisert med minnekostnaden per hash-operasjon. Med scrypt sin N-parameter, som dobler minnebruken for hvert trinn (2^13 til 2^17 i OWASP sin tabell), blir denne beregningen brattere å justere presist enn med Argon2id sin m-parameter, som kan settes i mer finmaskede steg (7 168 til 47 104 KiB i OWASP sine fem alternativer).

Det praktiske rådet for team som autoskalerer autentiseringstjenesten sin er å sette et hardt tak på antall samtidige hash-operasjoner per pod, uavhengig av hvilken algoritme som brukes, og heller skalere antall pod-replikaer horisontalt enn å øke minnegrensen per pod i det uendelige. Dette gjelder likt for begge algoritmene, men blir enklere å resonnere om med Argon2id sine mer granulære parametre.

Slik kalibrerer du dine egne parametre i stedet for å kopiere en tabell

Tabellene fra OWASP og RFC 9106 er gode utgangspunkt, men den beste praksisen er å kalibrere parametrene mot den faktiske maskinvaren autentiseringstjenesten din kjører på, ikke bare kopiere et tall fra en artikkel. Fremgangsmåten er den samme uansett om du velger scrypt eller Argon2id: sett deg et mål for maksimal responstid ved innlogging, for eksempel 250–500 millisekunder, og øk deretter minneparameteren (m for Argon2id, N for scrypt) gradvis mens du måler faktisk beregningstid på produksjonslik maskinvare, ikke på utviklerens bærbare PC. Stopp når du nærmer deg målet ditt, og legg inn litt margin for at produksjonsserveren kan være mer belastet enn under testing.

Denne fremgangsmåten er spesielt viktig fordi maskinvaren i skyinstanser varierer mye. En ARM-basert instans i en nordisk skyregion kan ha en annen minnebåndbredde enn en tilsvarende x86-instans, og det påvirker hvor mange millisekunder en gitt Argon2id- eller scrypt-konfigurasjon faktisk tar. Begge RFC 9106 og OWASP-cheatsheeten er tydelige på at tallene deres er referansepunkter for “2 GHz CPU” eller generiske moderne servere, ikke garantier som gjelder uendret på enhver skyinstans. Bygg derfor alltid inn en enkel selvtest i utrullingsprosessen som logger faktisk hash-tid på den konkrete maskinvaren applikasjonen kjører på, slik at avvik oppdages før de påvirker brukeropplevelsen i stor skala.

Verdikt: hvilken bør du velge i 2026

Basert på dataene over er svaret ganske entydig for de fleste nye prosjekter. OWASP sin Password Storage Cheat Sheet er direkte i formuleringen: Argon2id er førstevalget, scrypt er reserveløsningen når Argon2id ikke kan brukes. RFC 9106 underbygger dette med konkrete, testede referansekonfigurasjoner for flere scenarioer – frontend-autentisering, backend-autentisering og til og med diskkryptering – noe scrypt sin opprinnelige RFC 7914 ikke tilbyr i samme detaljnivå. Samtidig er scrypt langt fra dødt: det lever videre som en solid, velprøvd algoritme i Node.js sin kjernebibliotek, og som selve grunnmuren i proof-of-work-konsensusen til Litecoin og Dogecoin.

For norske og nordiske utviklingsteam som bygger nye tjenester i 2026, er den praktiske konklusjonen: start med Argon2id og OWASP sine anbefalte parametre, med mindre du har en konkret teknisk begrensning (for eksempel et Node.js-miljø uten native byggeverktøy) som gjør scrypt til det mer pragmatiske valget. Sitter du på et eldre system med scrypt allerede i produksjon, er det ingen akutt sikkerhetskrise – men en gradvis migrering til Argon2id, slik beskrevet i migreringsguiden over, er den anbefalte veien videre.

Det er også verdt å huske at dette valget ikke er statisk. Password Hashing Competition som ga oss Argon2 ble avsluttet i 2015, og det tok flere år før Argon2id ble den brede standardanbefalingen den er i 2026. Kryptografimiljøet fortsetter å analysere begge algoritmene, og OWASP oppdaterer cheatsheeten sin når nye funn eller bedre maskinvaremotstand tilsier det. Det praktiske rådet er derfor ikke bare “velg Argon2id og glem det”, men snarere å bygge inn et versjonsfelt og en migreringsvei fra dag én, slik at neste algoritmeskifte – uansett hva det måtte bli – ikke krever samme mengde arbeid som denne sammenligningen har lagt opp en plan for.

Kort oppsummert: begge algoritmene er trygge nok til produksjonsbruk i 2026 når de konfigureres etter offisielle anbefalinger. Forskjellen ligger i presisjon, sidekanalresistens og hvor godt de passer inn i stacken du allerede har, ikke i om den ene er “knekt” og den andre ikke.

Ofte stilte spørsmål

Er scrypt usikkert sammenlignet med Argon2id?
Nei, scrypt regnes ikke som usikkert eller knekket. OWASP lister den fortsatt som et godkjent alternativ for passordlagring. Forskjellen er at Argon2id gir bedre sidekanalresistens og mer presis parameterkontroll, ikke at scrypt har en kjent svakhet.

Må jeg migrere fra scrypt til Argon2id umiddelbart?
Nei. Hvis systemet ditt allerede bruker scrypt med fornuftige OWASP-parametre, er det ingen akutt grunn til å haste gjennom en migrering. En gradvis, lazy migration ved innlogging er den tryggeste fremgangsmåten.

Hvorfor bruker Litecoin og Dogecoin scrypt i stedet for Argon2?
Litecoin ble lansert i 2011, fire år før Argon2 vant Password Hashing Competition i 2015. Proof-of-work-algoritmen er en del av konsensusprotokollen og kan ikke byttes ut uten en hard fork som alle noder må godta.

Hvilken Argon2-variant skal jeg bruke: Argon2d, Argon2i eller Argon2id?
RFC 9106 er tydelig: “Argon2id MUST be supported by any implementation of this document.” For passordhashing i vanlige webapplikasjoner er Argon2id riktig valg i nesten alle tilfeller, siden den kombinerer egenskapene fra de to andre variantene.

Er scrypt innebygd i Node.js, mens Argon2 ikke er det?
Ja. Node.js sin crypto-modul har hatt scrypt innebygd i mange versjoner. Argon2 krever installasjon av en ekstern npm-pakke med native C++-bindinger.

Hvor mye minne bør jeg sette av til Argon2id på en vanlig webserver?
OWASP tilbyr fem likeverdige alternativer fra 7 MiB til 46 MiB, avhengig av hvor mye CPU-tid du vil bruke i stedet. RFC 9106 sin backend-anbefaling ligger langt høyere, opp mot 4 GiB, men er ment for dedikerte autentiseringstjenere, ikke delte containere.

Kan jeg bruke Argon2id til diskkryptering, ikke bare passord?
Ja. RFC 9106 gir en egen referansekonfigurasjon for nøkkelderivering til harddiskkryptering, med høyere minnebruk (6 GiB) og lengre beregningstid (ca. 3 sekunder) enn ved vanlig passordautentisering.

Hva skjer om jeg bruker for lave parametre på Argon2id eller scrypt?
Begge algoritmene mister mye av sin beskyttende effekt hvis minnekravet settes for lavt, siden hele poenget er å gjøre det dyrt i minne å prøve mange passordkombinasjoner parallelt. Følg et av de fem sett OWASP-alternativene som et minimum, ikke egne, uprøvde verdier.

Påvirker valget av hashingalgoritme om vi oppfyller NIS2 eller GDPR?
Regelverket navngir ikke spesifikke algoritmer, men krever “passende tekniske tiltak” for å beskytte personopplysninger. Å kunne dokumentere bruk av en anerkjent, oppdatert standard som Argon2id med OWASP-anbefalte parametre styrker en virksomhets sak dersom den må redegjøre for sikkerhetsrutinene sine etter et databrudd.

Kan jeg kjøre både scrypt og Argon2id i samme system samtidig?
Ja, og dette er nettopp normalsituasjonen under en migrering. Så lenge databasen lagrer hvilken algoritme og hvilke parametre hver enkelt hash ble generert med, kan verifiseringslogikken støtte begge formatene parallelt frem til alle brukere er migrert over.