C'è qualche ragione per usare AesManaged su DPAPI in questo scenario?

Question

C'è qualche ragione per usare AesManaged su DPAPI in questo scenario?

#1 da (2 voti)
#2 da (0 voti)

7

Ho una situazione in cui la mia applicazione web verrà distribuita su più server Web e vorrò memorizzare alcuni dati crittografati in modo sicuro sui server DB (ogni server Web ha un server DB associato).

Ora, quello che stavo pensando di fare era implementare le funzioni di libreria Encrypt e Decrypt che utilizzano la classe AesManaged . Questi userebbero un tasto AES che sarebbe diverso per ogni server (ne genereremmo uno nuovo per ogni server sulla distribuzione) - in questo modo, ogni server userebbe una chiave diversa. Dovremmo quindi utilizzare SectionInformation.ProtectSection() per crittografarli in Web.config , quindi erano sicuri.

Tuttavia, mi sono imbattuto in ProtectedData classe. Questo si aggancia alla funzionalità DPAPI di Windows e consente la crittografia e la decrittografia simmetriche. Ora mi chiedo, c'è qualche punto nel mio usando AesManaged con le mie chiavi generate a tutti, o dovrei semplicemente criptare e decrittografare i dati usando ProtectedData ? Quali sono i pro e i contro di ciascuno?

.net encryption aes windows-dpapi

posta Jez 25.03.2015 - 01:41

fonte

2 risposte

Leggi altre domande sui tag .net encryption aes windows-dpapi

Programmazione orientata al ritorno senza int 0x80 Verifica dei file firmati crittograficamente quando la chiave è stata revocata

score 2 · Answer 1

Probabilmente è un po 'tardi, ma solo come una raccomandazione per altre persone che si imbattono in questo. Per questo tipo di problema, utilizzerei sempre ProtectedData per implementare la propria implementazione con AesManaged per due motivi. Innanzitutto, non è necessario gestire le chiavi di crittografia con ProtectedData, il che è una seccatura da fare correttamente. In secondo luogo, c'è una serie di considerazioni sulla sicurezza che uno sviluppatore deve capire prima di lanciare a mano la propria crittografia e anche allora c'è una possibilità che lo sviluppatore possa commettere un errore e rendere la crittografia inutile. Perché cogliere l'occasione e rischiare un mal di testa quando una soluzione perfettamente accettabile, già controllata, è già disponibile?

score 0 · Answer 2

Come riferito da Justin, usare le tue chiavi e poi gestirle è un no. Questo è il motivo per cui hai OS o meccanismi linguistici per fare questo per te. In Java avete le keystore locali protette da password. Il vantaggio di affidarsi al sistema operativo per proteggere le tue chiavi è che nel caso in cui il sistema operativo sottostante sia corrotto in qualche modo, probabilmente perderai quelle chiavi per sempre. Perché non usi RSACryptoServiceProvider con CspParameters per creare un negozio con le tue chiavi?

Leggi: link

link

Penso che questo potrebbe aiutarti. In questo modo non sei limitato alle scelte chiave del sistema operativo e puoi tenere le tue chiavi al sicuro mentre le proteggi localmente nei negozi.

Stai al sicuro;)