Vantaggio pratico dell'utilizzo di SqlCredential vs nome utente / password nella stringa di connessione

Question

Vantaggio pratico dell'utilizzo di SqlCredential vs nome utente / password nella stringa di connessione

#1 da (1 voti)
#2 da (1 voti)

1

Attualmente sto utilizzando l'autenticazione di SQL Server con nome utente / password come parte della stringa di connessione per la mia applicazione web. Per quanto ne so questa procedura standard all'interno del mondo .NET e forse oltre. Tuttavia, stavo esaminando i documenti per SqlConnection.ConnectionString proprietà dovuta a un problema non correlato e notato che dicono:

SqlCredential is a more secure way to specify credentials for a connection that uses SQL Server Authentication.

Suppongo che la maggior parte di questa sicurezza sia dovuta all'uso di SecureString per memorizzare la password. Questa classe ha una propria serie di problemi quando viene utilizzata nel contesto di un'applicazione Web perché implementa IDisposable . Ciò significa che devo fare una delle tre opzioni sbagliate:

Non disponga intenzionalmente di SecureString lasciandola una variabile globale statica che legge una volta la password dal file di configurazione.
Accetta il colpo di prestazione di leggere la password dal file di configurazione ogni richiesta.
Ignora i benefici di SecureString mantenendo la password in giro come string in modo da poter smaltire regolarmente SecureString senza incorrere nella penalità di lettura dal file di configurazione ogni richiesta.

Considerati questi problemi e il fatto che se qualcuno abbia accesso al server in cui sei stato ucciso . Inoltre, sembra che i vantaggi della crittografia della stringa di connessione si riducano sostanzialmente a riducendo il rischio di perdita accidentale dei dettagli persone che non dovrebbero averle:

By keeping the connection details out of source control, and out of general distribution, you reduce the possibility of loss or leakage. ... Due to this if encryption is in use, separating the key from the connectionstring and separating the connectionstring from the source is an essential action. Doing this has separated the duties and protection of the encryption keys (or configuration files) becomes a system administrator function, rather than a developer function.

Tuttavia, mi sembra che il modo più efficace per ridurre tale rischio sia limitare l'accesso al server e la stringa di connessione solo a coloro che devono sapere tramite la pipeline di build / release automatizzata ¹ e la protezione del server è ovviamente il primo e più importante passo verso la protezione della stringa di connessione. Mi sembra che ci sia probabilmente un minor vantaggio teorico nell'usare SqlCredential classe in un'applicazione web ², ma non c'è un reale vantaggio pratico rispetto alla presenza del nome utente / password nella stringa di connessione.

Detto questo, c'è probabilmente un difetto fondamentale nel mio ragionamento perché i membri di Microsoft sono un gruppo intelligente. Quindi cosa mi manca?

^{_{1: Trasformazione / aggiunta del valore automaticamente nella pipeline di build / release.}}

^{_{2: sto utilizzando un Servizio cloud di Azure e connettersi a un Database SQL di Azure , con la maggior parte della logica del livello dell'applicazione scritta in C # se importa.}}

asp.net asp.net-mvc password-management web-application databases

posta Erik 24.11.2015 - 22:12

fonte

2 risposte

1

Se imposti la password utente nella stringa di connessione anziché utilizzare la proprietà SqlConnection.Credential (che utilizza internamente SecureString ), un amministratore malintenzionato può scaricare la memoria di un'app in esecuzione e leggere la password in chiaro.

risposta data 29.01.2018 - 00:58

fonte

Leggi altre domande sui tag asp.net asp.net-mvc password-management web-application databases

Lo stesso browser è ugualmente sicuro su un SO diverso? XSS - Usare firebug per iniettare script

score 1 · Accepted Answer

Non sono uno sviluppatore .net, ma Java è molto simile. Credo che il caso d'uso di SecureString e SQLCredential sia per qualsiasi password che non sia vissuta a lungo. ad esempio, si accede brevemente a un SQL Server remoto, quindi si rilascia la connessione e si procede con qualsiasi altra operazione che l'app deve eseguire. L'uso di SecureString sembra rimuovere questa password utilizzata per un breve periodo dalla memoria ASAP piuttosto che attendere che venga rimossa in un (forse molto più tardi) tempo.

Dalla tua descrizione la tua applicazione utilizza una connessione al database persistente e probabilmente un pool di connessione al database. Quindi hai bisogno del nome utente / password per essere sempre in memoria. C'è poco o nessun vantaggio nel rimuovere la password dalla memoria poiché sarà caricata di nuovo in memoria molto presto, e alla fine viene memorizzata comunque in qualche file di configurazione.

Per quanto riguarda il tuo modo di pensare, è bene farlo, ma non dare agli esperti la massima autorità. Non possono conoscere la tua situazione specifica. Consiglierei cautela leggendo consigli generalizzati. Può o non può applicarsi a te. In questo caso, Microsoft deve fornire un'ampia risposta basata su tutti, in una vasta gamma di usi. Microsoft deve informare chiunque stia sviluppando app .net anche sul desktop, il che potrebbe includere un utente che digita semplicemente una password. I desktop hanno un modello di minaccia completamente diverso rispetto ai server. Per un utente desktop che ha inserito una password una volta al mattino e ha interrotto la connessione, sarebbe "cattivo" se quella password fosse sopravvissuta per ore dopo e la macchina fosse stata quindi compromessa da un buco di sicurezza completamente non correlato.

In altre parole, è una "best practice" dire a tutti di usare SQLCredential piuttosto che cercare di spiegare tutti i modelli di minacce, ecc. La maggior parte delle persone non intende approfondire la comprensione di ciò che si sta guardando.