2009-12-17 11 views
5

Desidero utilizzare un SecureString per contenere una stringa di connessione per un database. Ma non appena ho impostato la proprietà ConnectionString dell'oggetto SqlConnection sul valore di securestring, sicuramente diventerà visibile a qualsiasi altra applicazione in grado di leggere la memoria dell'applicazione?utilizzando securestring per una connessione sql

ho fatte le seguenti ipotesi:
a) non sono in grado di un'istanza di un oggetto SqlConnection fuori di memoria gestita
b) qualsiasi stringa all'interno memoria gestita possono essere letti da un'applicazione come Hawkeye

+2

Apparentemente Hawkeye 1.2.0 può mostrare SecureStrings ... Quindi, qual è la tua domanda? –

+1

Oh - quindi qual è il punto in securestrings allora? – Richard

risposta

3

Hai assolutamente ragione il SecureString non ti offre alcun vantaggio quando devi passare la stringa a un'API gestita, come ad esempio l'impostazione di ConnectionString.

È davvero progettato per comunicazioni sicure con API sicure non gestite.

Microsoft potrebbe teoricamente in considerazione un miglioramento oggetto SqlConnection per sostenere una ConnectionString sicuro, ma penso che è improbabile che farlo perché:

  • SecureString è veramente utile solo in un'applicazione client, in cui per esempio una password viene costruita carattere per carattere dall'input dell'utente, senza mai avere l'intera password in una stringa gestita.

  • In tale ambiente, è più comune utilizzare l'autenticazione di Windows per le connessioni a SQL Server.

  • Su un server esistono altri modi per proteggere le credenziali di SQL Server, iniziando limitando l'accesso al server agli amministratori autorizzati.

+3

.NET 4.5 consente di passare una password come SecureString quando si utilizza l'autenticazione di SQL Server: [Novità di ADO.NET 4.5] (http://msdn.microsoft.com/en-us/library/ex6y04yf (v = vs.110) .aspx) –

+0

È mia opinione che SecureString è pensato per tutti i tipi di comunicazione di segreti in modo sicuro e non limitato alle API non gestite. Per Lee SecureString sono supportati con .NET 4.5. Lavoro personalmente in ambienti di ingegneria del supporto aziendale in cui il supporto di livello più basso può avere accesso ad alcuni dati in SQL, ma non viene garantita la conoscenza di quale sia la password dell'utente SQL. Invece questo segreto è crittografato in anticipo con un certificato e al programma è concesso l'uso del certificato ma non l'utente. –

+0

@DavidBurg - Non capisco il tuo punto. SqlConnection.ConnectionString continua a non utilizzare SecureString in .NET 4.5. Se è possibile evitare la necessità di una password, è chiaro che questa è una soluzione migliore, ma non è sempre così. E un programma che utilizza un certificato per l'autenticazione non ha bisogno di SecureString. – Joe

0

Se sei preoccupato per la sicurezza, ti suggerisco di abilitare SSL nel server SQL e comunicare con esso utilizzando SSL.

+2

La password di connessione non dovrebbe ancora essere in memoria ad un certo punto? –

+0

@JonB @Shamika si, penso che sarebbe troppo – Richard

+0

Non vedo cosa abbia a che fare SSL con la domanda. – Joe

0

Perché la stringa di connessione è un problema? La password non dovrebbe essere ciò che si desidera proteggere (a meno che non si inserisca la password nella stringa di connessione che è facoltativa per tutti i driver che ho visto). Detto questo, la password di solito deve essere "in chiaro" in memoria ad un certo punto (a meno che il driver abbia qualche API che consente password crittografate o qualcosa del genere, ma che probabilmente non sarebbe di grande aiuto in ogni caso).

In genere questo non è un problema perché il processo si trova in un ambiente sicuro, come su un server Web, o in esecuzione come account di amministratore di sistema (quindi gli utenti normali non possono accedere alla memoria del processo) o di solito entrambi. Se questo è sul computer di un cliente in esecuzione in userland, è necessario presumere che il processo sia comunque compromesso e questo non sarebbe di aiuto. Una volta sicuro il processo, non devi preoccuparti di cose come questa.

0

Assegnare un valore SecureString per SqlConnection.ConnectionString consentirà di bypassare la sicurezza, il che rende inutile.

Un SecureString è destinato a risolvere questi normali problemi di stringa, ref:

  • non appuntato, garbage collector può muoversi in giro, lasciando le copie in memoria
  • non crittografato
  • Se il processo viene scambiato su disco, la stringa sarà nel file di scambio
  • non modificabile, la modifica manterrà la versione precedente e la nuova versione entrambe in memoria
  • n o modo per cancellare fuori quando hai finito di usarlo

IMHO il tipo SecureString è una patch per un'implementazione di sicurezza scadente, e attualmente SecureString non è stata attuata in tutto il quadro, quindi è benefici puo' essere usato completamente

Ho lo stesso problema, sto optando per la crittografia RSA che memorizza informazioni sensibili in memoria.

Un'altra soluzione ospita il livello di accesso ai dati tramite un servizio sul server database e il servizio viene eseguito con l'account di sistema locale, che si collega al database e serve i dati, mentre l'utente locale non ha accesso al servizio config.

+0

Con la nuova versione di.NET, l'implementazione di SecureString è più olistica, rendendo la risposta originale un po 'obsoleta. –

4

Sì, è possibile e si, si dovrebbe usare SecureString per evitare che la password rimanga nella memoria libera e aperta agli attacchi. Anziché utilizzare una stringa di connessione SQL, è necessario utilizzare la nuova classe SqlCredential la cui proprietà Password è una SecureString. Si prega di fare riferimento agli articoli sotto per aiuto.

https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcredential.password(v=vs.110).aspx

http://www.codeproject.com/Tips/408901/Storing-your-connection-string-password-in-SecureS

Problemi correlati