Qual è il modo migliore per archiviare la stringa di connessione nelle DLL .NET?

Question

L'applicazione che il mio team sta attualmente sviluppando ha una DLL che viene utilizzata per eseguire tutti gli accessi al database.L'applicazione non può utilizzare una connessione attendibile perché il database è protetto da un firewall e il server di dominio no.Quindi sembra che la stringa di connessione debba avere un nome utente e una password DB.La DLL attualmente ha la stringa di connessione al database codificata in modo rigido, ma non voglio farlo all'avvio poiché l'assembly può essere disassemblato e il nome utente e la password sarebbero proprio lì allo scoperto.

Uno dei requisiti è che la password debba essere cambiata una volta ogni pochi mesi, quindi dovremmo distribuirla alla nostra base di utenti interni.

Esiste un modo per archiviare la password crittografata in modo tale da poterla distribuire facilmente all'intera base utenti senza memorizzarla nell'assembly?

AGGIORNAMENTO:Grazie a tutti coloro che hanno risposto.Proverò a rispondere ad alcune domande che mi sono state poste...La DLL dei dati viene utilizzata sia da ASP.NET WebForms che da VB.NET WinForms.Capisco che le applicazioni possono avere i propri file di configurazione, ma non ho visto nulla sui file di configurazione per le DLL.Sfortunatamente, non posso raggiungere la postazione di Jon Galloway al lavoro, quindi non posso giudicare se funzionerà.Dal punto di vista dello sviluppo, non vogliamo utilizzare i servizi web internamente, ma potremmo fornirli a terzi nel prossimo anno.Non penso che la rappresentazione funzionerà perché non possiamo autenticare l'utente attraverso il firewall.Poiché un utente (o ex utente) può essere un utente malintenzionato, lo teniamo nascosto a tutti!

Answer 1

Non ne sono sicuro, ma credo che tu possa inserirlo in un file di configurazione e crittografare il file di configurazione.

Aggiornamento:Vedi il post di Jon Galloway Qui.

Answer 2

Presumi semplicemente che i cattivi otterranno le credenziali dal tuo file di configurazione.Ciò significa che saranno in grado di accedere al tuo database e fare tutto ciò di cui quell'utente è capace.Quindi assicurati solo che l'utente non possa fare nulla di male come accedere direttamente alle tabelle.Rendi l'utente in grado di eseguire solo determinate procedure memorizzate e sarai più in forma.Questo è un posto in cui gli sproc brillano.

Answer 3

Odio dirlo, ma non appena metti qualcosa su un computer client, la sicurezza di quei dati va fuori dalla finestra.

Se il tuo programma decifra quella stringa, devi presumere che un utente malintenzionato possa fare lo stesso.Collegare un debugger al tuo programma sarebbe un modo.

Memorizzare la stringa di connessione su un server e ottenerla tramite una connessione web sembra una buona idea, finché non ti rendi conto che hai bisogno di sicurezza anche su quella connessione web, altrimenti un utente malintenzionato potrebbe benissimo impersonare il tuo programma e parlare con la connessione web.

Vorrei fare una domanda.A chi nascondi la stringa di connessione?L'utente o un utente malintenzionato?E se l'utente, perché?

Answer 4

Ci sono anche altre idee.Puoi sempre usare la rappresentazione.Inoltre, è possibile utilizzare la Libreria aziendale (Libreria comune).

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
  <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    filePath="Config\Exception.config" />
</sources>

Answer 5

.NET supporta la crittografia su valori di configurazione come questo.Potresti lasciarlo in un file di configurazione, ma crittografato.

Answer 6

Vuoi essere in grado di distribuire la DLL con tutte le informazioni di configurazione in una posizione configurabile, ma il fatto è che non puoi avere uno dei pratici file di configurazione .NET per una DLL a meno che non fai qualcosa di personalizzato.

Forse devi riconsiderare quale responsabilità dovrebbe avere la tua DLL.Sarebbe possibile o avrebbe senso richiedere che la stringa di connessione venga passata dall'utente della tua libreria?Ha davvero senso che la tua DLL legga un file di configurazione?

Answer 7

Se l'app è un'app ASP.NET, crittografa semplicemente la sezione delle stringhe di connessione del tuo file web.config.

Se l'app è un'applicazione client in esecuzione su più computer, invece di archiviare la stringa di connessione localmente, valuta la possibilità di utilizzare un servizio Web o qualche altro tipo di meccanismo sicuro per archiviarla a livello centrale.Ciò faciliterebbe aggiornamenti più semplici in futuro e non stai memorizzando la stringa di connessione localmente.

Solo alcuni pensieri.

Aggiornato: @lassevk

"Memorizzare la stringa di connessione su un server e ottenerla tramite una connessione web sembra una buona cosa, finché non ti rendi conto che hai bisogno di sicurezza anche su quella connessione web, altrimenti un utente malintenzionato potrebbe benissimo impersonare il tuo programma e parlare con la connessione web. "

La sicurezza sul servizio web era implicita.A seconda del tipo di distribuzione sono disponibili numerose opzioni... ad esempio i certificati lato client.

Answer 8

Diverse opzioni:

1. Archiviare in web.config e crittografare
2. Archiviare in dll e offuscare (dotfuscator)
3. Memorizzane uno in web.config (crittografato ovviamente) e resta nel database (se devi usarne più di uno e la crittografia/decrittografia diventa una seccatura)