{"id":82,"date":"2026-06-12T16:30:08","date_gmt":"2026-06-12T16:30:08","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/12\/hashing-password-bcrypt-nodejs\/"},"modified":"2026-06-12T16:31:29","modified_gmt":"2026-06-12T16:31:29","slug":"hashing-password-bcrypt-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/12\/hashing-password-bcrypt-nodejs\/","title":{"rendered":"Hashing Password con bcrypt in Node.js: 12 Step [2026]"},"content":{"rendered":"\n

Ogni volta che un database di credenziali finisce online, la differenza tra un incidente gestibile e un disastro dipende da una scelta tecnica fatta mesi prima: come sono state archiviate le password. Salvarle in chiaro, o con un semplice MD5, significa regalare gli account agli attaccanti nel giro di minuti. Usare bcrypt<\/strong> con un cost factor adeguato significa costringerli a una battaglia di forza bruta che, nella pratica, non vincono. Questo tutorial mostra passo dopo passo come implementare l’hashing delle password con bcrypt in Node.js, dalla prima riga di codice fino a una API di autenticazione completa e pronta per la produzione.<\/p>\n\n\n\n

Seguirai 12 step concreti, con codice testato, esempi di output reali e una sezione di troubleshooting per gli errori pi\u00f9 frequenti. Alla fine avrai un progetto Express funzionante che registra utenti, verifica i login in modo sicuro, gestisce il limite dei 72 byte di bcrypt e ricalcola automaticamente gli hash quando l’hardware diventa pi\u00f9 potente. Tempo stimato: circa 30 minuti.<\/p>\n\n\n\n

Perch\u00e9 serve bcrypt nel 2026 (e perch\u00e9 non basta una hash function)<\/h2>\n\n\n\n

Una funzione hash crittografica come SHA-256 \u00e8 progettata per essere veloce. \u00c8 esattamente la propriet\u00e0 sbagliata per le password. Una GPU moderna calcola miliardi di hash SHA-256 al secondo, quindi un attaccante che ruba un database di hash SHA-256 pu\u00f2 testare interi dizionari e liste di password trapelate in pochi minuti. Le password non vanno trattate come dati da indicizzare, vanno trattate come segreti da rendere costosi da indovinare.<\/p>\n\n\n\n

bcrypt risolve il problema con un approccio deliberatamente lento e adattivo. Si basa sul cifrario Blowfish e introduce un parametro di costo (il cost factor) che determina quante iterazioni il calcolo deve eseguire. Il costo cresce in modo esponenziale: ogni incremento di un’unit\u00e0 raddoppia il tempo di calcolo, perch\u00e9 il lavoro \u00e8 pari a 2 elevato al valore del cost. Questo rende l’hashing abbastanza veloce per un login legittimo (frazioni di secondo) ma proibitivo per chi prova miliardi di combinazioni.<\/p>\n\n\n\n

La parola chiave \u00e8 “adattivo”. bcrypt esiste dal 1999, ma \u00e8 ancora raccomandato dall’OWASP nel 2026 proprio perch\u00e9 il cost factor si pu\u00f2 aumentare nel tempo. Quando, fra cinque anni, le GPU saranno il doppio pi\u00f9 veloci, ti baster\u00e0 alzare il costo di un’unit\u00e0 per riportare la difesa al punto di partenza. Nessun’altra propriet\u00e0 di sicurezza invecchia cos\u00ec bene.<\/p>\n\n\n\n

bcrypt incorpora inoltre un salt univoco e casuale dentro ogni hash. Il salt impedisce gli attacchi con rainbow table (tabelle precalcolate) e garantisce che due utenti con la stessa password ottengano hash completamente diversi. Non devi gestire il salt separatamente: la libreria lo genera, lo usa e lo memorizza dentro la stringa finale. \u00c8 uno dei motivi per cui bcrypt resta cos\u00ec semplice da usare correttamente.<\/p>\n\n\n\n

Prerequisiti e versioni necessarie<\/h2>\n\n\n\n

Prima di scrivere codice, assicurati di avere l’ambiente corretto. Questo tutorial usa la libreria nativa bcrypt<\/code> (binding C++ ad alte prestazioni) e, in alternativa, accenna a bcryptjs<\/code> per gli ambienti dove non puoi compilare moduli nativi. La tabella seguente riassume cosa ti serve.<\/p>\n\n\n\n

Componente<\/th>Versione consigliata<\/th>Note<\/th><\/tr><\/thead>
Node.js<\/td>20 LTS o 22 LTS<\/td>Necessario per il binding nativo di bcrypt<\/td><\/tr>
npm<\/td>10 o superiore<\/td>Incluso con Node.js<\/td><\/tr>
bcrypt<\/td>6.0.0 (ultima versione)<\/td>Circa 4,8 milioni di download settimanali<\/td><\/tr>
bcryptjs<\/td>ultima versione<\/td>Pura JavaScript, zero dipendenze, per serverless<\/td><\/tr>
express<\/td>4.x o 5.x<\/td>Per la API di esempio degli step 7-9<\/td><\/tr>
Build tools<\/td>Python 3 + compilatore C<\/td>Solo per il pacchetto nativo bcrypt<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Verifica la tua versione di Node.js prima di iniziare. Un binding nativo come bcrypt richiede una versione supportata, e le release pi\u00f9 vecchie (sotto Node 18) non ricevono pi\u00f9 aggiornamenti di sicurezza.<\/p>\n\n\n\n

node --version\n# Output atteso: v20.x.x oppure v22.x.x\n\nnpm --version\n# Output atteso: 10.x.x<\/code><\/pre>\n\n\n\n
Se non hai una toolchain C disponibile (capita spesso su immagini Docker minimali o su alcune piattaforme serverless), usa bcryptjs<\/code> al posto di bcrypt<\/code>. L’API \u00e8 quasi identica e tutto il codice di questo tutorial funziona cambiando solo la riga di import. Ne parliamo nello step 11.<\/p>\n\n\n\n
Anatomia di un hash bcrypt: come leggere la stringa $2b$<\/h2>\n\n\n\n
Un hash bcrypt \u00e8 una stringa autocontenuta di 60 caratteri. Tutto ci\u00f2 che serve per verificare una password (algoritmo, costo, salt e digest) \u00e8 impacchettato in quella stringa. Capirne la struttura ti aiuta a fare debug e a non commettere errori di archiviazione nel database.<\/p>\n\n\n\n
$2b$12$R9h\/cIPz0gi.URNNX3kh2OPST9\/PgBkqquzi.Ss7KIUgO2t0jWMUW\n |  |  |                     |\n |  |  |                     +-- digest (31 caratteri, l'hash vero e proprio)\n |  |  +------------------------ salt (22 caratteri, generato casualmente)\n |  +--------------------------- cost factor (qui 12, cioe 2^12 iterazioni)\n +------------------------------ identificatore di versione ($2b$)<\/code><\/pre>\n\n\n\n
La tabella riassume i quattro segmenti. Quando li conosci, capisci a colpo d’occhio con quale costo \u00e8 stato generato un hash e se \u00e8 il momento di ricalcolarlo.<\/p>\n\n\n\n
Segmento<\/th>Esempio<\/th>Significato<\/th><\/tr><\/thead>
Prefisso versione<\/td>$2b$<\/td>Variante moderna e sicura dell’algoritmo<\/td><\/tr>
Cost factor<\/td>12<\/td>Numero di round, lavoro pari a 2^12 = 4096 iterazioni<\/td><\/tr>
Salt<\/td>22 caratteri base64<\/td>Valore casuale, diverso per ogni hash<\/td><\/tr>
Digest<\/td>31 caratteri base64<\/td>Risultato del calcolo Blowfish<\/td><\/tr>
Lunghezza totale<\/td>60 caratteri<\/td>Dimensiona cos\u00ec la colonna del database<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Errore frequente: dimensionare la colonna del database a 32 o 40 caratteri pensando a un hash “tipico”. Un hash bcrypt occupa sempre 60 caratteri. Usa VARCHAR(60)<\/code> come minimo, oppure VARCHAR(72)<\/code> per avere margine in caso di prefissi futuri. Una colonna troppo corta tronca l’hash in silenzio e rende impossibile ogni login successivo.<\/p>\n\n\n\n
bcrypt vs Argon2 vs scrypt: quale algoritmo scegliere<\/h2>\n\n\n\n
bcrypt non \u00e8 l’unica opzione. Le tre alternative serie nel 2026 sono bcrypt, Argon2 e scrypt. La differenza fondamentale \u00e8 il tipo di risorsa che rendono costosa: bcrypt \u00e8 CPU-hard (consuma cicli di processore), mentre Argon2 e scrypt sono memory-hard (consumano grandi quantit\u00e0 di RAM). La durezza in memoria \u00e8 pi\u00f9 efficace contro gli attacchi con hardware specializzato come gli ASIC, perch\u00e9 la memoria veloce \u00e8 costosa da scalare.<\/p>\n\n\n\n
Caratteristica<\/th>bcrypt<\/th>Argon2id<\/th>scrypt<\/th><\/tr><\/thead>
Tipo di durezza<\/td>CPU<\/td>Memoria + CPU<\/td>Memoria<\/td><\/tr>
Anno di nascita<\/td>1999<\/td>2015 (vincitore PHC)<\/td>2009<\/td><\/tr>
Supporto in Node.js<\/td>Pacchetto bcrypt<\/td>Pacchetto argon2<\/td>Nativo (crypto.scrypt)<\/td><\/tr>
Parametri da regolare<\/td>1 (cost)<\/td>3 (memoria, iterazioni, parallelismo)<\/td>3 (N, r, p)<\/td><\/tr>
Limite input<\/td>72 byte<\/td>Nessun limite pratico<\/td>Nessun limite pratico<\/td><\/tr>
Raccomandazione OWASP<\/td>Accettato, cost >= 10<\/td>Preferito (19 MiB, 2 iter, 1 par)<\/td>Accettato<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
La guida OWASP sullo storage delle password preferisce Argon2id, ma bcrypt resta una scelta pienamente accettata e, per molti progetti, la pi\u00f9 pragmatica. \u00c8 maturo, ha un solo parametro da regolare, \u00e8 disponibile ovunque ed \u00e8 praticamente impossibile da configurare male. Se stai partendo da zero e vuoi il massimo, valuta Argon2id. Se vuoi qualcosa di robusto, semplice e a prova di errore, bcrypt \u00e8 la risposta giusta. Per un confronto sui fondamenti, leggi anche la nostra guida sulle funzioni hash crittografiche<\/a>.<\/p>\n\n\n\n
Step 1-3: Creare il progetto e installare bcrypt<\/h2>\n\n\n\n
Iniziamo dalle fondamenta. Creiamo una cartella di progetto, inizializziamo npm e installiamo le dipendenze. Tutto il tutorial costruisce un’unica applicazione coerente, quindi i comandi che seguono sono il punto di partenza.<\/p>\n\n\n\n
Step 1: Inizializzare la cartella di progetto<\/h3>\n\n\n\n
mkdir bcrypt-auth-demo\ncd bcrypt-auth-demo\nnpm init -y\n\n# Output:\n# Wrote to \/percorso\/bcrypt-auth-demo\/package.json<\/code><\/pre>\n\n\n\n
Step 2: Installare bcrypt ed Express<\/h3>\n\n\n\n
npm install bcrypt express\n\n# Output atteso (le versioni esatte possono variare):\n# added 57 packages, and audited 58 packages in 4s\n# found 0 vulnerabilities<\/code><\/pre>\n\n\n\n
Se l’installazione di bcrypt fallisce con un errore di compilazione (node-gyp), salta direttamente allo step 11 dove usiamo bcryptjs<\/code>, che non richiede alcuna compilazione. Per ora, procediamo con il pacchetto nativo.<\/p>\n\n\n\n
Step 3: Abilitare i moduli ES e la struttura base<\/h3>\n\n\n\n
Apri package.json<\/code> e aggiungi \"type\": \"module\"<\/code> per usare la sintassi import moderna. Poi crea un file hash.js<\/code> vuoto. La struttura del progetto \u00e8 minimale e cresce a ogni step.<\/p>\n\n\n\n
\/\/ package.json (estratto)\n{\n  \"name\": \"bcrypt-auth-demo\",\n  \"version\": \"1.0.0\",\n  \"type\": \"module\",\n  \"dependencies\": {\n    \"bcrypt\": \"^6.0.0\",\n    \"express\": \"^4.21.0\"\n  }\n}<\/code><\/pre>\n\n\n\n
Step 4-6: Hashing, verifica e scelta del cost factor<\/h2>\n\n\n\n
Ora il cuore del tutorial: trasformare una password in un hash bcrypt e verificarla. Sono tre operazioni distinte, ognuna con la sua funzione asincrona dedicata.<\/p>\n\n\n\n
Step 4: Generare un hash con bcrypt<\/h3>\n\n\n\n
Scrivi questo codice in hash.js<\/code>. La funzione bcrypt.hash<\/code> prende la password in chiaro e il cost factor, genera automaticamente un salt casuale e restituisce la stringa di 60 caratteri. Usa sempre la versione asincrona basata su promise: la versione sincrona (hashSync<\/code>) blocca l’event loop e va evitata in un server.<\/p>\n\n\n\n
import bcrypt from 'bcrypt';\n\nconst COST = 12;\n\nasync function creaHash(password) {\n  const hash = await bcrypt.hash(password, COST);\n  return hash;\n}\n\nconst hash = await creaHash('passwordSuperSegreta!');\nconsole.log(hash);\n\/\/ Output: $2b$12$R9h\/cIPz0gi.URNNX3kh2OPST9\/PgBk...\n\/\/ La tua stringa sara diversa: il salt e casuale.<\/code><\/pre>\n\n\n\n
Esegui con node hash.js<\/code>. Nota che eseguendo il file due volte ottieni due hash diversi, anche con la stessa password. \u00c8 il salt al lavoro: questa \u00e8 la propriet\u00e0 che neutralizza le rainbow table.<\/p>\n\n\n\n
Step 5: Verificare una password con bcrypt.compare<\/h3>\n\n\n\n
Per verificare un login non si decifra l’hash (\u00e8 impossibile, \u00e8 una funzione a senso unico). Si passa la password fornita e l’hash memorizzato a bcrypt.compare<\/code>, che estrae salt e costo dall’hash, ricalcola e confronta. La funzione restituisce un booleano.<\/p>\n\n\n\n
async function verifica(password, hashMemorizzato) {\n  const corretta = await bcrypt.compare(password, hashMemorizzato);\n  return corretta;\n}\n\nconsole.log(await verifica('passwordSuperSegreta!', hash));\n\/\/ Output: true\n\nconsole.log(await verifica('passwordSbagliata', hash));\n\/\/ Output: false<\/code><\/pre>\n\n\n\n
Un dettaglio cruciale di sicurezza: bcrypt.compare<\/code> esegue un confronto a tempo costante. Non interrompe il calcolo al primo byte diverso, quindi non rivela informazioni tramite il tempo di risposta. Non sostituire mai questa funzione con un confronto manuale di stringhe (===<\/code>): apriresti la porta agli attacchi di timing.<\/p>\n\n\n\n
Step 6: Misurare e scegliere il cost factor giusto<\/h3>\n\n\n\n
Il cost factor \u00e8 la decisione di sicurezza pi\u00f9 importante. Troppo basso, e l’hash \u00e8 debole. Troppo alto, e ogni login rallenta e il server diventa vulnerabile ad attacchi di tipo denial of service via login ripetuti. L’obiettivo pratico \u00e8 che un singolo hash richieda tra 250 e 500 millisecondi sull’hardware di produzione. Misura sempre sul tuo server reale.<\/p>\n\n\n\n
import bcrypt from 'bcrypt';\n\nfor (const cost of [10, 11, 12, 13, 14]) {\n  const inizio = process.hrtime.bigint();\n  await bcrypt.hash('benchmark', cost);\n  const fine = process.hrtime.bigint();\n  const ms = Number(fine - inizio) \/ 1_000_000;\n  console.log(`cost ${cost}: ${ms.toFixed(0)} ms`);\n}\n\n\/\/ Esempio di output su un core a 2 GHz:\n\/\/ cost 10: 65 ms\n\/\/ cost 11: 130 ms\n\/\/ cost 12: 260 ms\n\/\/ cost 13: 520 ms\n\/\/ cost 14: 1040 ms<\/code><\/pre>\n\n\n\n
Nota il raddoppio a ogni incremento: \u00e8 la natura esponenziale di 2 elevato al cost. La guida OWASP fissa il minimo a 10. Nel 2026, per i login interattivi, il valore predefinito ragionevole \u00e8 12, da alzare a 13 o 14 su hardware potente. La tabella seguente riassume i compromessi.<\/p>\n\n\n\n
Cost factor<\/th>Iterazioni (2^cost)<\/th>Tempo indicativo<\/th>Uso consigliato<\/th><\/tr><\/thead>
10<\/td>1.024<\/td>~65 ms<\/td>Minimo OWASP assoluto<\/td><\/tr>
11<\/td>2.048<\/td>~130 ms<\/td>Hardware modesto<\/td><\/tr>
12<\/td>4.096<\/td>~260 ms<\/td>Default consigliato 2026<\/td><\/tr>
13<\/td>8.192<\/td>~520 ms<\/td>Server moderni<\/td><\/tr>
14<\/td>16.384<\/td>~1040 ms<\/td>Massima sicurezza, dati sensibili<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Step 7-9: Costruire l’API di autenticazione con Express<\/h2>\n\n\n\n
Mettiamo insieme i pezzi in una API reale. Costruiamo due endpoint: registrazione (\/register<\/code>) e login (\/login<\/code>). Per semplicit\u00e0 usiamo un archivio in memoria, ma il flusso \u00e8 identico con un database vero come PostgreSQL o MongoDB.<\/p>\n\n\n\n
Step 7: L’endpoint di registrazione<\/h3>\n\n\n\n
Crea un file server.js<\/code>. L’endpoint di registrazione riceve email e password, genera l’hash con bcrypt e lo memorizza. La password in chiaro non tocca mai il database e non viene mai loggata.<\/p>\n\n\n\n
import express from 'express';\nimport bcrypt from 'bcrypt';\n\nconst app = express();\napp.use(express.json());\n\nconst COST = 12;\nconst utenti = new Map(); \/\/ sostituisci con un database reale\n\napp.post('\/register', async (req, res) => {\n  const { email, password } = req.body;\n\n  if (!email || !password) {\n    return res.status(400).json({ errore: 'Email e password obbligatorie' });\n  }\n  if (utenti.has(email)) {\n    return res.status(409).json({ errore: 'Utente gia registrato' });\n  }\n\n  const hash = await bcrypt.hash(password, COST);\n  utenti.set(email, { email, hash });\n\n  res.status(201).json({ messaggio: 'Registrazione completata' });\n});<\/code><\/pre>\n\n\n\n
Step 8: L’endpoint di login<\/h3>\n\n\n\n
Il login recupera l’utente, confronta la password con bcrypt.compare<\/code> e risponde. Nota un dettaglio di sicurezza importante: il messaggio di errore \u00e8 identico sia che l’utente non esista, sia che la password sia sbagliata. Rivelare quale dei due \u00e8 fallito aiuterebbe un attaccante a enumerare gli account validi.<\/p>\n\n\n\n
app.post('\/login', async (req, res) => {\n  const { email, password } = req.body;\n  const utente = utenti.get(email);\n\n  \/\/ Messaggio generico: niente enumerazione degli account\n  const erroreGenerico = { errore: 'Credenziali non valide' };\n\n  if (!utente) {\n    \/\/ Esegui comunque un confronto fittizio per non rivelare nulla via timing\n    await bcrypt.compare(password, '$2b$12$invalidinvalidinvalidinvalidinvalidinvalidinv');\n    return res.status(401).json(erroreGenerico);\n  }\n\n  const corretta = await bcrypt.compare(password, utente.hash);\n  if (!corretta) {\n    return res.status(401).json(erroreGenerico);\n  }\n\n  res.json({ messaggio: 'Login riuscito', email });\n});\n\napp.listen(3000, () => console.log('Server in ascolto sulla porta 3000'));<\/code><\/pre>\n\n\n\n
Step 9: Testare l’API con curl<\/h3>\n\n\n\n
Avvia il server con node server.js<\/code> e prova gli endpoint da un altro terminale. Ecco il flusso completo registrazione e login con l’output atteso.<\/p>\n\n\n\n
curl -X POST http:\/\/localhost:3000\/register \\\n  -H 'Content-Type: application\/json' \\\n  -d '{\"email\":\"mario@example.com\",\"password\":\"Tornado-Viola-92!\"}'\n# Output: {\"messaggio\":\"Registrazione completata\"}\n\ncurl -X POST http:\/\/localhost:3000\/login \\\n  -H 'Content-Type: application\/json' \\\n  -d '{\"email\":\"mario@example.com\",\"password\":\"Tornado-Viola-92!\"}'\n# Output: {\"messaggio\":\"Login riuscito\",\"email\":\"mario@example.com\"}\n\ncurl -X POST http:\/\/localhost:3000\/login \\\n  -H 'Content-Type: application\/json' \\\n  -d '{\"email\":\"mario@example.com\",\"password\":\"sbagliata\"}'\n# Output: {\"errore\":\"Credenziali non valide\"}<\/code><\/pre>\n\n\n\n
Hai un’API di autenticazione funzionante. Per completarla con i token di sessione, leggi la nostra guida sull’autenticazione JWT in Node.js<\/a>, che si combina perfettamente con il flusso di login appena costruito.<\/p>\n\n\n\n
Step 10: Ricalcolare gli hash al login (rehash adattivo)<\/h2>\n\n\n\n
Qui sfruttiamo la vera superpotenza di bcrypt: l’adattivit\u00e0. Quando alzi il cost factor predefinito (per esempio da 12 a 13), gli hash gi\u00e0 nel database restano al vecchio costo. Non puoi ricalcolarli senza la password in chiaro, ma c’\u00e8 un momento perfetto in cui ce l’hai: il login. La strategia \u00e8 verificare la password, e se l’hash usa un costo inferiore a quello attuale, rigenerarlo in modo trasparente.<\/p>\n\n\n\n
import bcrypt from 'bcrypt';\n\nconst COST_ATTUALE = 13;\n\nasync function loginConRehash(password, utente) {\n  const corretta = await bcrypt.compare(password, utente.hash);\n  if (!corretta) return false;\n\n  \/\/ Estrai il costo dall'hash memorizzato\n  const costoHash = bcrypt.getRounds(utente.hash);\n\n  if (costoHash < COST_ATTUALE) {\n    \/\/ La password e corretta e l'abbiamo in chiaro: aggiorniamo l'hash\n    utente.hash = await bcrypt.hash(password, COST_ATTUALE);\n    \/\/ salva utente.hash nel database\n    console.log(`Hash aggiornato da costo ${costoHash} a ${COST_ATTUALE}`);\n  }\n  return true;\n}<\/code><\/pre>\n\n\n\n
La funzione bcrypt.getRounds<\/code> legge il cost factor direttamente dalla stringa dell’hash. Con questo schema, il tuo intero database migra gradualmente al nuovo costo man mano che gli utenti accedono, senza interruzioni e senza dover mai chiedere a nessuno di reimpostare la password. \u00c8 il pattern che separa un’implementazione amatoriale da una professionale.<\/p>\n\n\n\n
Step 11: Il limite dei 72 byte e il pre-hashing<\/h2>\n\n\n\n
bcrypt ha un limite poco conosciuto ma critico: ignora tutto ci\u00f2 che supera i 72 byte di input. Attenzione, sono 72 byte, non 72 caratteri. Un carattere accentato o un’emoji in UTF-8 pu\u00f2 occupare fino a 4 byte, quindi una passphrase lunga pu\u00f2 raggiungere il limite prima di quanto pensi. Tutto ci\u00f2 che eccede viene troncato in silenzio, il che significa che due password diverse ma con gli stessi primi 72 byte risultano equivalenti.<\/p>\n\n\n\n
La soluzione raccomandata dall’OWASP \u00e8 il pre-hashing: prima di passare la password a bcrypt, calcola un digest SHA-256 e codificalo in base64. Lo SHA-256 produce sempre 32 byte, e la sua codifica base64 sta comodamente sotto i 72 byte, eliminando il problema del troncamento qualunque sia la lunghezza originale della password.<\/p>\n\n\n\n
import bcrypt from 'bcrypt';\nimport { createHash } from 'node:crypto';\n\nconst COST = 12;\n\nfunction preHash(password) {\n  \/\/ SHA-256 -> 32 byte, poi base64 -> ~44 caratteri, sempre sotto i 72 byte\n  return createHash('sha256').update(password).digest('base64');\n}\n\nasync function hashSicuro(password) {\n  return bcrypt.hash(preHash(password), COST);\n}\n\nasync function verificaSicura(password, hash) {\n  return bcrypt.compare(preHash(password), hash);\n}\n\n\/\/ Funziona anche con password lunghissime\nconst lunga = 'a'.repeat(200) + ' caffe ristretto doppio';\nconst h = await hashSicuro(lunga);\nconsole.log(await verificaSicura(lunga, h)); \/\/ true<\/code><\/pre>\n\n\n\n
Una sola avvertenza: se adotti il pre-hashing, devi applicarlo in modo coerente sia in fase di hashing sia in fase di verifica. E se hai gi\u00e0 un database di hash creati senza pre-hashing, non puoi cambiare strategia retroattivamente. In quel caso, migra al nuovo schema al login, con lo stesso pattern di rehash dello step 10.<\/p>\n\n\n\n
Usare bcryptjs negli ambienti serverless<\/h3>\n\n\n\n
Se non puoi compilare moduli nativi (AWS Lambda con runtime limitati, edge function, alcuni container), sostituisci bcrypt<\/code> con bcryptjs<\/code>, l’implementazione in pura JavaScript con zero dipendenze. \u00c8 pi\u00f9 lenta del binding nativo, ma a livello di codice cambia solo l’import: tutte le funzioni (hash<\/code>, compare<\/code>, getRounds<\/code>) hanno la stessa firma.<\/p>\n\n\n\n
npm install bcryptjs\n\n# Nel codice, cambia solo questa riga:\n# import bcrypt from 'bcrypt';\nimport bcrypt from 'bcryptjs';\n# Tutto il resto del tutorial funziona identico.<\/code><\/pre>\n\n\n\n
Step 12: Validazione delle password e blocklist (NIST 2026)<\/h2>\n\n\n\n
Un hashing impeccabile non serve a nulla se l’utente sceglie “password123”. L’ultimo step aggiunge una validazione conforme alle linee guida NIST SP 800-63B (confermate nella revisione 800-63-4 del 2024). Le regole moderne ribaltano i vecchi dogmi.<\/p>\n\n\n\n
Il NIST richiede di accettare password lunghe almeno fino a 64 caratteri e di imporre un minimo di almeno 8 caratteri. Soprattutto, il NIST sconsiglia le regole di composizione obbligatorie (la classica imposizione di maiuscole, numeri e simboli) perch\u00e9 spingono gli utenti verso schemi prevedibili. La regola davvero efficace \u00e8 un’altra: controllare la password contro una blocklist di password compromesse, trapelate in violazioni passate o troppo comuni.<\/p>\n\n\n\n
const BLOCKLIST = new Set([\n  'password', '123456', '12345678', 'qwerty',\n  'password123', 'admin', 'iloveyou', 'letmein'\n  \/\/ in produzione: carica una lista reale di password trapelate\n]);\n\nfunction validaPassword(password) {\n  if (typeof password !== 'string') return 'Password non valida';\n  if (password.length < 8) return 'Minimo 8 caratteri';\n  if (password.length > 64) return 'Massimo 64 caratteri';\n  if (BLOCKLIST.has(password.toLowerCase())) {\n    return 'Questa password e troppo comune o compromessa';\n  }\n  return null; \/\/ null significa: password valida\n}\n\nconst errore = validaPassword('password');\nconsole.log(errore); \/\/ \"Questa password e troppo comune o compromessa\"<\/code><\/pre>\n\n\n\n
In produzione, sostituisci la blocklist di esempio con un controllo serio. Il servizio “Pwned Passwords” di Have I Been Pwned espone una API basata su k-anonymity che permette di verificare se una password \u00e8 apparsa in una violazione senza mai inviarla per intero. Combinata con bcrypt, questa validazione copre la maggior parte dei rischi reali sugli account.<\/p>\n\n\n\n
5 errori comuni da evitare con bcrypt<\/h2>\n\n\n\n
La maggior parte delle vulnerabilit\u00e0 non nasce da un difetto di bcrypt, ma da un uso sbagliato. Ecco i cinque errori che vediamo pi\u00f9 spesso nelle code review.<\/p>\n\n\n\n