AES è una buona scelta per proteggere una chiave memorizzata sul computer di un utente della mia applicazione? Ho visto thread sulle password di hashing che suggeriscono l'uso di algoritmi lenti per difendersi da brute attacchi di forza.
Inoltre, eventuali consigli su quali parametri dovrei usare per RijnadealManaged , come ad esempio algoritmo di riempimento, cifra cifrata o dimensione della chiave?
Stai meglio usando DPAPI .
Mentre AES-256 / CBC / PKCS7 / etc è una buona scelta di parametri cipher +, che comunque non risolverà il tuo problema: dopo aver crittografato la chiave di crittografia, cosa fai con Key Encrypting Key (KEK) ? Sarai comunque bloccato a crittografare la chiave di crittografia ...
DPAPI fornisce una soluzione eccellente, che consente di rinviare la responsabilità della gestione delle chiavi sul sistema operativo. (Ordina per.)
È possibile utilizzare la classe ProtectedData dal Sistema. Security.Cryptography namespace, è molto semplice e diretto - assicurati di aver impostato USER_MODE per assicurarti che solo quell'utente abbia accesso per decrittografare la chiave.
Tornando indietro per un momento, a seconda dell'applicazione, potrebbe essere meglio utilizzare DPAPI per proteggere KEK (chiave di crittografia chiave) e non la chiave di crittografia stessa - la condivisione e la distribuzione delle chiavi diventa più facile, così come la rekeying (se necessario).
Sono nuovo anche in crypto, quindi prendi questo con un pizzico di sale, ma usando AES in CBC è probabilmente una buona scelta, anche se dipende in realtà da cosa / come si sta crittografando). AES con chiavi a 128 bit è sufficiente per i documenti di livello SECRET; Per i documenti TOP SECRET sono necessari i tasti 192 o 256 bit in base alla NSA . Per quanto riguarda il padding, credo che lo standard sia Padding PKCS7 , quindi probabilmente dovresti limitarti a questo. Se decidi di utilizzare CBC, assicurati di generare un IV casuale (stessa lunghezza della tua chiave) ogni volta che crittografa i dati con quella chiave. È necessario assicurarsi che finché si utilizza la stessa chiave che non si utilizza mai la stessa IV per crittografare un altro messaggio. L'IV è considerato pubblico, quindi puoi semplicemente memorizzarlo insieme ai tuoi dati crittografati in modo che possa essere utilizzato per inizializzare il codice durante la decrittazione.
Detto questo, probabilmente la cosa più sicura da fare è vedere se .NET ha una libreria simile a Jasypt o KeyCzar . Queste librerie si prenderanno cura di tutti i piccoli dettagli pericolosi per te, così non finirai per creare buchi di sicurezza che nemmeno sapevi fossero possibili.
Spero che punti almeno nella giusta direzione!
In generale, non dovresti farlo da solo, ma seguendo le linee guida per il sistema che stai utilizzando.
Il modo "corretto" di memorizzare le password è con un hash "unidirezionale", con "sale" e "rafforzamento delle chiavi".
Il termine "a senso unico" significa solo questo. Una volta che lo hai cancellato, non puoi mai recuperare la password da solo. Non c'è modo di recuperare la password. Tuttavia, è ancora possibile controllare se l'utente ha inserito la password corretta ripetendo l'hash su ciò che ha digitato e vedere se corrisponde a quella memorizzata nel database.
Se gli hacker rubano gli hash delle password, possono eliminarli offline.
Il crack più comune è precalcolare gli hash di una password di zillion. Quando rubano gli hash dal tuo sito, li cercano in una tabella e trovano immediatamente la password originale.
Per sconfiggerlo, "salvi" la password. Genera un testo casuale e cancella quel testo con la password. Quindi memorizzi quel sale + hash nel tuo database.
Questo costringe gli hacker a "forzare la tua password" invece di usare una "ricerca tabella". I desktop degli hacker possono calcolare 1 miliardo di hash al secondo, quindi scopriranno rapidamente le password di piccole dimensioni.
Per sconfiggerlo, hai semplicemente ripetutamente cancellato il valore. Se ripeti l'hash un migliaio di volte, l'hacker ora può testare solo un milione al secondo.
Sfortunatamente, più costoso lo fai per l'hacker, più costoso ti metti a testare le tue password. Ripetere l'hash 1000 volte è un buon compromesso tra il rallentamento dell'hacker e l'impatto sulle prestazioni del tuo server.
Un altro modo per rallentare l'hacker consiste nell'applicare regole alle password, come richiedere di avere almeno 8 caratteri e contenere numeri e simboli. La maggior parte delle password sono parole, in tutte le lettere minuscole. Ciò significa che l'hacker ha bisogno solo di testare 26 combinazioni per lettera. Se le password sono composte da lettere maiuscole e minuscole, numeri e simboli, diventano circa 100 combinazioni per lettera.
Il punto di cui sopra è quello di insegnarti tutte le complicazioni su come gli hacker attaccano le password e le cose che gli amministratori devono affrontare per difendere quelle password. Di solito, non devi preoccuparti di questo: scegli la soluzione che il sistema sottostante che stai utilizzando ha scelto per te.
Leggi altre domande sui tag .net cryptography encryption appsec