Sto crittografando i dati (settore sanitario) utilizzando le classi di crittografia aes nel framework .net. Quali sono alcune delle posizioni consigliate per la memorizzazione sicura della chiave? Ce l'ho nel web.config per lo sviluppo, ma non ritengo la produzione meritevole, per non dire altro.Dove memorizzare la chiave di crittografia
Se l'applicazione richiede l'autenticazione utilizzando le chiavi, l'approccio normale
nelle macchine unix è quello di memorizzare le password in formato hash.
È possibile utilizzare sha-512 + salt.
Quindi è possibile calcolare l'hash quando l'utente immette la password e verificare con il proprio.
La password/chiave stessa può essere memorizzata ovunque se la sua hash. Se non lo memorizza nella directory utente tecnica dove nessuno ha accesso.
EDIT per quelli che non vogliono mettere troppa fatica nella comprensione dei casi d'uso che ho presentato
Johny ha alcuni dati crittografati AES.
Conserva la sua chiave in testa.
Vuole memorizzare questo hey da qualche parte sul suo PC per automatizzare l'accesso.
Può memorizzarlo come ASCII in web.config.
Ma lui può fare in modo che hash non sia più ASCII ma hash.
Durante l'applicazione di autenticazione calcola i controlli di hash è la chiave corretta, quindi utilizza questo tasto ....
Basso probabilmente di collisione con l'algoritmo corretto.
ps. semplicemente postando il mio punto di vista sull'argomento.
Perché sei così sensibile alla parola "hash" ???
EDIT 2
So che cosa è hash,
so cosa si chiama così la crittografia a 2 vie ....
È possibile crittografare i valori web.config utilizzando built nei metodi della quadro:
http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
Questo è probabilmente un posto ragionevole per conservare la chiave - se qualcuno è riuscito ad accedere al server per recuperare questi dettagli, allora probabilmente avete bi gger si preoccupa
Vero. Ma DPAPI è più "sicuro"? – Saraz
@Saraz - Mi spiace, non so la risposta ... – Paddy
@Saraz: più sicuro di cosa? È più sicuro, nel senso che "non è possibile ripristinare senza l'accesso a livello di amministratore * su quella macchina specifica *" (poiché l'algoritmo di crittografia dipende da dati unici per la macchina). In altre parole, se qualcuno è riuscito a ottenere il tuo web.config, non è ancora possibile decodificare su un altro computer. – Piskvor
Quello che devi fare è nascondere questa chiave da qualche parte, e una posizione sicura sarebbe all'interno di un database. Preferibilmente un database diverso da quello che contiene i tuoi dati. Poiché i dati richiedono combinazioni nome utente/password per aprirli, basta aggiungere un secondo livello di sicurezza alla propria applicazione. La tua app dovrebbe accedere al database delle chiavi, recuperare la chiave X per l'applicazione Y e quindi utilizzarla. Dovresti comunque memorizzare la stringa di connessione per questo database da qualche parte.
Anche se si memorizzasse solo una singola chiave in un database di chiavi, varrebbe la pena. Costringe un hacker a fare un po 'più di fatica ad aprire questo database per trovare la chiave prima di poter accedere ai dati. Dal momento che non c'è una sicurezza perfetta, le tue opzioni sono solo limitate a ritardare il tempo necessario a un hacker per ottenere l'accesso.
La crittografia del file web.config o dei dati al suo interno aiuterà anche a ritardare l'hacker ma se la chiave si trova nel file di configurazione, tutto ciò che deve fare è decrittografarlo di nuovo.
Questo non è affatto diverso da memorizzare una chiave nel file di configurazione - è necessario memorizzare la stringa di connessione nel database delle chiavi da qualche parte, e se il tuo hacker ha accesso sufficiente per arrivare al tuo file di configurazione, probabilmente sarà in grado di ottenere questo ... – Paddy
Vero. Ma aggiunge un secondo livello. È necessario accedere al database per ottenere la chiave e, in generale, i database sono archiviati su un sistema diverso. Se il server database è impostato per accettare solo le chiamate dalla posizione del server Web, è più difficile per un hacker remoto ottenere l'accesso alla chiave. E se il database ha memorizzato alcune centinaia di chiavi (fittizie!), L'hacker non sa ancora quale usare. –
Un approccio che fornirà una buona sicurezza se le uniche persone che avranno bisogno di utilizzare la chiave per qualsiasi scopo può essere assolutamente affidabile con esso è quello di memorizzare la chiave crittografata con un'altra chiave, una copia di cui è memorizzata per ogni utente , crittografato con un hash della password dell'utente (salted in modo diverso da quello memorizzato per la convalida della password!). Anche una persona malvagia con accesso a ogni bit di dati, in qualsiasi parte dell'universo, associata a quella chiave del database, non sarebbe in grado di accedere al database senza eseguire il reverse engineering di almeno una delle password.
Si noti che se le password per tutti gli account validi sono stati persi o dimenticati, i dati sarebbero irrecuperabili. Questo fa parte della natura della sicurezza reale. Se si vuole evitare la possibilità di perdere dati, è necessario assicurarsi che le copie di backup delle chiavi e/o password necessarie siano archiviate in modo sicuro.
È possibile utilizzare invece la crittografia basata su certificato. Vedi http://en.wikipedia.org/wiki/Certificate-based_encryption e http://msdn.microsoft.com/en-us/library/ms867080.aspx e http://msdn.microsoft.com/en-us /library/ms229744.aspx –