Qual è il modo giusto di memorizzare le stringhe di connessione al database dal punto di vista della sicurezza?

Opzione migliore: non utilizzare una password per il database, ma invece utilizzare (Windows) l'autenticazione integrata, se possibile, e ovviamente isolare l'identità dell'applicazione che è autorizzata per il database. In questo modo l'OS / Webserver / SCM gestiscono la tua identità, in maniera molto sicura.

Se non è possibile seguire la procedura di IWA, è necessario crittografare in modo sicuro il connstring, preferibilmente utilizzando qualcosa come DPAPI (quindi non è necessario gestire la chiave di crittografia) e archiviare il valore crittografato in un registro protetto chiave con ACL forti.
Se sei su ASP.NET (dai tuoi commenti, ma non da OP), ci sono strumenti integrati per farlo automaticamente (aspnet_setreg, aspnet_regiis, ecc. A seconda della versione ...)

cose che non dovresti mai fare

• inserire la stringa di connessione in un file di testo.
• avere il file di configurazione nella cartella / directory accessibile pubblica

cose che dovresti fare.

• crea una funzione di supporto che genera la password del database al volo.
• cambia frequentemente password e nome utente del database.
• controlla se il tuo server è configurato correttamente, che non stai servendo file excutable come testo semplice.

Consiglia di archiviare la tua stringa di connessione al di fuori della directory principale del sito web.

Se utilizzi ASP.NET, il tuo file web.config si troverà nella directory principale del sito Web, ma puoi crittografare una sezione del file web.config utilizzando l'API di Data Protection, che memorizza in modo sicuro la chiave di decrittografia.

Quale framework stai usando per la tua applicazione web?

Come opzione, prova ad utilizzare il ruolo dell'applicazione per accedere al server sql

I vantaggi:

• Gli amministratori di rete regolari possono gestire l'accesso ai dati senza dover consultare l'amministratore del database (DBA), semplicemente controllando chi ha accesso a un'applicazione.
• Non è necessario preoccuparsi di tenere traccia del cambiamento degli utenti con SQL Server stesso. Imposta un ruolo dell'applicazione e puoi delegarne di nuovo a livello di rete.
• È possibile limitare la disponibilità dei dati a una singola applicazione. Ad esempio, un utente potrebbe essere in grado di modificare le informazioni contabili solo quando utilizza l'applicazione di contabilità generale e non quando si connette direttamente a SQL Server.