System.Cryptology.RFC2898DeriveBytes () basato su PBKDF2 è "migliore" per l'hashing della password Unicode rispetto ai metodi tradizionali?

Il NIST approva PBKDF2 durante l'hashing e la memorizzazione delle password, tuttavia questo non è il suo scopo originale. In particolare, StackExchange utilizza anche PBKDF2 per lo stesso scopo. Il codice sorgente è disponibile qui.

Vedi questa risposta per un confronto tra BCrypt e PBKDF2. BCrypt è il metodo più convenzionale di memorizzazione delle password.

Sto considerando PBKDF2 poiché è integrato in .NET ed è già conforme a FIPS.

PasswordDeriveBytes implementa la funzione di derivazione chiave PBKDF1. Un KDF è una funzione che trasforma un pezzo di dati segreti (qui, una "password", cioè il tipo di dati che si adatta a un cervello umano e può essere digitato con le dita umane) in una sequenza di bit adeguata per algoritmi che necessitano di un chiave simmetrica (es. crittografia simmetrica). Un KDF non è pensato per nient'altro, in particolare per l'archiviazione di password.

È possibile utilizzare una funzione di hash come KDF, a condizione che la chiave simmetrica necessaria non sia più lunga della dimensione dell'output della funzione hash. Tuttavia, un tale KDF sarebbe molto grezzo. Una caratteristica che il buon KDF dovrebbe fornire è sufficientemente lenta . Questo perché le "password" sono, per loro natura, vulnerabili alla ricerca esaustiva (nota anche come "attacco al dizionario": gli utenti tendono a scegliere come password parole piuttosto semplici o combinazioni che possono essere indovinate con solo pochi milioni o miliardi di tentativi). In un dato sistema, solitamente è possibile tollerare un KDF relativamente lento: un utente che cerca di autenticare non vedrà la differenza tra un ritardo di 1 μs e un ritardo di 1ms per la funzione di derivazione della chiave; ma un rallentamento di 1000x è mortale per l'aggressore: converte uno sforzo di rottura di un giorno in uno sforzo di tre anni anni .

PBKDF1 include un "conteggio di iterazioni" che è un parametro inteso esattamente per questo: per rendere la derivazione della chiave adeguatamente lenta, in un modo configurabile. Una semplice funzione di hash è troppo veloce per quello. L'utilizzo come KDF è esattamente dove preferiresti PBKDF1 su una funzione hash. In realtà, PBKDF1 non è raccomandato; PBKDF2, dallo stesso standard , dovrebbe essere più robusto.

Le funzioni di hash sono oggetti molto più generici di KDF e hanno molti altri usi, che KDF non soddisfa.

Quello che vuoi fare non è chiaro: usi il termine "firma", che normalmente significa "firma digitale asimmetrica" come con RSA o ECDSA; ci sono alcune persone che tendono ad usare il termine "firma" per designare un controllo di integrità simmetrico, come un MAC (chiamata una "firma" è impropria, ma diffusa). Tuttavia, questo comporta un po 'di segreto ad un certo punto, una chiave e una funzione di hash è senza chiave.

A meno che non mi sia sfuggito qualcosa, PasswordDeriveBytes - e altre implementazioni PBKDF - non sono intesi per l'archiviazione di password, né devono essere utilizzati al posto di un hash "tipico".

A cosa serve, è creare una chiave di crittografia, per la crittografia simmetrica, basata su una password fornita dall'utente.

Per chiarire, considera la seguente situazione:
Hai un'applicazione, che richiede la crittografia di un file. Questo viene fatto a discrezione dell'utente e può essere decodificato a sua scelta.
Oh, diciamo che MS Word ha una funzionalità per crittografare i suoi contenuti. O un file ZIP crittografato.
Si vuole dare all'utente il controllo per accedervi, ma non si vuole fare affidamento sull'utente per generare una chiave strong, casuale, esattamente a 256 bit, che renderebbe difficile la memorizzazione, ecc.
Quindi, permetti all'utente di impostare qualsiasi password che desidera - e derivare la chiave di crittografia da quella.

In nessun momento stai memorizzando la password, o usando un semplice hash per memorizzarlo. È destinato esclusivamente alla creazione di materiale chiave.

PBKDF2 è migliore di PBKDF1, che era stato deprecato in RFC 2898 10 anni fa. È implementato per .NET in Classe Rfc2898DeriveBytes (System.Security.Cryptography)

Sono contento di vedere anche che a partire da Java 6 c'è un'implementazione di PBKDF2: PBKDF2WithHmacSHA1 in SunJCE.

Per le versioni precedenti di Java, come discusso in BlackBerry App Security - StackTranslate.it , un'implementazione di PBKDF2 è in Un'implementazione Java gratuita di RFC 2898 / PKCS # 5 PBKDF2

Mi chiedo, tuttavia, se l'uso di SHA-256 sia migliore di SHA-1, che ora è deprecato.

L'utilizzo di RFC2898DeriveBytes con un conteggio di iterazione non banale dovrebbe essere migliore rispetto all'utilizzo di una funzione di hash lineare per scopi di autenticazione.

In primo luogo richiede di mettere un sale, e mentre è ancora possibile per lo sviluppatore fare qualcosa di stupido come il codice duro del sale, è almeno un passo più vicino rispetto a quello in cui gli sviluppatori di solito messup che non è tutto e tutto. Il fatto di avere un po 'di sale rende meno probabile che un tavolo arcobaleno già funzionerà su una password insignificante e se salti casualmente per ogni utente interrompe la perdita di informazioni quando più utenti hanno la stessa password e rende molto difficili quelle password ricevi perché dovresti generare una tabella per ogni sale.

Secondo mentre RFC2898DeriveBytes sfortunatamente non ti permette di scegliere la funzione di hash e usa HMAC-SHA1 e non è un problema in quanto la cosa bella rispetto a PBKDF1 è che la dimensione della tua chiave può essere grande quanto praticamente potresti volere. Ciò aiuta a rendere difficile la memorizzazione e la diffusione delle tabelle arcobaleno rispetto a qualsiasi algoritmo di hash standard.

Infine, i conteggi di iterazione sono fondamentali! Avere un conteggio molto alto rallenta il calcolo dell'hash, gli algoritmi hash standard sono progettati per essere veloci, l'archiviazione dei dati cresce in modo esponenziale e non puoi contare solo sulla dimensione della tua chiave.

La domanda dell'OP e l'obiettivo di tale domanda sono in qualche modo contraddittori. Come tutti sottolineando, PBKDF2 non è utilizzato principalmente per l'enc / storage della password, ma per la generazione delle chiavi. Più comunemente, viene utilizzato in WPA2 PMK e in altri schemi di generazione di chiavi WPA, utilizzando tali componenti di esempio come password + un salt del nome SSID e della lunghezza del nome SSID, che viene quindi eseguito attraverso un hashing SHA1 di iterazione 4096.

Quando la crittografia passa, le cose più importanti da richiedere per sicurezza sono la lunghezza e un sale che è dinamico e non trasparente per l'utente (es .: lo sfruttatore non può determinare cosa sia il sale). Se si utilizza un archivio crittografato AES con una password di almeno 20 caratteri, un salt random e iterazioni 4K + di SHA-256 (PBKDF2 raccomanda almeno 1K iterazioni di SHA1 per i suoi scopi), un hacker avrà un periodo molto difficile quella password (vedi: ordine di grandezza in anni o decenni se non di più).

Anche la crittografia delle password dipende molto dall'uso finale (velocità, necessità di livello di sicurezza, ecc.), quindi senza sapere quale sia il potenziale utilizzo finale è più difficile raccomandare una soluzione ideale.