PBKDF2 spiegato: la funzione di derivazione delle chiavi basata su password che protegge il tuo vault

TL;DR

PBKDF2 (Password-Based Key Derivation Function 2) è un algoritmo di key stretching definito in RFC 2898. Applica una funzione pseudo-casuale (tipicamente HMAC-SHA256) molte volte a una password e un salt, producendo una chiave derivata. Il conteggio delle iterazioni rende gli attacchi di forza bruta esponenzialmente più costosi. OWASP raccomanda 600.000 iterazioni per SHA-256 a partire dal 2026. AppVault utilizza PBKDF2 con 600.000 iterazioni, un salt da 128 bit per installazione e avvolge l'output con una chiave del Secure Enclave per una protezione legata all'hardware.

Ogni volta che sblocchi il tuo iPhone, inserisci una password su un sito web o apri un vault di file, un software trasforma il tuo segreto in una chiave crittografica. Quella trasformazione non è un semplice hash. È una funzione progettata con cura per rendere costosi gli attacchi di forza bruta. La più diffusa di queste funzioni è PBKDF2.

PBKDF2 sta per Password-Based Key Derivation Function 2. È definita in RFC 2898 (PKCS #5 v2.0) ed è uno standard raccomandato dal NIST da oltre due decenni. Prende una password, un salt, un conteggio di iterazioni e una lunghezza di chiave desiderata, e produce una chiave derivata che può essere utilizzata per crittografia, autenticazione o altre operazioni crittografiche.

Questo articolo spiega come funziona PBKDF2, perché l’hashing diretto è insufficiente, il ruolo dei salt e del conteggio delle iterazioni, la raccomandazione OWASP 2026 di 600.000 iterazioni per SHA-256, e come PBKDF2 si confronta con alternative moderne come Argon2id, bcrypt e scrypt. Descrive anche come AppVault utilizza PBKDF2 come parte del suo stack di crittografia.

Perché l’Hashing Diretto Fallisce

Se prendi una password e calcoli il suo hash SHA-256, ottieni un valore a 256 bit. Quel valore può essere usato come chiave. Il problema è la velocità. Una GPU moderna può calcolare miliardi di hash SHA-256 al secondo. Un attaccante con una singola GPU consumer può provare tutte le password di 8 caratteri minuscoli in pochi minuti.

L’hashing diretto non ha nemmeno protezione integrata contro la precomputazione. Senza un salt, la stessa password produce sempre lo stesso hash. Gli attaccanti possono costruire tabelle arcobaleno — catene di hash precomputate — e cercare l’hash per recuperare la password istantaneamente.

PBKDF2 risolve entrambi i problemi. Ripete l’hash migliaia di volte, rendendo ogni tentativo computazionalmente costoso. Richiede un salt, quindi password identiche producono chiavi diverse. La combinazione di conteggio di iterazioni e salt trasforma un hash veloce in una derivazione lenta e unica.

Come Funziona PBKDF2

PBKDF2 è costruito su una funzione pseudo-casuale (PRF), tipicamente HMAC-SHA256 o HMAC-SHA1. L’algoritmo funziona come segue:

1. La password e il salt vengono combinati.
2. La PRF viene applicata al salt concatenato con un contatore di blocco (per lunghezze di chiave superiori all’output della PRF).
3. L’output viene XORato con il risultato dell’iterazione precedente (per la prima iterazione, il risultato precedente è l’output della PRF stesso).
4. I passaggi 2-3 vengono ripetuti per il numero specificato di iterazioni.
5. L’output finale è la chiave derivata.

Il conteggio delle iterazioni è il parametro critico. Ogni iterazione aggiunge una quantità fissa di lavoro. Se un attaccante vuole testare una password, deve eseguire l’intera catena di iterazioni. Con 600.000 iterazioni, un singolo tentativo di password richiede circa 600.000 volte più tempo di un singolo hash SHA-256.

Il salt deve essere unico per utente o per installazione. Un salt a 128 bit (16 byte) è il minimo raccomandato dal NIST. Il salt viene memorizzato insieme alla chiave derivata (o nei metadati del vault) in modo che la derivazione possa essere ripetuta durante l’autenticazione.

La Raccomandazione OWASP 2026

OWASP pubblica un Password Storage Cheat Sheet che fornisce raccomandazioni sul conteggio delle iterazioni per varie funzioni di derivazione delle chiavi. A partire dal 2026, la raccomandazione per PBKDF2-HMAC-SHA256 è di 600.000 iterazioni. Per PBKDF2-HMAC-SHA1, la raccomandazione è di 1.300.000 iterazioni, perché SHA1 produce un output a 160 bit ed è leggermente più veloce per iterazione.

Questi numeri non sono arbitrari. Sono calibrati in modo che un singolo tentativo di password richieda circa 0,1 secondi su hardware consumer moderno. Quel ritardo è impercettibile per un utente legittimo, ma rende gli attacchi di forza bruta proibitivamente lenti. Un attaccante con un cluster di 100 GPU può tentare solo poche centinaia di password al secondo, non miliardi.

Il conteggio delle iterazioni dovrebbe essere aumentato nel tempo man mano che l’hardware migliora. OWASP aggiorna periodicamente le sue raccomandazioni. AppVault utilizza 600.000 iterazioni per PBKDF2-HMAC-SHA256, in linea con la linea guida 2026.

Compromessi del Conteggio di Iterazioni

Conteggi di iterazioni più elevati rendono gli attacchi di forza bruta più difficili, ma aumentano anche il tempo necessario per derivare la chiave sul dispositivo legittimo. Su un iPhone, 600.000 iterazioni di HMAC-SHA256 richiedono circa 0,2 secondi. Questo è accettabile per uno sblocco del vault. Ma se il conteggio delle iterazioni fosse aumentato a 10 milioni, il tempo di sblocco supererebbe i 3 secondi, degradando l’esperienza utente.

C’è anche un compromesso sul consumo energetico. I dispositivi mobili hanno una batteria limitata. Ogni iterazione consuma cicli della CPU. AppVault bilancia sicurezza e usabilità scegliendo un conteggio di iterazioni che fornisce una forte protezione senza scaricare la batteria o frustrare l’utente.

Un altro compromesso è l’uso della memoria. PBKDF2 non è memory-hard. Utilizza una piccola quantità fissa di memoria indipendentemente dal conteggio delle iterazioni. Questo lo rende vulnerabile ad attacchi GPU e ASIC che possono parallelizzare molti tentativi di password. Le funzioni memory-hard come Argon2id e scrypt richiedono una grande quantità di memoria per tentativo, rendendo gli attacchi paralleli molto più costosi. PBKDF2 compensa la sua mancanza di memory hardness con un alto conteggio di iterazioni e, nel caso di AppVault, con il binding hardware tramite il Secure Enclave.

PBKDF2 vs. Argon2id, bcrypt e scrypt

PBKDF2 non è l’unica funzione di derivazione delle chiavi basata su password. Altre tre funzioni sono comunemente usate: bcrypt, scrypt e Argon2id. Ognuna ha diversi obiettivi di design e proprietà di sicurezza.

Bcrypt è stato progettato nel 1999 e utilizza un key schedule basato su Blowfish. È resistente agli attacchi GPU perché richiede una quantità fissa di memoria (4 KB) e ha un fattore di costo integrato. Bcrypt è ampiamente supportato ma ha una lunghezza massima della password di 72 byte. Non è raccomandato per nuovi sistemi perché è più lento sulle CPU di Argon2id e non supporta l’uso variabile della memoria.

Scrypt è stato progettato nel 2009 ed è memory-hard. Richiede una grande quantità di memoria (configurabile) e tempo CPU. Scrypt è resistente agli attacchi ASIC e GPU perché la larghezza di banda della memoria diventa il collo di bottiglia. È utilizzato in alcuni portafogli di criptovalute e strumenti di crittografia dei file. Tuttavia, scrypt è meno ampiamente implementato di PBKDF2 e non ha uno standard NIST.

Argon2id è il vincitore del Password Hashing Competition del 2015. È il KDF più moderno e raccomandato per nuovi sistemi. Argon2id è memory-hard, CPU-hard e resistente agli attacchi side-channel. Ha tre varianti: Argon2d (dipendente dai dati), Argon2i (indipendente dai dati) e Argon2id (ibrido). OWASP raccomanda Argon2id per nuove applicazioni.

PBKDF2 rimane il KDF più ampiamente distribuito perché è semplice, standardizzato e disponibile in ogni libreria crittografica principale. È il default in CommonCrypto di iOS, KeyStore di Android e molti sistemi aziendali. Per applicazioni che non possono utilizzare Argon2id a causa di limitazioni della piattaforma o requisiti di compatibilità, PBKDF2 con un alto conteggio di iterazioni e binding hardware è una scelta solida.

Come AppVault Utilizza PBKDF2

AppVault utilizza PBKDF2-HMAC-SHA256 con 600.000 iterazioni e un salt da 128 bit per installazione. Il salt viene generato durante la configurazione iniziale e memorizzato nel Secure Enclave del dispositivo. La chiave derivata viene poi avvolta da una chiave generata all’interno del Secure Enclave, che non lascia mai il chip. Questo fornisce una protezione legata all’hardware: anche se un attaccante estrae l’output di PBKDF2, non può usarlo senza la chiave del Secure Enclave.

Il Blocco Pattern sulla griglia 5×5 di AppVault viene convertito in una stringa di password. Quella stringa viene inserita in PBKDF2 insieme al salt. La chiave derivata risultante viene utilizzata per crittografare il catalogo del vault e ogni file individualmente utilizzando AES-256-GCM con un nonce unico a 96 bit per file.

L’architettura a conoscenza zero di AppVault significa che la password non lascia mai il dispositivo. La derivazione PBKDF2 avviene interamente sull’iPhone. I server di AppVault (che non esistono) non vedono mai la password o la chiave derivata. Il modello di minaccia presuppone che un attaccante possa ottenere l’accesso fisico al dispositivo, ma senza la password e la chiave del Secure Enclave, il vault rimane sigillato.

Altre app vault in questa categoria adottano approcci diversi alla derivazione delle chiavi. Le differenze architetturali — conteggi di iterazioni, gestione dei salt, custodia delle chiavi legata all’hardware rispetto a quella solo software — sono descritte nelle pagine di confronto dedicate: AppVault vs Vaultaire e AppVault vs Keepsafe. AppVault pubblica il suo stack crittografico completo con citazioni delle fonti primarie, prerequisito per qualsiasi verifica indipendente.

Considerazioni Pratiche per gli Sviluppatori

Se stai implementando PBKDF2, segui queste linee guida:

• Usa HMAC-SHA256 come PRF. SHA1 è accettabile ma richiede più iterazioni.
• Genera un salt casuale di almeno 16 byte per utente o per installazione.
• Imposta il conteggio delle iterazioni alla raccomandazione OWASP corrente (600.000 per SHA-256 a partire dal 2026).
• Memorizza il salt e il conteggio delle iterazioni insieme alla chiave derivata (o ai metadati del vault) in modo che la derivazione possa essere ripetuta.
• Considera il binding hardware (es. Secure Enclave, TPM) per proteggere la chiave derivata anche se il dispositivo è compromesso.
• Non usare PBKDF2 per la memorizzazione delle password in sistemi di autenticazione se Argon2id è disponibile. PBKDF2 è più adatto per la derivazione delle chiavi in scenari di crittografia locale.

Conclusione

PBKDF2 è una funzione di derivazione delle chiavi collaudata che ha protetto password e chiavi di crittografia per oltre due decenni. Non è il KDF più moderno, ma è il più ampiamente supportato e, se configurato correttamente, fornisce una forte protezione contro gli attacchi di forza bruta. La raccomandazione OWASP 2026 di 600.000 iterazioni per SHA-256 garantisce che ogni tentativo di password sia sufficientemente costoso da scoraggiare gli attaccanti.

AppVault utilizza PBKDF2 con 600.000 iterazioni, un salt per installazione e avvolgimento Secure Enclave per proteggere i tuoi file. La combinazione di un alto conteggio di iterazioni e binding hardware rende il vault resistente sia agli attacchi software che fisici. Nessun reset della password, nessuna backdoor, nessun recupero della chiave lato server. La sicurezza dei tuoi dati dipende dalla forza della tua password e dall’integrità della derivazione PBKDF2.

Per un approfondimento su come AppVault implementa la sua crittografia, consulta la panoramica sulla crittografia e il modello di minaccia.