Se il vostro software gestionale, il portale clienti o l’applicativo su misura conserva delle password, c’è un documento che vale mezz’ora di lettura: le linee guida “Funzioni Crittografiche — Conservazione delle Password”, firmate insieme da ACN e Garante privacy nel dicembre 2023.
E contiene una frase che sorprende chi sviluppa software da anni:
Per quanto riguarda bcrypt, esso risulta alquanto datato e non viene raccomandato, visto anche il numero di avanzamenti e miglioramenti ottenuti dagli altri algoritmi.
bcrypt è il meccanismo di default in una parte enorme dei framework applicativi. Non è un algoritmo esotico o una scelta trascurata: è quello che si ottiene seguendo la documentazione ufficiale di molti stack. E secondo ACN non è fra i raccomandati.
Prima di allarmarsi, il contesto: sono linee guida, non un regolamento. Chi adotta misure diverse può farlo, se è in grado di dimostrare che garantiscono un livello di sicurezza adeguato al rischio — è il principio di responsabilizzazione. Ma “dimostrare” è la parola operativa: se usate bcrypt, dovete poter spiegare perché.
A chi si applicano davvero
L’ambito è generale: riguardano chiunque conservi password nei propri sistemi. Il provvedimento indica però tre condizioni in cui l’adozione delle misure raccomandate è necessaria in particolare:
a) il trattamento riguarda le password di un numero significativo di utenti; b) il trattamento riguarda le password di utenti che possono accedere a banche di dati di particolare rilevanza o dimensioni; c) il trattamento riguarda le password di specifiche tipologie di utenti che, in modo sistematico, trattano, con l’ausilio di sistemi informatici, dati appartenenti a categorie particolari
La terza tocca più PMI di quanto sembri. Non parla della dimensione dell’azienda ma della natura dei dati trattati dagli utenti: uno studio medico, un’azienda con un applicativo HR, chi gestisce dati sanitari o giudiziari per conto terzi rientra in quella casella con venti utenti, non con ventimila.
I tre algoritmi raccomandati, con i parametri
La Tabella 1 del documento è la parte che serve a chi implementa. Questi sono i parametri minimi consigliati:
| Algoritmo | Parametri minimi |
|---|---|
| PBKDF2 | salt ≥ 128 bit · digest 128 bit · 600.000 iterazioni con HMAC-SHA256, oppure 210.000 con HMAC-SHA512 |
| scrypt | salt ≥ 128 bit · digest 128 bit · dimensione blocchi r = 8 · memoria e parallelizzazione in coppia: 128 MiB con p=1, 64 MiB con p=2, 32 MiB con p=3, 16 MiB con p=5, 8 MiB con p=10 |
| Argon2id | salt ≥ 128 bit · digest 128 bit · p=1 · iterazioni e memoria in coppia: c=1 con 46 MiB, c=2 con 19 MiB, c=3 con 12 MiB, c=4 con 9 MiB, c=5 con 7 MiB |
Il documento riporta anche un profilo più robusto, con digest a 256 bit e requisiti di memoria molto più alti. Prima di implementare, leggete la tabella nell’originale: qui l’abbiamo trascritta per orientarvi, ma i parametri di sicurezza si prendono dalla fonte, non da un articolo.
E la gerarchia fra i tre non è ambigua:
scrypt e Argon2id risultano gli algoritmi più robusti ed efficienti e dovrebbero essere prioritari rispetto a qualsiasi altra scelta
Nota su Argon2: la variante indicata è Argon2id, non Argon2i né Argon2d. Sulla scelta dei parametri il documento aggiunge un vincolo che si sbaglia facilmente — aumentare il grado di parallelizzazione p richiede necessariamente di aumentare anche le iterazioni o la memoria — e un criterio di dimensionamento sensato: parametri tali da garantire “una rapida esecuzione su una singola password, ma tale da rendere infattibile un numero elevato di esecuzioni”.
L’errore più grave non è nell’elenco
C’è un anti-pattern che il documento segnala a parte, e che nella pratica si incontra più spesso di bcrypt:
È importante non utilizzare direttamente le comuni funzioni di hash crittografiche, in quanto queste ultime risultano ottimizzate per effettuare calcoli in maniera molto rapida ed esistono metodi per velocizzare la generazione dei digest che renderebbero eventuali attacchi molto più veloci.
Tradotto: SHA256(password) non è conservazione sicura delle password, nemmeno con il salt. SHA-256 è progettato per essere veloce, e la velocità è esattamente ciò che aiuta l’attaccante che ha in mano l’archivio. Gli algoritmi di password hashing esistono per essere deliberatamente lenti e costosi in memoria.
È il difetto tipico dell’applicativo scritto in casa anni fa, o del gestionale verticale mai rivisto: nessuno ha salvato le password in chiaro — c’è un hash — ma è l’hash sbagliato.
Salt e pepper: la differenza che conta
Il salt è obbligatorio. Il documento è netto: “l’uso di un salt risulta una condizione obbligatoria per qualsiasi algoritmo di password hashing e si sconsiglia l’utilizzo di soluzioni personalizzate”. Deve essere generato casualmente per ogni password e avere lunghezza adeguata — la tabella fissa il minimo a 128 bit.
Il punto interessante è perché: il salt non rende più sicura la singola password. Rallenta l’attaccante sull’intero archivio, in modo proporzionale alla sua dimensione — due utenti con la stessa password ottengono digest diversi, e le rainbow table precalcolate diventano inutilizzabili.
Il pepper è un’altra cosa, ed è opzionale. A differenza del salt può essere lo stesso per tutte le password, ma deve restare segreto: funziona come chiave di un HMAC o di una cifratura applicata al digest. La conseguenza pratica è che il pepper non va nella stessa base dati dei digest — se finisce nel dump insieme a loro non ha aggiunto nulla.
Come si migra senza resettare le password a tutti
Qui c’è la risposta all’obiezione che blocca il 90% delle migrazioni: “non possiamo cambiare algoritmo, dovremmo far reimpostare la password a tutti gli utenti”. Non è vero, e le linee guida descrivono la strategia:
- Si applica la nuova funzione ai digest esistenti. Per ogni password si salva
H(h(P))al posto dih(P). Il documento chiarisce che “calcolare il digest di un digest non comporta un rischio per la sicurezza se si utilizzano funzioni di password hashing adeguate”. - Si marca ogni record con un flag che tiene traccia della necessità di aggiornare il digest.
- Al primo accesso di ogni utente, verificata la corrispondenza con il valore salvato, si ricalcola il digest direttamente dalla password inserita e si rimuove il flag.
Il risultato: l’archivio è protetto col nuovo algoritmo subito, non quando gli utenti si ricorderanno di accedere. E la conversione completa avviene da sé, con il normale traffico di login. È un intervento da poche giornate su un applicativo di dimensioni ordinarie.
Le tre domande da fare a chi ha scritto il vostro software
Se il codice non è vostro — un gestionale verticale, un portale fornito da terzi, un applicativo ereditato — sono le domande che discriminano una risposta reale da una rassicurazione:
- Quale funzione di password hashing usate, e con quali parametri? Una risposta come “usiamo l’hash” o “sono cifrate” non è una risposta: le password non si cifrano, si sottopongono a hashing, e la differenza non è terminologica.
- Il salt è generato casualmente per ogni utente, e di quanti bit? Un salt unico per l’applicazione, o derivato dallo username, non svolge la funzione descritta sopra.
- Come intendete migrare, e in quanto tempo? Con la strategia in tre passi la risposta “servirebbe un reset di massa” non è più accettabile.
Se invece il software è su misura e lo sviluppate voi o con noi, questa è una delle voci della checklist tecnica GDPR per software custom — e vale la pena verificarla anche sui progetti già in produzione, non solo su quelli nuovi.
Perché è anche un tema NIS2
La co-firma non è decorativa: queste linee guida le ha scritte ACN, la stessa Agenzia che vigila sull’attuazione della NIS2 e che dal 31 ottobre 2026 può iniziare a verificare le misure di base — ne abbiamo scritto nella guida a quella scadenza.
Per un soggetto nel perimetro NIS2, un archivio di password protetto con una funzione che l’Agenzia stessa ha indicato come datata è una posizione difficile da difendere in sede ispettiva. Non perché esista una norma che imponga Argon2id, ma perché l’adeguatezza si valuta rispetto allo stato dell’arte, e lo stato dell’arte qui è scritto e pubblicato da chi ispeziona.
Una nota che sdrammatizza
Sul quantum computing il documento è più tranquillo di molta divulgazione. Le funzioni di password hashing sono suscettibili all’algoritmo di Grover, ma questo “garantisce, tuttavia, solo un aumento quadratico della velocità degli attacchi di forza bruta”. La conseguenza è concreta: raddoppiare la dimensione del digest ripristina il livello di sicurezza attuale, rendendo di fatto vani i miglioramenti quantistici.
Detto altrimenti: le password non sono il fronte urgente della transizione post-quantistica. Le firme e gli scambi di chiavi sì.
Stato delle informazioni: verificate il 14 agosto 2026 sul testo delle linee guida ACN-Garante “Funzioni Crittografiche — Conservazione delle Password” (provvedimento del 7 dicembre 2023, pubblicato in Gazzetta Ufficiale il 19 gennaio 2024) e del documento tecnico allegato. I parametri riportati in tabella sono trascritti dalla Tabella 1 dell’allegato: prima di implementarli, verificateli sull’originale. Questo articolo non è una consulenza legale né una specifica di sicurezza: la scelta dei parametri va dimensionata sulla capacità di calcolo del vostro sistema.
Se sviluppiamo o manteniamo insieme un applicativo, la conservazione delle credenziali è una delle voci che verifichiamo nei progetti web application e backend e API. Se invece volete solo capire com’è configurato quello che avete oggi — anche se l’ha scritto qualcun altro — scriveteci: la verifica è più rapida di quanto sembri.