{"id":154,"date":"2026-06-20T20:46:09","date_gmt":"2026-06-20T20:46:09","guid":{"rendered":"https:\/\/shattered.io\/dk\/2026\/06\/20\/scrypt-password-hashing-nodejs\/"},"modified":"2026-06-20T20:47:55","modified_gmt":"2026-06-20T20:47:55","slug":"scrypt-password-hashing-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/dk\/scrypt-password-hashing-nodejs\/","title":{"rendered":"Scrypt i Node.js: sikker password-hashing i 12 trin [2026]"},"content":{"rendered":"\n

Scrypt er den mest hukommelseskr\u00e6vende standard for password-hashing, og Node.js har underst\u00f8ttet den via det indbyggede node:crypto<\/code>-modul siden version 10.5.0. Algoritmen blev designet til at g\u00f8re GPU- og ASIC-angreb 10-100 gange dyrere end bcrypt, fordi den kr\u00e6ver op til 128 MB RAM per hash. Denne guide viser dig pr\u00e6cis, hvordan du implementerer scrypt korrekt i Node.js, trin for trin, fra installation til produktionsklar kode med Express, PostgreSQL og en komplet testpakke.<\/p>\n\n\n\n

Hvad er scrypt, og hvorfor bruge det i 2026?<\/h2>\n\n\n\n

Scrypt er en password-baseret n\u00f8gleafledningsfunktion (PBKDF), designet af Colin Percival og offentliggjort i 2009. Den er standardiseret i RFC 7914<\/a> og er i dag brugt i Litecoin (proof-of-work), WPA3-netv\u00e6rk (Wi-Fi-n\u00f8gleafledning) og adskillige open source password-managere. Tricket er, at scrypt ikke bare er CPU-tung, den er hukommelsestung<\/strong>: for at beregne \u00e9n hash skal algoritmen allokere en stor m\u00e6ngde RAM og tilg\u00e5 den i et pseudo-tilf\u00e6ldigt m\u00f8nster, der er sv\u00e6rt at parallelisere p\u00e5 GPU’er og specialiserede ASIC-chips.<\/p>\n\n\n\n

Klassiske hashfunktioner som MD5 eller SHA-256 kan beregnes af tusindvis af GPU-kerner parallelt, fordi de kr\u00e6ver minimal RAM. bcrypt tilf\u00f8jede CPU-belastning via en cost-faktor, men er stadig rimeligt effektiv p\u00e5 GPU: en moderne RTX 4090 kan cracke op til 10.000 bcrypt-hashes per sekund med cost=10. Scrypt tilf\u00f8jer den tredje dimension, hukommelsesb\u00e5ndbredde: den samme GPU kan kun beregne 50-200 scrypt-hashes per sekund med N=32.768, fordi hvert hash kr\u00e6ver 32 MB RAM der skal l\u00e6ses og skrives i et ikke-paralleliserbart m\u00f8nster. Det g\u00f8r offline dictionary-angreb 50-200 gange dyrere end med bcrypt.<\/p>\n\n\n\n

OWASP anbefaler i sin Password Storage Cheat Sheet<\/a> scrypt som et legitimt alternativ til Argon2id, med minimum-parametrene N=32.768, r=8, p=1. Argon2id er foretrukket, n\u00e5r platformen underst\u00f8tter det, men scrypt er det rigtige valg, n\u00e5r du arbejder direkte med Node.js’ built-in kryptografi uden tredjeparts afh\u00e6ngigheder. Det er s\u00e6rlig relevant i 2026, hvor containere og serverless-funktioner s\u00e6tter strenge begr\u00e6nsninger p\u00e5 native native C++-kompilering.<\/p>\n\n\n\n

Scrypt bruger tre internt sammenkoblede faser: en PBKDF2-SHA256-fase der afkomprimerer passwordet til en blok, en ROMix-fase der udfylder RAM med pseudo-tilf\u00e6ldige data og derefter l\u00e6ser dem i afh\u00e6ngig r\u00e6kkef\u00f8lge, og endelig en ny PBKDF2-SHA256-fase der komprimerer resultatet til outputn\u00f8glen. ROMix-fasen er kernen i den hukommelseshardhed: dens RAM-adgangsm\u00f8nster er designet til at maksimere cache-fejlhit, s\u00e5 en angriber ikke kan reducere RAM-behovet uden dramatisk at \u00f8ge beregningsomkostningen. Det er i mods\u00e6tning til bcrypt, der kun kr\u00e6ver 4 KB arbejdshukommelse og er effektiv p\u00e5 GPU’er med mange sm\u00e5 kerner.<\/p>\n\n\n\n

Foruds\u00e6tninger og systemkrav<\/h2>\n\n\n\n

Scrypt er tilg\u00e6ngeligt i Node.js’ standard node:crypto<\/code>-modul uden nogen npm-installation. Du beh\u00f8ver ingen ekstra pakker til basis-implementationen. De eneste afh\u00e6ngigheder i dette projekt er Express (webserver) og express-rate-limit (sikkerhed). Tjek f\u00f8lgende tabel, inden du begynder:<\/p>\n\n\n\n

Komponent<\/th>Minimumversion<\/th>Anbefalet version<\/th>Bem\u00e6rkning<\/th><\/tr><\/thead>
Node.js<\/td>10.5.0<\/td>22.x LTS<\/td>crypto.scrypt()<\/code> og crypto.scryptSync()<\/code> tilg\u00e6ngeligt<\/td><\/tr>
npm<\/td>6.x<\/td>10.x<\/td>Kun til Express-eksemplet<\/td><\/tr>
RAM p\u00e5 server<\/td>256 MB<\/td>2 GB+<\/td>N=32.768 kr\u00e6ver ~32 MB per hash; 10 samtidige login = 320 MB<\/td><\/tr>
CPU-kerner<\/td>1<\/td>4+<\/td>Scrypt er enkelt-tr\u00e5det; Worker Threads anbefales til h\u00f8j trafik<\/td><\/tr>
Operativsystem<\/td>Linux\/macOS\/Windows<\/td>Ubuntu 22.04+<\/td>Alle platforme underst\u00f8ttet via OpenSSL<\/td><\/tr>
JavaScript-kendskab<\/td>ES2017 (async\/await)<\/td>ES2022+<\/td>Scrypt-API’et er callback-baseret men wrappes nemt<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Verifik\u00e9r din Node.js-version og at scrypt er tilg\u00e6ngeligt:<\/p>\n\n\n\n

node --version\n# Forventet: v22.x.x eller nyere\n\nnode -e \"const { scrypt, scryptSync } = require('node:crypto'); console.log('scrypt:', typeof scrypt, '| scryptSync:', typeof scryptSync);\"\n# Forventet: scrypt: function | scryptSync: function<\/code><\/pre>\n\n\n\n
Hvis du k\u00f8rer Node.js 10.5.0-11.x, er scrypt tilg\u00e6ngeligt men crypto.scryptSync()<\/code> var ikke stabil f\u00f8r Node.js 12.0.0. Til alle produktionssystemer anbefales Node.js 20 LTS eller 22 LTS.<\/p>\n\n\n\n
Trin 1: Projektops\u00e6tning og mappestruktur<\/h2>\n\n\n\n
Opret projektmappen og initialiser npm. Strukturen er enkel: \u00e9n fil til hashing-logikken, \u00e9n til brugerdatabasen og \u00e9n til Express-serveren. Det g\u00f8r koden let at teste isoleret.<\/p>\n\n\n\n
mkdir scrypt-demo && cd scrypt-demo\nnpm init -y\nnpm install express express-rate-limit dotenv\nmkdir -p src<\/code><\/pre>\n\n\n\n
Mappestrukturen:<\/p>\n\n\n\n
scrypt-demo\/\n\u251c\u2500\u2500 src\/\n\u2502   \u251c\u2500\u2500 hash.js          # Scrypt-hj\u00e6lpefunktioner\n\u2502   \u251c\u2500\u2500 server.js        # Express API-server\n\u2502   \u251c\u2500\u2500 users.js         # In-memory brugerstore (erstat med DB)\n\u2502   \u2514\u2500\u2500 benchmark.js     # Benchmarking-script til parametervalg\n\u251c\u2500\u2500 package.json\n\u2514\u2500\u2500 .env<\/code><\/pre>\n\n\n\n
Opret .env<\/code>-filen. Disse parametre er centerale for sikkerheden og b\u00f8r aldrig hardcodes direkte i koden:<\/p>\n\n\n\n
# .env\nPORT=3000\n\n# Scrypt-parametre - tilpas N til din servers RAM og CPU\n# N=32768: ~32 MB RAM, ~200-300 ms per hash (OWASP-minimum)\n# N=65536: ~64 MB RAM, ~400-600 ms per hash (anbefalet til nye systemer)\nSCRYPT_N=32768\nSCRYPT_R=8\nSCRYPT_P=1\nSCRYPT_KEYLEN=64\nSCRYPT_SALT_BYTES=32<\/code><\/pre>\n\n\n\n
Tilf\u00f8j en startscript-sektion til package.json<\/code>:<\/p>\n\n\n\n
{\n  \"name\": \"scrypt-demo\",\n  \"version\": \"1.0.0\",\n  \"scripts\": {\n    \"start\": \"node -r dotenv\/config src\/server.js\",\n    \"dev\": \"node --watch -r dotenv\/config src\/server.js\",\n    \"benchmark\": \"node -r dotenv\/config src\/benchmark.js\",\n    \"test\": \"node --test src\/hash.test.js\"\n  },\n  \"dependencies\": {\n    \"dotenv\": \"^16.4.0\",\n    \"express\": \"^4.21.0\",\n    \"express-rate-limit\": \"^7.4.0\"\n  },\n  \"engines\": {\n    \"node\": \">=20.0.0\"\n  }\n}<\/code><\/pre>\n\n\n\n
Trin 2: Forst\u00e5 N, r og p-parametrene<\/h2>\n\n\n\n
Scrypt har tre arbejdsfaktorer, og det er kritisk at forst\u00e5 dem, inden du v\u00e6lger v\u00e6rdier til produktion. En forkert konfiguration kan enten efterlade systemet s\u00e5rbart over for angreb eller crashe serveren med out-of-memory-fejl.<\/p>\n\n\n\n
Parameter<\/th>Navn<\/th>Effekt<\/th>OWASP minimum 2025<\/th>Anbefalet 2026<\/th><\/tr><\/thead>
N<\/strong><\/td>CPU\/hukommelsesomkostning<\/td>Potens af 2. Fordobling af N fordobler CPU-tid og RAM-forbrug line\u00e6rt<\/td>32.768 (215<\/sup>)<\/td>65.536 (216<\/sup>) for nye systemer<\/td><\/tr>
r<\/strong><\/td>Blokst\u00f8rrelse<\/td>Blokmixer-st\u00f8rrelse. RAM = 128 \u00d7 N \u00d7 r bytes. \u00d8gning \u00f8ger RAM proportionalt<\/td>8<\/td>8 (\u00e6ndres sj\u00e6ldent)<\/td><\/tr>
p<\/strong><\/td>Paralleliseringsfaktor<\/td>Multiplicerer CPU-belastningen sekventielt. \u00d8ger ikke hukommelse<\/td>1<\/td>1<\/td><\/tr>
keylen<\/strong><\/td>Outputl\u00e6ngde<\/td>L\u00e6ngden p\u00e5 den afledte n\u00f8gle i bytes. Gemmes som hex<\/td>32 bytes (256 bit)<\/td>64 bytes (512 bit)<\/td><\/tr>
salt<\/strong><\/td>Tilf\u00e6ldig salt<\/td>Unik per hash, forhindrer rainbow-table-angreb og ligner hashes<\/td>16 bytes tilf\u00e6ldig<\/td>32 bytes tilf\u00e6ldig<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
RAM-formlen er afg\u00f8rende for dimensionering:<\/strong> RAM-forbrug = 128 \u00d7 N \u00d7 r bytes. Med N=32.768 og r=8 bruger \u00e9n scrypt-operation 128 \u00d7 32.768 \u00d7 8 = 33.554.432 bytes = 32 MB RAM<\/strong>. Med N=65.536 bruger den 64 MB. Med N=131.072 (2^17) bruger den 128 MB. Plan\u00e9r for antallet af samtidige login-fors\u00f8g din server skal h\u00e5ndtere: 20 samtidige logins med N=32.768 kr\u00e6ver 640 MB RAM kun til hashing, og det er eksklusiv \u00f8vrig serverhukommelse.<\/p>\n\n\n\n
Parameteren N skal altid v\u00e6re en potens af 2<\/strong>. V\u00e6rdier som N=30.000 eller N=50.000 er ugyldige og udl\u00f8ser en RangeError<\/code>. Node.js validerer ikke altid dette ved opstart, men fejlen viser sig ved den f\u00f8rste hash-operation. Valider N-v\u00e6rdien programmatisk ved serveropstart med bitvis AND-tjek: (N & (N - 1)) === 0<\/code>.<\/p>\n\n\n\n
Parameteren maxmem<\/strong> er Node.js-specifik og s\u00e6tter et loft for, hvor meget RAM scrypt-operationen m\u00e5 bruge. Standard er 32 MB. Det er for lavt til N=65.536 og derover, og du skal s\u00e6tte den eksplicit. Beregn den som 128 * N * r * 2<\/code> for et sikkert buffer.<\/p>\n\n\n\n
Trin 3: Hash.js med asynkron scrypt<\/h2>\n\n\n\n
Node.js’ crypto.scrypt()<\/code> bruger callback-modellen fra \u00e6ldre Node.js-API’er. Til moderne async\/await-kode wrapper du den med promisify<\/code> fra node:util<\/code>. Det er den anbefalede metode frem for at skrive en manuel Promise-wrapper, fordi promisify<\/code> korrekt h\u00e5ndterer fejltilf\u00e6lde og bevarer den originale kontekst.<\/p>\n\n\n\n
'use strict';\n\nconst { scrypt, randomBytes, timingSafeEqual } = require('node:crypto');\nconst { promisify } = require('node:util');\n\nconst scryptAsync = promisify(scrypt);\n\n\/\/ Hent parametre fra milj\u00f8variabler - valider dem ved opstart\nconst N = parseInt(process.env.SCRYPT_N || '32768', 10);\nconst r = parseInt(process.env.SCRYPT_R || '8', 10);\nconst p = parseInt(process.env.SCRYPT_P || '1', 10);\nconst KEYLEN = parseInt(process.env.SCRYPT_KEYLEN || '64', 10);\nconst SALT_BYTES = parseInt(process.env.SCRYPT_SALT_BYTES || '32', 10);\n\n\/\/ Valider N ved opstart\nif (!Number.isInteger(N) || N < 16384 || (N & (N - 1)) !== 0) {\n  throw new Error(`Ugyldig SCRYPT_N=${N}. Kr\u00e6ver potens af 2 og min. 16384.`);\n}\n\nconst SCRYPT_PARAMS = {\n  N,\n  r,\n  p,\n  \/\/ maxmem skal s\u00e6ttes eksplicit ved h\u00f8je N-v\u00e6rdier\n  maxmem: 128 * N * r * 2,\n};\n\n\/**\n * Hash et password med scrypt.\n * Returnerer en streng i formatet: salt_hex:hash_hex\n *\/\nasync function hashPassword(password) {\n  if (typeof password !== 'string' || password.length === 0) {\n    throw new TypeError('Password skal v\u00e6re en ikke-tom streng');\n  }\n\n  const salt = randomBytes(SALT_BYTES);\n  const derivedKey = await scryptAsync(password, salt, KEYLEN, SCRYPT_PARAMS);\n\n  return `${salt.toString('hex')}:${derivedKey.toString('hex')}`;\n}\n\n\/**\n * Verificer et password mod et gemt hash.\n * Bruger timingSafeEqual til at undg\u00e5 timing-angreb.\n *\/\nasync function verifyPassword(password, storedHash) {\n  if (typeof password !== 'string' || typeof storedHash !== 'string') {\n    throw new TypeError('Ugyldige argumenttyper til verifikation');\n  }\n\n  const colonIndex = storedHash.indexOf(':');\n  if (colonIndex === -1) {\n    throw new Error('Ugyldig hash-format: mangler kolon-separator');\n  }\n\n  const saltHex = storedHash.slice(0, colonIndex);\n  const hashHex = storedHash.slice(colonIndex + 1);\n  const salt = Buffer.from(saltHex, 'hex');\n  const storedKeyBuffer = Buffer.from(hashHex, 'hex');\n\n  const derivedKey = await scryptAsync(password, salt, KEYLEN, SCRYPT_PARAMS);\n\n  \/\/ timingSafeEqual er obligatorisk - aldrig === eller Buffer.equals()\n  if (derivedKey.length !== storedKeyBuffer.length) return false;\n  return timingSafeEqual(derivedKey, storedKeyBuffer);\n}\n\nmodule.exports = { hashPassword, verifyPassword, SCRYPT_PARAMS };<\/code><\/pre>\n\n\n\n
Tre sikkerhedsbeslutninger i koden fortjener forklaring. For det f\u00f8rste bruger vi randomBytes(SALT_BYTES)<\/code> og ikke Math.random()<\/code> eller UUID: Math.random()<\/code> er ikke kryptografisk sikker og kan forudsiges. For det andet bruger vi colonIndex = storedHash.indexOf(':')<\/code> og ikke storedHash.split(':')<\/code>: hvis hashen indeholder et kolon i hex-kodningen (usandsynligt men muligt i fremtidige formater), splitter .split(':')<\/code> forkert. For det tredje kontrollerer vi derivedKey.length !== storedKeyBuffer.length<\/code> inden timingSafeEqual<\/code>, fordi timingSafeEqual<\/code> kaster en fejl hvis bufferne har forskellig st\u00f8rrelse.<\/p>\n\n\n\n
Trin 4: Synkron scrypt og hvorn\u00e5r du bruger den<\/h2>\n\n\n\n
Node.js tilbyder crypto.scryptSync()<\/code>, men den blokerer event loop under beregningen. Med N=32.768 varer det 200-400 ms, i hvilken tid Node.js ikke kan betjene nogen andre requests, timers eller I\/O-operationer. Det g\u00e6lder hele processen, ikke kun den aktuelle request.<\/p>\n\n\n\n
Acceptabel brug af scryptSync()<\/code> er begr\u00e6nset til: CLI-scripts der k\u00f8rer \u00e9n hash ad gangen, database-migreringsscripts der k\u00f8rer udenfor \u00e5bningstid, og test-setup der skaber brugerkonti inden testene k\u00f8rer. Brug aldrig scryptSync()<\/code> i request-handlers, middleware, eller nogen kode der k\u00f8rer i en server med samtidige brugere.<\/p>\n\n\n\n
'use strict';\n\n\/\/ Kun til CLI-scripts - ALDRIG i produktions-request-handlers\nconst { scryptSync, randomBytes, timingSafeEqual } = require('node:crypto');\n\nfunction hashPasswordSync(password) {\n  const salt = randomBytes(32);\n  const key = scryptSync(password, salt, 64, {\n    N: 32768,\n    r: 8,\n    p: 1,\n    maxmem: 128 * 1024 * 1024, \/\/ 128 MB buffer\n  });\n  return `${salt.toString('hex')}:${key.toString('hex')}`;\n}\n\nfunction verifyPasswordSync(password, storedHash) {\n  const colonIndex = storedHash.indexOf(':');\n  const salt = Buffer.from(storedHash.slice(0, colonIndex), 'hex');\n  const stored = Buffer.from(storedHash.slice(colonIndex + 1), 'hex');\n  const derived = scryptSync(password, salt, 64, {\n    N: 32768, r: 8, p: 1, maxmem: 128 * 1024 * 1024,\n  });\n  return timingSafeEqual(derived, stored);\n}\n\n\/\/ Eksempel: admin-CLI der opretter en initialkonto\nconst adminPassword = process.argv[2];\nif (!adminPassword) {\n  console.error('Brug: node create-admin.js ');\n  process.exit(1);\n}\nconst hash = hashPasswordSync(adminPassword);\nconsole.log('Admin password hash (gem i .env eller database):');\nconsole.log(hash);\n\/\/ Output (k\u00f8rer i ~200 ms):\n\/\/ Admin password hash:\n\/\/ a3f8b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1:\n\/\/ b2c3d4e5f6a7b8c9d0e1f2a3b4c5...d8e9f0a1<\/code><\/pre>\n\n\n\n
Trin 5: In-memory brugerstore<\/h2>\n\n\n\n
I et produkt vil du bruge PostgreSQL, MySQL eller MongoDB, men til demonstration opretter vi en simpel in-memory Map. Strukturen inkluderer login-t\u00e6ller og lockout-tidsstempel til brute-force-beskyttelse. Erstat dette med en rigtig databaseklasse i trin 10.<\/p>\n\n\n\n
'use strict';\n\n\/\/ In-memory brugerstore - erstat med rigtig database i produktion\nconst users = new Map();\n\nfunction createUser(username, hashedPassword) {\n  if (users.has(username)) {\n    throw new Error('Bruger eksisterer allerede');\n  }\n  users.set(username, {\n    username,\n    password: hashedPassword,\n    createdAt: new Date().toISOString(),\n    loginAttempts: 0,\n    lockedUntil: null,\n    lastLogin: null,\n  });\n  return { username };\n}\n\nfunction getUser(username) {\n  return users.get(username) || null;\n}\n\nfunction incrementLoginAttempts(username) {\n  const user = users.get(username);\n  if (!user) return;\n  user.loginAttempts += 1;\n  \/\/ L\u00e5s kontoen i 15 minutter efter 5 fejlede fors\u00f8g\n  if (user.loginAttempts >= 5) {\n    user.lockedUntil = new Date(Date.now() + 15 * 60 * 1000).toISOString();\n    console.warn(`Konto l\u00e5st: ${username} (${user.loginAttempts} fejlede fors\u00f8g)`);\n  }\n  users.set(username, user);\n}\n\nfunction resetLoginAttempts(username) {\n  const user = users.get(username);\n  if (!user) return;\n  user.loginAttempts = 0;\n  user.lockedUntil = null;\n  user.lastLogin = new Date().toISOString();\n  users.set(username, user);\n}\n\nmodule.exports = { createUser, getUser, incrementLoginAttempts, resetLoginAttempts };<\/code><\/pre>\n\n\n\n
Trin 6: Express API-server med sikkerhedslag<\/h2>\n\n\n\n
Serveren implementerer tre sikkerhedslag: IP-baseret rate limiting via express-rate-limit<\/code>, kontobaseret lockout i brugerstoren og konstante fejlbeskeder der ikke afsl\u00f8rer om en bruger eksisterer. Det er n\u00f8glen til at forhindre to typer angreb: brute force og bruger-enumeration.<\/p>\n\n\n\n
'use strict';\n\nrequire('dotenv').config();\nconst express = require('express');\nconst { rateLimit } = require('express-rate-limit');\nconst { hashPassword, verifyPassword } = require('.\/hash');\nconst { createUser, getUser, incrementLoginAttempts, resetLoginAttempts } = require('.\/users');\n\nconst app = express();\napp.use(express.json({ limit: '10kb' })); \/\/ Begr\u00e6ns request-st\u00f8rrelse\n\n\/\/ Striks rate limiting for login-endpoint\nconst loginLimiter = rateLimit({\n  windowMs: 15 * 60 * 1000, \/\/ 15 minutter\n  limit: 10,\n  standardHeaders: 'draft-7',\n  legacyHeaders: false,\n  handler: (req, res) => {\n    res.status(429).json({\n      error: 'For mange login-fors\u00f8g. Pr\u00f8v igen om 15 minutter.',\n    });\n  },\n});\n\n\/\/ POST \/register - Opret ny bruger\napp.post('\/register', async (req, res) => {\n  const { username, password } = req.body || {};\n\n  if (!username || typeof username !== 'string' || username.length < 3) {\n    return res.status(400).json({ error: 'Brugernavn skal v\u00e6re mindst 3 tegn' });\n  }\n\n  if (!password || typeof password !== 'string' || password.length < 12) {\n    return res.status(400).json({ error: 'Password skal v\u00e6re mindst 12 tegn' });\n  }\n\n  \/\/ Saniter brugernavn - kun alfanumeriske tegn og understregning\n  if (!\/^[a-zA-Z0-9_\u00e6\u00f8\u00e5\u00c6\u00d8\u00c5]{3,50}$\/.test(username)) {\n    return res.status(400).json({ error: 'Brugernavn indeholder ugyldige tegn' });\n  }\n\n  if (getUser(username)) {\n    return res.status(409).json({ error: 'Bruger eksisterer allerede' });\n  }\n\n  try {\n    const hashedPassword = await hashPassword(password);\n    createUser(username, hashedPassword);\n    return res.status(201).json({ message: 'Bruger oprettet', username });\n  } catch (err) {\n    console.error('Registreringsfejl:', err.message);\n    return res.status(500).json({ error: 'Intern serverfejl' });\n  }\n});\n\n\/\/ POST \/login - Valider brugerlogin\napp.post('\/login', loginLimiter, async (req, res) => {\n  const { username, password } = req.body || {};\n\n  if (!username || !password) {\n    return res.status(400).json({ error: 'Brugernavn og password er p\u00e5kr\u00e6vet' });\n  }\n\n  const user = getUser(username);\n\n  if (!user) {\n    \/\/ K\u00f8r dummy-hashing for at undg\u00e5 timing-baseret bruger-enumeration\n    await hashPassword('dummy-for-constant-time-' + username);\n    return res.status(401).json({ error: 'Ugyldige legitimationsoplysninger' });\n  }\n\n  \/\/ Tjek om kontoen er l\u00e5st\n  if (user.lockedUntil && new Date(user.lockedUntil) > new Date()) {\n    const unlockTime = new Date(user.lockedUntil).toLocaleTimeString('da-DK');\n    return res.status(429).json({\n      error: `Kontoen er l\u00e5st til ${unlockTime}. Brug \"Glemt password\" for at nulstille.`,\n    });\n  }\n\n  try {\n    const isValid = await verifyPassword(password, user.password);\n\n    if (!isValid) {\n      incrementLoginAttempts(username);\n      return res.status(401).json({ error: 'Ugyldige legitimationsoplysninger' });\n    }\n\n    resetLoginAttempts(username);\n    return res.status(200).json({ message: 'Login lykkedes', username });\n  } catch (err) {\n    console.error('Login-fejl:', err.message);\n    return res.status(500).json({ error: 'Intern serverfejl' });\n  }\n});\n\n\/\/ Health-check endpoint\napp.get('\/health', (req, res) => {\n  const memUsage = process.memoryUsage();\n  res.json({\n    status: 'ok',\n    scrypt: { N: parseInt(process.env.SCRYPT_N), r: parseInt(process.env.SCRYPT_R) },\n    memory: { heapUsedMB: Math.round(memUsage.heapUsed \/ 1024 \/ 1024) },\n  });\n});\n\nconst PORT = process.env.PORT || 3000;\napp.listen(PORT, () => {\n  console.log(`Server k\u00f8rer p\u00e5 port ${PORT}`);\n  console.log(`Scrypt: N=${process.env.SCRYPT_N || 32768}, r=${process.env.SCRYPT_R || 8}, p=${process.env.SCRYPT_P || 1}`);\n  console.log(`RAM per hash: ${Math.round(128 * parseInt(process.env.SCRYPT_N || 32768) * 8 \/ 1024 \/ 1024)} MB`);\n});\n\nmodule.exports = app;<\/code><\/pre>\n\n\n\n
Det vigtigste sikkerhedsm\u00f8nster i login-endpoint er dummy-hashing ved ukendt bruger. Uden det vil en angriber se, at serveren svarer hurtigere for ukendte brugere (0 ms for bruger-opslag + ingen hashing) end for kendte brugere (200-400 ms for scrypt-verifikation). Den tidsforskel kan bruges til at enumerere alle gyldige brugernavne. Med dummy-hashing er responstiden ens uanset om brugeren eksisterer.<\/p>\n\n\n\n
Trin 7: Start og test serveren<\/h2>\n\n\n\n
Start serveren og test alle endpoints med curl:<\/p>\n\n\n\n
npm start\n# Output:\n# Server k\u00f8rer p\u00e5 port 3000\n# Scrypt: N=32768, r=8, p=1\n# RAM per hash: 32 MB\n\n# Registrer ny bruger (tag tid - det tager ~300 ms)\ntime curl -X POST http:\/\/localhost:3000\/register \\\n  -H \"Content-Type: application\/json\" \\\n  -d '{\"username\":\"alice\",\"password\":\"SuperHemmeligtKodeord2026!\"}'\n# Output: {\"message\":\"Bruger oprettet\",\"username\":\"alice\"}\n# Tid: real 0m0.312s\n\n# Log ind med korrekt password\ncurl -X POST http:\/\/localhost:3000\/login \\\n  -H \"Content-Type: application\/json\" \\\n  -d '{\"username\":\"alice\",\"password\":\"SuperHemmeligtKodeord2026!\"}'\n# Output: {\"message\":\"Login lykkedes\",\"username\":\"alice\"}\n\n# Forkert password\ncurl -X POST http:\/\/localhost:3000\/login \\\n  -H \"Content-Type: application\/json\" \\\n  -d '{\"username\":\"alice\",\"password\":\"ForkertKodeord\"}'\n# Output: {\"error\":\"Ugyldige legitimationsoplysninger\"}\n\n# Ikke-eksisterende bruger (samme svartid som forkert password)\ncurl -X POST http:\/\/localhost:3000\/login \\\n  -H \"Content-Type: application\/json\" \\\n  -d '{\"username\":\"findesikke\",\"password\":\"test\"}'\n# Output: {\"error\":\"Ugyldige legitimationsoplysninger\"}\n\n# Health-check\ncurl http:\/\/localhost:3000\/health\n# Output: {\"status\":\"ok\",\"scrypt\":{\"N\":32768,\"r\":8},\"memory\":{\"heapUsedMB\":42}}<\/code><\/pre>\n\n\n\n
Svartiden p\u00e5 200-400 ms er normal og tilsigtet. Det er scrypt der arbejder. Fors\u00f8g aldrig at reducere svartiden ved at s\u00e6nke N, det sv\u00e6kker sikkerheden. Design i stedet frontend til at vise en loading-indikator og undg\u00e5 HTTP-timeouts under 5 sekunder for auth-endpoints.<\/p>\n\n\n\n
Trin 8: Benchmarking til parametervalg<\/h2>\n\n\n\n
K\u00f8r dette benchmark-script direkte p\u00e5 din produktionsserver for at finde den rigtige N-v\u00e6rdi. K\u00f8r det under repr\u00e6sentativ serverbelastning for at simulere det reelle milj\u00f8. Resultater varierer meget mellem en cloud-VM, en dedikeret server og serverless:<\/p>\n\n\n\n
'use strict';\n\nconst { scrypt, randomBytes } = require('node:crypto');\nconst { promisify } = require('node:util');\nconst scryptAsync = promisify(scrypt);\n\nasync function benchmark(N, iterations = 5) {\n  const password = 'BenchmarkPassword123!Sikker';\n  const salt = randomBytes(32);\n  const maxmem = 128 * N * 8 * 2;\n\n  const times = [];\n  for (let i = 0; i < iterations; i++) {\n    const start = process.hrtime.bigint();\n    await scryptAsync(password, salt, 64, { N, r: 8, p: 1, maxmem });\n    const end = process.hrtime.bigint();\n    times.push(Number(end - start) \/ 1_000_000);\n  }\n\n  const avg = times.reduce((a, b) => a + b, 0) \/ times.length;\n  const min = Math.min(...times);\n  const max = Math.max(...times);\n  const memMB = (128 * N * 8) \/ (1024 * 1024);\n  console.log(\n    `N=${String(N).padStart(7)} | RAM: ${String(memMB).padStart(4)} MB | ` +\n    `Gns: ${avg.toFixed(0).padStart(4)} ms | Min: ${min.toFixed(0).padStart(4)} ms | Max: ${max.toFixed(0).padStart(4)} ms`\n  );\n  return avg;\n}\n\n(async () => {\n  const os = require('node:os');\n  console.log(`Platform: ${os.type()} ${os.arch()} | Kerner: ${os.cpus().length} | RAM: ${Math.round(os.totalmem()\/1024\/1024)} MB`);\n  console.log(`Node.js: ${process.version} | Benchmark-parametre: r=8, p=1, keylen=64, 5 iterationer\\n`);\n  console.log('N         | RAM     | Gns. tid | Min. tid | Maks. tid');\n  console.log('----------|---------|----------|----------|----------');\n\n  for (const N of [8192, 16384, 32768, 65536, 131072]) {\n    await benchmark(N);\n  }\n\n  console.log('\\nAnbefalede valg:');\n  console.log('  Serverless \/ lav RAM (<512 MB): N=16384');\n  console.log('  Standardserver (1-4 GB RAM):    N=32768 (OWASP-minimum)');\n  console.log('  Sikker server (8+ GB RAM):       N=65536 (anbefalet 2026)');\n  console.log('  H\u00f8j sikkerhed \/ lav trafik:     N=131072');\n})();\n\n\/\/ Typisk output p\u00e5 en moderne server:\n\/\/ N=   8,192 | RAM:    8 MB | Gns:   51 ms | Min:   49 ms | Maks:   54 ms\n\/\/ N=  16,384 | RAM:   16 MB | Gns:  102 ms | Min:   99 ms | Maks:  107 ms\n\/\/ N=  32,768 | RAM:   32 MB | Gns:  205 ms | Min:  201 ms | Maks:  211 ms\n\/\/ N=  65,536 | RAM:   64 MB | Gns:  413 ms | Min:  409 ms | Maks:  419 ms\n\/\/ N= 131,072 | RAM:  128 MB | Gns:  847 ms | Min:  841 ms | Maks:  858 ms<\/code><\/pre>\n\n\n\n
Scrypt vs bcrypt vs Argon2: direkte sammenligning<\/h2>\n\n\n\n
Valget af password-hashing-algoritme er \u00e9n af de vigtigste sikkerhedsbeslutninger i en applikation. Her er en objektiv sammenligning af de tre OWASP-anbefalede algoritmer:<\/p>\n\n\n\n
Egenskab<\/th>scrypt (N=32768)<\/th>bcrypt (cost=12)<\/th>Argon2id (t=2, m=65536)<\/th><\/tr><\/thead>
RAM-forbrug<\/strong><\/td>~32 MB<\/td><1 MB<\/td>~64 MB<\/td><\/tr>
CPU-tid (moderne server)<\/strong><\/td>200-400 ms<\/td>250-350 ms<\/td>200-500 ms<\/td><\/tr>
GPU-modstand (RTX 4090)<\/strong><\/td>~100-200 hash\/sek<\/td>~10.000 hash\/sek<\/td>~50-100 hash\/sek<\/td><\/tr>
ASIC-modstand<\/strong><\/td>H\u00f8j<\/td>Lav (ASIC-chips eksisterer)<\/td>Meget h\u00f8j<\/td><\/tr>
Node.js built-in<\/strong><\/td>Ja (node:crypto)<\/td>Nej (npm: bcrypt)<\/td>Nej (npm: argon2, native C++)<\/td><\/tr>
OWASP-prioritet 2025<\/strong><\/td>2. prioritet<\/td>3. prioritet<\/td>1. prioritet (foretrukket)<\/td><\/tr>
Password-maksimall\u00e6ngde<\/strong><\/td>Ingen gr\u00e6nse<\/td>72 bytes (kritisk fejl!)<\/td>Ingen gr\u00e6nse<\/td><\/tr>
RFC-standard<\/strong><\/td>RFC 7914 (2016)<\/td>Ingen RFC<\/td>RFC 9106 (2021)<\/td><\/tr>
Alpine Linux Docker<\/strong><\/td>Virker (built-in)<\/td>Kr\u00e6ver build-essential<\/td>Kr\u00e6ver build-essential + Python<\/td><\/tr>
Password Hashing Competition<\/strong><\/td>Finalist<\/td>Ikke deltaget<\/td>Vinder (2015)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
bcrypts 72-byte-gr\u00e6nse er et alvorligt og underkendt problem. Passwords over 72 bytes trunkeres stille uden fejlbesked, hvilket betyder at to passwords der kun adskiller sig efter det 72. tegn producerer identiske hashes. En bruger der har et langt og \"sikkert\" password p\u00e5 100 tegn tror de er beskyttede, men en angriber der ved om denne gr\u00e6nse kan reducere angrebet markant. Scrypt og Argon2 har ingen s\u00e5dan begr\u00e6nsning.<\/p>\n\n\n\n
Argon2id vinder den tekniske sammenligning som vinder af Password Hashing Competition 2015. Men i praksis giver native C++-kompilering problemer i Alpine Linux Docker-containere (standardbase for mange produktionssystemer), ARM64-baserede servere og AWS Lambda. En byggeproces der virker lokalt fejler i CI\/CD. Scrypt kr\u00e6ver ingen native kompilering og er det bedste valg for teams der prioriterer zero-dependency og reproducerbare builds. Se Ed25519 i Node.js<\/a> for et lignende eksempel p\u00e5 effektiv built-in kryptografi.<\/p>\n\n\n\n
Trin 9: Lazy migration fra bcrypt til scrypt<\/h2>\n\n\n\n
N\u00e5r du migrerer fra bcrypt til scrypt, skal du aldrig pr\u00f8ve at konvertere eksisterende bcrypt-hashes direkte. Du har ikke adgang til de originale passwords, og du b\u00f8r heller ikke have det. Den korrekte strategi er lazy migration: opdater hashen ved n\u00e6ste succesfulde login, og gem et versionspr\u00e6fiks i hash-feltet s\u00e5 du kan h\u00e5ndtere begge formater parallelt.<\/p>\n\n\n\n
'use strict';\n\nconst { scrypt, randomBytes, timingSafeEqual } = require('node:crypto');\nconst { promisify } = require('node:util');\nconst scryptAsync = promisify(scrypt);\n\n\/\/ Hash-versioner og deres parametre\nconst VERSIONS = {\n  'scrypt-v1': { N: 16384, r: 8, p: 1, keylen: 64, maxmem: 33554432 },\n  'scrypt-v2': { N: 32768, r: 8, p: 1, keylen: 64, maxmem: 67108864 },\n};\nconst CURRENT_VERSION = 'scrypt-v2';\n\nfunction detectVersion(storedHash) {\n  for (const version of Object.keys(VERSIONS)) {\n    if (storedHash.startsWith(version + ':')) return version;\n  }\n  return null; \/\/ Ukendt format (f.eks. bcrypt med $2b$)\n}\n\nasync function verifyScryptHash(password, storedHash) {\n  const version = detectVersion(storedHash);\n  if (!version) return { valid: false, needsMigration: false, error: 'Ukendt hash-format' };\n\n  const params = VERSIONS[version];\n  const hashBody = storedHash.slice(version.length + 1); \/\/ Fjern \"scrypt-vX:\"\n  const colonIdx = hashBody.indexOf(':');\n  const salt = Buffer.from(hashBody.slice(0, colonIdx), 'hex');\n  const stored = Buffer.from(hashBody.slice(colonIdx + 1), 'hex');\n\n  const derived = await scryptAsync(password, salt, params.keylen, params);\n  if (derived.length !== stored.length) return { valid: false, needsMigration: false };\n  const isValid = timingSafeEqual(derived, stored);\n\n  if (!isValid) return { valid: false, needsMigration: false, newHash: null };\n\n  const needsMigration = version !== CURRENT_VERSION;\n  let newHash = null;\n  if (needsMigration) {\n    const np = VERSIONS[CURRENT_VERSION];\n    const newSalt = randomBytes(32);\n    const newKey = await scryptAsync(password, newSalt, np.keylen, np);\n    newHash = `${CURRENT_VERSION}:${newSalt.toString('hex')}:${newKey.toString('hex')}`;\n  }\n\n  return { valid: true, needsMigration, newHash };\n}\n\nasync function createScryptHash(password) {\n  const np = VERSIONS[CURRENT_VERSION];\n  const salt = randomBytes(32);\n  const key = await scryptAsync(password, salt, np.keylen, np);\n  return `${CURRENT_VERSION}:${salt.toString('hex')}:${key.toString('hex')}`;\n}\n\nmodule.exports = { verifyScryptHash, createScryptHash };\n\n\/\/ Brug i login-flowet:\n\/\/ const { valid, needsMigration, newHash } = await verifyScryptHash(password, user.password_hash);\n\/\/ if (valid && needsMigration && newHash) {\n\/\/   await db.query('UPDATE users SET password_hash=$1 WHERE id=$2', [newHash, user.id]);\n\/\/ }<\/code><\/pre>\n\n\n\n
Lazy migration har en vigtig egenskab: inaktive brugere migrerer aldrig automatisk. Det er acceptabelt, men du b\u00f8r s\u00e6tte en deadline (f.eks. 6 m\u00e5neder) og tvinge brugere der ikke har logget ind til at nulstille password via e-mail. Kombiner versionspr\u00e6fikset med en migreringsdato i databasen for at spore fremskridtet.<\/p>\n\n\n\n
Trin 10: PostgreSQL-integration<\/h2>\n\n\n\n
I produktionssystemer gemmer du hashes i en relationsdatabase. Her er det komplette databaselag til PostgreSQL med beskyttelse mod SQL-injection via parametriserede foresp\u00f8rgsler. Brug vores guide til SQL Injection i Node.js<\/a> for at forst\u00e5, hvorfor stringinterpolation i SQL-foresp\u00f8rgsler er farligt.<\/p>\n\n\n\n
'use strict';\n\nconst { Pool } = require('pg');\nconst { hashPassword, verifyPassword } = require('.\/hash');\n\nconst pool = new Pool({\n  connectionString: process.env.DATABASE_URL,\n  max: 10, \/\/ Maks. 10 databaseforbindelser i poolen\n  ssl: process.env.NODE_ENV === 'production' ? { rejectUnauthorized: true } : false,\n});\n\n\/\/ K\u00f8r ved serveropstart\nconst CREATE_TABLE_SQL = `\n  CREATE TABLE IF NOT EXISTS users (\n    id SERIAL PRIMARY KEY,\n    username VARCHAR(50) UNIQUE NOT NULL,\n    password_hash TEXT NOT NULL,\n    created_at TIMESTAMPTZ DEFAULT NOW(),\n    last_login TIMESTAMPTZ,\n    login_attempts SMALLINT DEFAULT 0,\n    locked_until TIMESTAMPTZ\n  );\n  CREATE INDEX IF NOT EXISTS idx_users_username ON users(username);\n`;\n\nasync function initDatabase() {\n  const client = await pool.connect();\n  try {\n    await client.query(CREATE_TABLE_SQL);\n    console.log('Databaseskema klar');\n  } finally {\n    client.release();\n  }\n}\n\nasync function registerUser(username, password) {\n  const hashedPassword = await hashPassword(password);\n  const result = await pool.query(\n    `INSERT INTO users (username, password_hash)\n     VALUES ($1, $2)\n     RETURNING id, username, created_at`,\n    [username, hashedPassword]\n  );\n  return result.rows[0];\n}\n\nasync function loginUser(username, password) {\n  const result = await pool.query(\n    `SELECT id, username, password_hash, login_attempts, locked_until\n     FROM users WHERE username = $1`,\n    [username]\n  );\n\n  if (result.rows.length === 0) {\n    \/\/ Kald scrypt alligevel for konstant svartid\n    await hashPassword('timing-protection-dummy');\n    return null;\n  }\n\n  const user = result.rows[0];\n  if (user.locked_until && new Date(user.locked_until) > new Date()) {\n    const err = new Error('Kontoen er l\u00e5st');\n    err.lockedUntil = user.locked_until;\n    throw err;\n  }\n\n  const isValid = await verifyPassword(password, user.password_hash);\n\n  if (!isValid) {\n    await pool.query(\n      `UPDATE users\n       SET login_attempts = login_attempts + 1,\n           locked_until = CASE\n             WHEN login_attempts >= 4\n             THEN NOW() + INTERVAL '15 minutes'\n             ELSE locked_until\n           END\n       WHERE username = $1`,\n      [username]\n    );\n    return null;\n  }\n\n  await pool.query(\n    `UPDATE users\n     SET login_attempts = 0, locked_until = NULL, last_login = NOW()\n     WHERE username = $1`,\n    [username]\n  );\n  return { id: user.id, username: user.username };\n}\n\nmodule.exports = { initDatabase, registerUser, loginUser };<\/code><\/pre>\n\n\n\n
Trin 11: Test med Node.js' indbyggede testmodul<\/h2>\n\n\n\n
Node.js 20+ inkluderer et built-in testmodul der eliminerer behovet for Jest eller Mocha til simple enhedstests. Brug N=1024 i test-milj\u00f8et for at holde testen under 1 sekund, og s\u00e6t N=32.768 til integrationstests der verificerer den fulde produktionskonfiguration.<\/p>\n\n\n\n
'use strict';\n\nconst { test, describe } = require('node:test');\nconst assert = require('node:assert\/strict');\n\n\/\/ Lavere N til unit-tests - undg\u00e5 timeouts i CI\/CD\nprocess.env.SCRYPT_N = '1024';\nprocess.env.SCRYPT_R = '8';\nprocess.env.SCRYPT_P = '1';\nprocess.env.SCRYPT_KEYLEN = '64';\nprocess.env.SCRYPT_SALT_BYTES = '32';\n\nconst { hashPassword, verifyPassword } = require('.\/hash');\n\ndescribe('hashPassword', () => {\n  test('returnerer salt:hash format', async () => {\n    const hash = await hashPassword('TestPassword123!');\n    assert.equal(typeof hash, 'string');\n    const colonIdx = hash.indexOf(':');\n    assert.ok(colonIdx > 0, 'Hash skal indeholde \":\"');\n    assert.equal(hash.slice(0, colonIdx).length, 64);  \/\/ 32 bytes = 64 hex\n    assert.equal(hash.slice(colonIdx + 1).length, 128); \/\/ 64 bytes = 128 hex\n  });\n\n  test('producerer forskellig hash for samme password pga. tilf\u00e6ldig salt', async () => {\n    const h1 = await hashPassword('SammePassword!');\n    const h2 = await hashPassword('SammePassword!');\n    assert.notEqual(h1, h2);\n    \/\/ Men salt-prefixet alene er ogs\u00e5 unikt:\n    assert.notEqual(h1.split(':')[0], h2.split(':')[0]);\n  });\n\n  test('kaster TypeError for tomt password', async () => {\n    await assert.rejects(() => hashPassword(''), TypeError);\n    await assert.rejects(() => hashPassword(null), TypeError);\n    await assert.rejects(() => hashPassword(12345), TypeError);\n    await assert.rejects(() => hashPassword(undefined), TypeError);\n  });\n\n  test('hashPassword h\u00e5ndterer ikke-ASCII-tegn korrekt', async () => {\n    const hash = await hashPassword('KodeordMed\u00c6\u00d8\u00c5!123');\n    assert.ok(hash.includes(':'));\n  });\n});\n\ndescribe('verifyPassword', () => {\n  test('verificerer korrekt password', async () => {\n    const pw = 'KorrektPassword2026!';\n    const hash = await hashPassword(pw);\n    assert.equal(await verifyPassword(pw, hash), true);\n  });\n\n  test('afviser forkert password', async () => {\n    const hash = await hashPassword('RigtigtPassword!');\n    assert.equal(await verifyPassword('ForkertPassword!', hash), false);\n  });\n\n  test('afviser tomt password mod gyldig hash', async () => {\n    const hash = await hashPassword('Rigtigt!');\n    assert.equal(await verifyPassword('', hash), false);\n  });\n\n  test('kaster fejl ved manglende kolon-separator', async () => {\n    await assert.rejects(() => verifyPassword('test', 'ingenkolonher'), Error);\n  });\n\n  test('kaster TypeError ved ugyldig input-type', async () => {\n    const hash = await hashPassword('test!12345678');\n    await assert.rejects(() => verifyPassword(null, hash), TypeError);\n    await assert.rejects(() => verifyPassword('test', null), TypeError);\n  });\n});\n\n\/\/ K\u00f8r med: node --test src\/hash.test.js\n\/\/ Forventet output:\n# \u25b6 hashPassword\n#   \u2714 returnerer salt:hash format (12.3ms)\n#   \u2714 producerer forskellig hash for samme password (24.8ms)\n#   \u2714 kaster TypeError for tomt password (0.2ms)\n#   \u2714 hashPassword h\u00e5ndterer ikke-ASCII-tegn korrekt (12.1ms)\n# \u25b6 verifyPassword\n#   \u2714 verificerer korrekt password (12.4ms)\n#   \u2714 afviser forkert password (12.2ms)\n#   \u2714 afviser tomt password mod gyldig hash (0.1ms)\n#   \u2714 kaster fejl ved manglende kolon-separator (0.1ms)\n#   \u2714 kaster TypeError ved ugyldig input-type (0.1ms)\n# \u2139 tests 9, pass 9<\/code><\/pre>\n\n\n\n
Trin 12: Produktionscheckliste<\/h2>\n\n\n\n
Inden deployment til produktion, gennemg\u00e5 denne checkliste punkt for punkt:<\/p>\n\n\n\n
Sikkerhedspunkt<\/th>Krav<\/th>Verifikation<\/th><\/tr><\/thead>
N-parameter<\/td>Min. 32.768 i produktion<\/td>K\u00f8r benchmark-scriptet p\u00e5 produktionsserver<\/td><\/tr>
maxmem<\/td>Min. 128 \u00d7 N \u00d7 r \u00d7 1,5 bytes<\/td>Tjek ingen maxmem exceeded<\/code>-fejl i logs<\/td><\/tr>
Salt<\/td>randomBytes(32), unik per hash<\/td>Verificer at ingen to hashes har samme salt-pr\u00e6fix<\/td><\/tr>
timingSafeEqual<\/td>Altid ved hash-verifikation<\/td>Code review: s\u00f8g efter Buffer.equals<\/code> og ===<\/code><\/td><\/tr>
Rate limiting<\/td>Max 10 login-fors\u00f8g\/IP\/15 min<\/td>Test med Apache Bench: ab -n 15 -c 1 ...<\/code><\/td><\/tr>
Kontobaseret lockout<\/td>5 fors\u00f8g, 15 min lockout<\/td>Test med 6 forkerte passwords for samme bruger<\/td><\/tr>
Dummy-hashing<\/td>Ved ukendt brugernavn<\/td>M\u00e5l svartid for eksisterende vs. ikke-eksisterende bruger<\/td><\/tr>
HTTPS<\/td>TLS 1.3 p\u00e5 alle endpoints<\/td>curl --verbose https:\/\/... (tjek TLS-version)<\/td><\/tr>
Password-minimumsl\u00e6ngde<\/td>Min. 12 tegn (NIST SP 800-63B)<\/td>Test med 11-tegns password - skal afvises<\/td><\/tr>
Ingen hash i API-response<\/td>password_hash aldrig eksponeret<\/td>Tjek alle res.json()-kald i koden<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
5 typiske fejl med scrypt i Node.js<\/h2>\n\n\n\n
Disse fejl optr\u00e6der hyppigt i kodereviews og kan nullificere scrypts sikkerhedsfordele selv med ellers korrekt implementering.<\/p>\n\n\n\n
Fejl 1: Manglende maxmem-konfiguration.<\/strong> Node.js' standard maxmem er 32 MB. Med N=65.536 og r=8 kr\u00e6ver scrypt 64 MB, og du f\u00e5r fejlen Error: Invalid scrypt params: maxmem = 33554432 exceeded<\/code>. Denne fejl opst\u00e5r typisk i produktion med f\u00f8rste deployment af nye N-parametre, fordi udviklermaskinen havde en anden Node.js-version eller en nyere standard. S\u00e6t altid maxmem eksplicit til mindst 128 * N * r * 2<\/code> for at have buffer til OS-overhead.<\/p>\n\n\n\n
Fejl 2: Statisk eller forudsigeligt salt.<\/strong> Et fast salt som 'mysalt'<\/code>, brugernavnet som salt, eller et UUID fra en ekstern kilde g\u00f8r alle hashes beregnelige p\u00e5 forh\u00e5nd via rainbow tables. Med et forudsigeligt salt kan en angriber der stj\u00e6ler databasen beregne alle hash-v\u00e6rdier for en stor ordbog af passwords \u00e9n gang og derefter sl\u00e5 dem op i realtid. Brug altid randomBytes(32)<\/code> og gem saltet i det samme felt som hashen.<\/p>\n\n\n\n
Fejl 3: Sammenligning med === eller Buffer.equals().<\/strong> Sammenligning med ===<\/code> eller Buffer.equals()<\/code> returnerer false<\/code> s\u00e5 snart det f\u00f8rste forskellige byte er fundet. En angriber kan m\u00e5le responstiden med h\u00f8j pr\u00e6cision (mikrosekunder) og gradvist g\u00e6tte den korrekte hash ved at sende mange requests og observere tidsvariationer. timingSafeEqual()<\/code> bruger altid pr\u00e6cis den samme tid uanset, hvor hashes adskiller sig.<\/p>\n\n\n\n
\/\/ FORKERT - l\u00e6kker timing-information\nif (derivedKey.toString('hex') === storedHash) { ... }\nif (derivedKey.equals(storedKeyBuffer)) { ... }\n\n\/\/ KORREKT - konstant tid\nconst { timingSafeEqual } = require('node:crypto');\nif (derivedKey.length !== storedKeyBuffer.length) return false;\nif (timingSafeEqual(derivedKey, storedKeyBuffer)) { ... }<\/code><\/pre>\n\n\n\n
Fejl 4: Test-N-v\u00e6rdier i produktion.<\/strong> Med N=1024 (som bruges i test-suite) beregner en moderne GPU op til 100.000 hashes per sekund. Med N=32.768 falder den til under 200. Producerer du N fra en milj\u00f8variabel der ikke s\u00e6ttes korrekt i produktionsmilj\u00f8et, ender du med N=1024 eller endda N=undefined, der typisk defaulter til en lav fejlsikker v\u00e6rdi. Valider altid N ved opstart med en hard-coded minimumsgr\u00e6nse.<\/p>\n\n\n\n
Fejl 5: scryptSync i Express-request-handlers.<\/strong> crypto.scryptSync()<\/code> blokerer Node.js' event loop i 200-400 ms. I den tid kan serveren ikke h\u00e5ndtere nogen andre requests, ikke engang health-checks, statiske filer eller database-keepalive-foresp\u00f8rgsler. 10 samtidige brugere der logger ind giver 2-4 sekunders total blokering per request i k\u00f8en. Brug altid scryptAsync<\/code> (promisify-wrapped version) i alle web-request-handlers.<\/p>\n\n\n\n
8 fejlfindingsscenarier<\/h2>\n\n\n\n
Her er en guide til de hyppigste fejlbeskeder og problemer ved brug af scrypt i Node.js-produktion:<\/p>\n\n\n\n
Fejlbesked eller symptom<\/th>\u00c5rsag<\/th>L\u00f8sning<\/th><\/tr><\/thead>
Error: Invalid scrypt params: maxmem exceeded<\/code><\/td>N \u00d7 r \u00d7 128 bytes overstiger maxmem-gr\u00e6nsen<\/td>S\u00e6t maxmem: 128 * N * r * 2<\/code> i SCRYPT_PARAMS<\/td><\/tr>
Error: scrypt failed<\/code> (generisk OpenSSL-fejl)<\/td>Utilstr\u00e6kkelig RAM p\u00e5 serveren, typisk ved N=131072<\/td>Reducer N eller for\u00f8g serverens RAM-allokering<\/td><\/tr>
TypeError: Invalid data, key must be a string or an instance of Buffer<\/code><\/td>Password-argumentet er null, undefined eller et tal<\/td>Valider input-typer inden scrypt-kaldet med typeof<\/code><\/td><\/tr>
Hash-verifikation returnerer altid false<\/td>Encoding-mismatch (utf8 vs. hex) eller forkert split-logik<\/td>Brug konsekvent hex-encoding; brug indexOf(':')<\/code> ikke split(':')<\/code><\/td><\/tr>
RangeError: scrypt work factors are out of range<\/code><\/td>N er ikke en potens af 2, eller er 0, negativt eller NaN<\/td>Valider: N > 0 && (N & (N-1)) === 0<\/code><\/td><\/tr>
Server svarer ikke under h\u00f8j login-trafik<\/td>Mange samtidige scrypt-operationer blokerer eller s\u00e6tter serveren under pres<\/td>Reducer N, implement\u00e9r rate limiting og Worker Thread-pool<\/td><\/tr>
Out-of-memory-crash ved spidsbelastning<\/td>N \u00d7 antal samtidige login \u00d7 128 \u00d7 r bytes overstiger serverens RAM<\/td>S\u00e6t N=16384 i serverless; brug job-queue til batching af auth<\/td><\/tr>
ERR_INVALID_ARG_TYPE: keylen must be an integer<\/code><\/td>SCRYPT_KEYLEN er en streng pga. manglende parseInt()<\/td>Brug altid parseInt(process.env.SCRYPT_KEYLEN, 10)<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Generel diagnostik: k\u00f8r Node.js med node --trace-warnings src\/server.js<\/code> for alle runtime-advarsler. M\u00e5l hukommelsesforbrug under test med Apache Bench: ab -n 50 -c 10 -p login-body.json -T application\/json http:\/\/localhost:3000\/login<\/code> og overv\u00e5g process.memoryUsage().heapUsed<\/code> via health-endpoint.<\/p>\n\n\n\n
Ved mystiske timing-fejl under migration: kontroll\u00e9r at alle Node.js-versioner i dit produktionsmilj\u00f8 er identiske. Node.js 10.5.0-11.x har en \u00e6ldre OpenSSL-version med anderledes standarder for maxmem. Containeris\u00e9r altid med en pinned Node.js-version (FROM node:22.14-alpine3.20<\/code>) for reproducerbare builds.<\/p>\n\n\n\n
Avancerede tips til produktionssystemer<\/h2>\n\n\n\n
Worker Thread-isolering:<\/strong> For applikationer med h\u00f8j login-trafik b\u00f8r du flytte scrypt-beregningerne til Worker Threads. En server med 4 CPU-kerner kan oprette 3 scrypt-workers og 1 main thread til HTTP-h\u00e5ndtering. Implement\u00e9r en simpel round-robin-scheduler der fordeler hash-requests til workers via parentPort.postMessage()<\/code>. Med denne arkitektur kan main thread fortsat betjene nye requests, health-checks og database-queries under intens login-belastning.<\/p>\n\n\n\n
Pepper som ekstra beskyttelseslag:<\/strong> En \"pepper\" er et hemmeligt, server-side-suffix tilf\u00f8jet til passwordet inden hashing. I mods\u00e6tning til salt gemmes pepper ikke i databasen, men kun i en milj\u00f8variabel eller et Key Management System. Selv hvis en angriber stj\u00e6ler hele databasen, kan de ikke cracke passwords uden at kende pepper. Brug pepper med: const peppered = password + process.env.PASSWORD_PEPPER<\/code> og hash derefter peppered<\/code>. Gem pepper aldrig i kode-repositoriet og roter den periodisk med lazy migration.<\/p>\n\n\n\n
Scrypt til n\u00f8gleafledning (ikke kun password-hashing):<\/strong> Scrypt er standardiseret i RFC 7914 prim\u00e6rt som en n\u00f8gleafledningsfunktion (KDF). WPA3-netv\u00e6rk bruger scrypt til at afkryptere den pre-shared n\u00f8gle fra et password. Du kan replikere dette i Node.js til envelope encryption: brug scrypt til at generere en 32-byte AES-n\u00f8gle fra et brugerpassword og krypter dine data med AES-256-GCM. Scrypt-n\u00f8glen b\u00f8r genereres med et unikt salt per krypteringsoperation og gemmes ved siden af de krypterede data. Kombiner med WebCrypto API i Node.js<\/a> til selve krypteringen.<\/p>\n\n\n\n
Adaptive parameter-revision:<\/strong> Hardware bliver kraftigere hvert \u00e5r. Angribere kan i 2026 bryde N=8.192 hashes 16 gange hurtigere end i 2018. Planl\u00e6g en halv\u00e5rlig revision af N-parameteren og dokument\u00e9r versionen i databaseskemaet. Som tommelfingerregel: fordobl N hvert 2. \u00e5r for at modsvare Moores lov. Med versionsbaseret lazy migration (se trin 9) er opgradering usynlig for brugerne.<\/p>\n\n\n\n
Integreret audit-log:<\/strong> Log alle login-h\u00e6ndelser til en separat tabel med timestamp, username, IP-adresse, User-Agent og resultat (success\/failure). Inklud\u00e9r aldrig password eller password_hash i logfiler. Brug HMAC-SHA256 som beskrevet i vores Node.js-guide<\/a> til at signere audit-log-poster kryptografisk, s\u00e5 en kompromitteret database ikke kan give en angriber mulighed for at slette beviser.<\/p>\n\n\n\n
Containerisering med korrekt RAM-allokering:<\/strong> I Docker og Kubernetes skal du eksplicit allokere nok RAM til scrypt. Med N=32.768 og 20 samtidige login kr\u00e6ver du 640 MB kun til hashing. S\u00e6t resources.limits.memory<\/code> i Kubernetes-manifestet til mindst 1 GB, og s\u00e6t Node.js heap-limit med --max-old-space-size=768<\/code> for at undg\u00e5 OOM-kills. Overv\u00e5g container_memory_usage_bytes<\/code> i Prometheus med en alert ved over 80% af gr\u00e6nsen.<\/p>\n\n\n\n
Relateret indhold<\/h2>\n\n\n\n
Relateret d\u00e6kning<\/h3>\n\n\n\n