Rfc2898DeriveBytes strumenti l'algoritmo standard noto come PBKDF2 e definito in RFC 2898 (da cui il nome). Tale algoritmo utilizza una funzione pseudocasuale sottostante configurabile, che di solito è HMAC , e HMAC si basa su una funzione di hash sottostante configurabile , di solito SHA-1. Benché tutto ciò sia configurabile, una determinata implementazione potrebbe non essere flessibile e, infatti, Rfc2898DeriveBytes sempre utilizza HMAC e sempre usa SHA-1 come funzione sottostante per SHA-1.
Al giorno d'oggi, le persone conosciute collettivamente come "auditor" tendono a piangere, lamentarsi, urlare, deridere e correre in cerchio quando vedono qualcosa che coinvolge SHA-1 . Questo è scientificamente ingiustificato. In questo momento , tra tutte le Science pubblicate, non c'è la minima indicazione che SHA-1 quando usato in HMAC sarebbe debole. I punti deboli noti di SHA-1 riguardano le collisioni che non hanno impatto sull'HMAC (e sono comunque teoriche). Se un ragazzo con un CISSP insiste sul fatto che SHA-1 rende effettivamente PBKDF2 più vulnerabile alla forza bruta, allora quel ragazzo dovrebbe andare a imparare di nuovo le sue lezioni.
Ciononostante, cambiare SHA-256 non è una cattiva idea, quindi se shA-1 è quello che serve per sbarazzarsi degli auditor, così sia.
Tuttavia, si deve ancora dire quanto segue:
-
Disassemblare e modificare è un metodo piuttosto grezzo e tende a portare a codice non gestibile. Potresti semplicemente iniziare dal codice sorgente attuale (ad esempio da qui ) o, ancora più semplicemente (e con uno stato giuridico più pulito), reimplementarlo da zero. .NET fornisce un'implementazione HMAC / SHA-256 ; utilizzarlo per fare un codice PBKDF2 non è difficile.
-
In alternativa, puoi provare a riutilizzare altre implementazioni esistenti, come questo .
-
Si usa PBKDF2 quando si desidera "hash una password" e non tutte le funzioni sono uguali a tale riguardo. Una funzione di hashing è valida solo nella misura in cui è costoso da calcolare per gli attaccanti. A tale riguardo, PBKDF2 con SHA-1 o SHA-256 non è la scelta migliore; discutibilmente, PBKDF2 con SHA-512 è un affare migliore (perché la GPU esistente ha un tempo di ottimizzazione più difficile di SHA-512 rispetto a SHA-256), ma altre soluzioni potrebbero essere preferibili, in particolare bcrypt . Per ulteriori informazioni su questo argomento, leggi questo e più in generale questo .
Questo significa che mentre i "punti deboli" di SHA-1 non rendono più debole PBKDF2, è comunque una funzione che può essere ottimizzata molto bene su GPU, che è, in quel caso, un problema - ma, e questo è l'importante punta qui, SHA-256 non è migliore.
-
In ogni caso, utilizzando un'implementazione C # pura, si accetta che questo specifico per la CPU funzioni con il rallentamento intrinseco di tale tecnologia, che può essere stimato in un fattore da 2 a 3 se confrontato con l'ottimizzazione Codice C (o assemblaggio). In altre parole, dai un vantaggio di 2x o 3x agli attaccanti. Pertanto, potresti voler utilizzare un codice nativo qui, non puro C #.