Dove memorizzare le password db quando si usano le applicazioni Windows .NET o ASP.NET

Question

Ho uno scenario che mi ha turbato per anni. Se è necessario connettersi a un database o un altro servizio (come un servizio Web) utilizzando un nome utente e una password, dove sarebbe il posto più sicuro in cui archiviare queste informazioni se ci si connette tramite un assembly .NET? Capisco che dovresti cifrare la password, ma poi ti imbatti in una specie di problema uovo di gallina - bene - puoi cifrarlo, ma poi dove metti la chiave?

In .NET, non è possibile codificare la password poiché è possibile decompilare il codice .NET.

Ho esaminato i diritti basati sugli assembly con Isolamento isolato, ma MS consiglia di archiviare gli elementi segreti non crittografati lì perché gli utenti privilegiati possono ottenere l'accesso, quindi, di nuovo, stiamo spostando il problema dal punto A al punto B. Quindi per esempio, un amministratore di dominio senza necessità di conoscere le informazioni in un database sarebbe in grado di ottenere l'accesso a causa della possibilità di essere un amministratore su qualsiasi workstation sul dominio.

È possibile crittografare App.Config e Web.Config, ma credo che gli utenti privilegiati possano accedere alle chiavi.

Penso che tu abbia lo stesso problema con DPAPI.

Avevo pensato di archiviare le password, crittografato in un database remoto e ottenerle tramite l'autenticazione del sistema operativo, ma il nostro reparto vieta l'archiviazione delle password sui server di database. Sono abbastanza sicuro di essere bloccato e volevo una conferma.

Answer 1

Non si desidera memorizzare la password nell'assieme e reinventare la rotellina crea solo più problemi (e introduce più vulnerabilità) di quanto valga. Se si utilizza la piattaforma MS sia sul database che sul server Web, il modo più semplice per gestirlo è use a trusted connection e concedere i diritti sul server SQL all'identità utilizzata dall'applicazione.

In secondo luogo, vorrei solo let DPAPI do its job to encrypt your connection settings.

Answer 2

Ci sono un paio di opzioni qui.

1. memorizzarli nel file di configurazione criptato
2. memorizzarli in un file esterno che è criptato con un seme generato. Obfuscate il codice che memorizza questo seme di base o lo memorizza in una DLL C++ (difficile da decompilare).

Answer 3

Questa è una buona domanda e ho cercato una risposta da solo. Il problema che ho avuto è stato quello di mantenere sicure le password db nel caso in cui il server fosse stato violato e si potessero recuperare i singoli file. Un'opzione molto interessante che ho trovato è che le sezioni di web.config possono essere crittografate e decrittografate automaticamente al volo da .NET framework che usa l'archivio sicuro di Windows per conservare e recuperare la chiave di crittografia. Nella mia situazione non era disponibile perché il mio provider di hosting non lo supportava, ma potresti dare un'occhiata a questa opzione. Perché penso che possa funzionare è che puoi gestire in modo indipendente la sicurezza di ciò che gli utenti possono accedere all'archivio protetto di Windows e limitare significativamente qualsiasi potenziale violazione. Un hacker che si intromette nel server potrebbe ottenere una copia dei tuoi file di configurazione e di tutti i tuoi assembly, ma l'accesso alla chiave di decifrazione sarebbe un altro ostacolo per lui.

Answer 4

È possibile utilizzare i seguenti metodi della .NET Framework per proteggere i dati, usano il DPAPI internamente per proteggere i dati, ed è possibile utilizzare direttamente in C# o VB.NET senza dover smanettare con le chiamate DLL di sistema:

namespace System.Security.Cryptography 
{ 
    // Summary: 
    //  Provides methods for protecting and unprotecting data. This class cannot 
    //  be inherited. 
    public sealed class ProtectedData 
    { 
     public static byte[] Protect(byte[] userData, 
      byte[] optionalEntropy, DataProtectionScope scope); 
     public static byte[] Unprotect(byte[] encryptedData, 
      byte[] optionalEntropy, DataProtectionScope scope); 
    } 
} 

Per usarlo, aggiungere il riferimento System.Security al progetto. Consiglio vivamente di utilizzare l'array di byte optionalEntropy per aggiungere un SALT ai dati protetti (aggiungere alcuni valori casuali all'array di byte che sono univoci per i dati che si intende proteggere).

Per scope è possibile utilizzare DataProtectionScope.CurrentUser, che crittograferà i dati per proteggere con le credenziali dell'utente corrente.

In alcuni scenari, anche DataProtectionScope.LocalMachine è utile. In questo caso, i dati protetti sono associati al contesto della macchina. Con questa impostazione qualsiasi processo in esecuzione sul computer può rimuovere la protezione dei dati. Viene solitamente utilizzato in applicazioni specifiche del server che vengono eseguite su un server a cui gli utenti non autorizzati non possono accedere.

Utilizzare il metodo Protect per crittografare i dati, decrittografarlo con Unprotect. È possibile memorizzare l'array di byte restituito in base ai requisiti dell'applicazione (file, database, registro, ecc.).

più su questi metodi possono essere trovati qui a MSDN:

• Windows data protection - informazioni generali sulla funzionalità DPAPI,
• Protected data class - specifica della classe ProtectedData,
• Protect method - descrizione circa l'uso di il metodo Protect

Per i campioni di codice e nel caso siete interessati a criptare parti delle applicazioni di file .config, check this out:

• Encrypt passwords in config - articolo che spiega come crittografare parti del web/app.config

vi consiglio di usare un SALE (es usando il parametro optionalEntropy) - protegge contro gli attacchi della tabella arcobaleno.

---

C'è uno svantaggio della soluzione DPAPI vorrei citare: La chiave è generato in base alle tue credenziali di Windows, il che significa chi ha accesso alle proprie credenziali Windows ha probabilmente l'accesso ai dati protetti. Un programma in esecuzione con il tuo account può accedere anche ai dati protetti.