¿Cuál es la forma correcta de almacenar cadenas de conexión de base de datos desde el punto de vista de la seguridad?

Mejor opción: no use una contraseña para la base de datos, sino que utilice la autenticación integrada (Windows) si es posible, y por supuesto aísle la identidad de la aplicación autorizada para la base de datos. De esa manera, el sistema operativo / servidor web / SCM gestionará su identidad de forma muy segura.

Si no es posible seguir el camino de IWA, deberá cifrar de forma segura la conexión, preferiblemente utilizando algo como DPAPI (para no tener que administrar la clave de cifrado) y almacenar el valor cifrado en un Registro protegido clave con ACL fuertes.
Si está en ASP.NET (de sus comentarios, pero no de OP), hay herramientas integradas para hacerlo automáticamente (aspnet_setreg, aspnet_regiis, etc., según la versión ...)

cosas que nunca debes hacer

• poner una cadena de conexión en un archivo de texto.
• tener el archivo de configuración en una carpeta / directorio de acceso público.

cosas que debes hacer.

• crear una función auxiliar que genere la contraseña de la base de datos al volar.
• cambia frecuentemente la contraseña de la base de datos y el nombre de usuario.
• compruebe si su servidor está configurado correctamente, que no está sirviendo archivos extraíbles como texto simple.

Recomendaría almacenar su cadena de conexión fuera del directorio raíz del sitio web.

Si está usando ASP.NET, su archivo web.config estará en el directorio raíz del sitio web, pero puede encripta una sección de su archivo web.config utilizando la API de protección de datos, que almacena la clave de descifrado de forma segura.

¿Qué marco de trabajo está utilizando para su aplicación web?

Como opción, intente usar función de la aplicación para acceder al servidor SQL

Beneficios:

• Los administradores de red regulares pueden administrar el acceso a los datos sin necesidad de consultar al administrador de la base de datos (DBA), simplemente controlando quién tiene acceso a una aplicación.
• No debe preocuparse por realizar un seguimiento de los cambios de usuarios con el propio SQL Server. Configura un rol de aplicación y puedes delegarlo a nivel de red.
• Puede limitar la disponibilidad de los datos a una sola aplicación. Por ejemplo, un usuario podría modificar la información contable solo cuando usa la aplicación del libro mayor, y no cuando se conecta directamente a SQL Server.