È buona norma impostare stringhe di connessione in una configurazione Web?

Recentemente ho discusso con alcuni dei miei colleghi di lavoro perché mi hanno detto che è meglio avere in una .DLL una connessione a stringa crittografata. E ho detto perché semplicemente non usare la connessione stringa definita in web.config crittografata? è lo stesso ed è migliore perché l'entità framework, ad esempio, cerca il nome della connessione nella configurazione web dell'applicazione, ora voglio sapere da un punto di sicurezza cosa è meglio o qual è la migliore pratica ??

Non c'è alcuna differenza sostanziale, tranne per il fatto che dovrai effettivamente creare un binario se desideri apportare una modifica alla configurazione se lo metti in una DLL, mentre un amministratore potrebbe semplicemente modificare la configurazione con strumenti ben comprensibili se è nella configurazione. Esiste già un meccanismo per crittografare le stringhe di configurazione e ulteriori indicazioni su MSDN . Le versioni attuali di Asp.Net possono avere meccanismi alternativi, quindi fai qualche ricerca aggiuntiva prima di impegnarti in un approccio.

Solo perché qualcosa si trova in una DLL, non lo rende più sicuro. Un editor di testo può anche aprire file binari, strumenti come Reflector possono fornire un'interfaccia migliore per navigare in una DLL .Net; una DLL non fornirà alcuna crittografia "extra".

Non importa dove sono archiviati i dati crittografati, importa come sono crittografati.

Le sezioni crittografate in un web.config sono normalmente crittografate con l' API Data Protection , che è estremamente difficile da decifrare senza compromettere l'intero computer. È inoltre possibile utilizzare un contenitore di chiavi RSA, che è simile (difficile da rimuovere dalla macchina).

Se vuoi archiviare la stringa crittografata nella DLL, va bene, immagino, anche se non è intrinsecamente più sicuro di un web.config crittografato (chiunque può sbirciare in quella DLL con Reflector ), ed è ovviamente più difficile cambiare (tu dovrei ricompilare). Ma ancora una volta, ciò che è molto più importante è come è stata generata quella stringa crittografata; presumibilmente non stai usando gli stessi provider che faresti per un web.config crittografato, quindi cosa stai usando?

Uno schema di crittografia è efficace solo come la chiave privata o il segreto condiviso. Se tale chiave viene anche memorizzato nella vostra assemblea, allora si potrebbe anche non avere la crittografia a tutti. Se è archiviato in un database esterno, solleva la questione di come è protetta la stringa di connessione di quel database. Questo può davvero solo portare a una sicurezza più debole nel complesso.

D'altra parte, se tu fossi un fornitore di servizi e la stringa di connessione fosse crittografata con a password utente , sarebbe più sicuro rispetto all'utilizzo di una chiave di macchina statica. Inoltre, se stai usando le password degli utenti per crittografare, è abbastanza improbabile che tu stia codificando i dati crittografati nel tuo assembly, poiché devono essere generati e archiviati in risposta all'azione dell'utente (non dello sviluppatore).

Davvero non riesco a pensare a troppe situazioni in cui la codifica hardware di una stringa di connessione (crittografata) nella DLL è più sicura della crittografia della sezione web.config pertinente. Nella migliore delle ipotesi si tratta solo di aggiungere inconvenienti, nella peggiore dei casi si basa su una sicurezza personalizzata scritta goffamente, piena di buchi. Fatti un favore e fai ciò che Microsoft consiglia: crittografa il tuo web.config se ci sono dati sensibili lì dentro.

La procedura consigliata per ASP.NET è inserire tutte le configurazioni / impostazioni nel file web.config o nel file app.config (per altri tipi di progetto).

La crittografia e il motivo per usarla nelle stringhe di connessione devono essere un caso molto speciale. Poiché la maggior parte dei casi fino al 99% non è necessario crittografare le stringhe di connessione. Le applicazioni aziendali di Microsoft hanno la stringa di connessione esposta nel file web.config / app.config. Penso che tu abbia complicato la sicurezza.

Un'altra cosa, codificare a fondo le stringhe di connessione è una cattiva pratica. Ad esempio, non inserire alcuna stringa di connessione (aka connectionstring) in una DLL o .aspx / .ascx / .cshtml o code-behind.