¿Cuál es la mejor manera de almacenar cadenas de conexión en archivos DLL .NET?

Question

La aplicación que mi equipo está desarrollando actualmente tiene una DLL que se utiliza para realizar todos los accesos a la base de datos.La aplicación no puede utilizar una conexión confiable porque la base de datos está detrás de un firewall y el servidor de dominio no.Entonces parece que la cadena de conexión debe tener un nombre de usuario y contraseña de base de datos.La DLL actualmente tiene la cadena de conexión de la base de datos codificada, pero no quiero hacer esto cuando la iniciemos, ya que el ensamblaje se puede desmontar y el nombre de usuario y la contraseña estarían ahí a la vista.

Uno de los requisitos es que la contraseña debe cambiarse una vez cada pocos meses, por lo que necesitaríamos implementarla en nuestra base de usuarios internos.

¿Existe alguna manera de almacenar la contraseña cifrada de tal manera que podamos distribuirla fácilmente a toda la base de usuarios sin almacenarla en el ensamblado?

ACTUALIZAR:Gracias a todos los que respondieron.Intentaré responderme algunas de las preguntas...La DLL de datos es utilizada tanto por ASP.NET WebForms como por VB.NET WinForms.Entiendo que las aplicaciones pueden tener sus propios archivos de configuración, pero no he visto nada sobre archivos de configuración para DLL.Desafortunadamente, no puedo acceder al puesto de Jon Galloway en el trabajo, así que no puedo juzgar si funcionará.Desde el punto de vista del desarrollo, no queremos utilizar servicios web internos, pero es posible que los proporcionemos a terceros en algún momento del próximo año.No creo que la suplantación funcione porque no podemos autenticar al usuario a través del firewall.Como un usuario (o ex usuario) puede ser un atacante, ¡lo ocultamos a todos!

Answer 1

No estoy seguro, pero creo que puedes ponerlo en un archivo de configuración y cifrarlo.

Actualizar:Ver la publicación de Jon Galloway aquí.

Answer 2

Simplemente asuma que los malos sacarán las credenciales de su archivo de configuración.Esto significa que podrán iniciar sesión en su base de datos y hacer todo lo que ese usuario sea capaz de hacer.Así que asegúrese de que el usuario no pueda hacer nada malo, como acceder a las tablas directamente.Haga que ese usuario solo sea capaz de ejecutar ciertos procedimientos almacenados y estará en mejor forma.Este es un lugar donde brillan los sprocs.

Answer 3

Odio decir esto, pero tan pronto como pones algo en una máquina cliente, la seguridad de esos datos desaparece.

Si su programa va a descifrar esa cadena, debe asumir que un atacante puede hacer lo mismo.Adjuntar un depurador a su programa sería una forma.

Almacenar la cadena de conexión en un servidor y obtenerla a través de una conexión web suena bien, hasta que te das cuenta de que también necesitas seguridad en esa conexión web; de lo contrario, un atacante podría hacerse pasar por tu programa y hablar con la conexión web.

Déjame hacerte una pregunta.¿A quién le estás ocultando la cadena de conexión?¿El usuario o un atacante?Y si el usuario, ¿por qué?

Answer 4

También hay otras ideas.Siempre puedes utilizar la suplantación.Además, puede utilizar la biblioteca empresarial (biblioteca común).

<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 admite el cifrado en valores de configuración como este.Podrías dejarlo en un archivo de configuración, pero cifrado.

Answer 6

Desea poder distribuir la DLL con toda la información de configuración en un lugar configurable, pero el hecho es que no puede tener uno de los prácticos archivos de configuración .NET para una DLL a menos que haga algo personalizado.

Quizás necesites repensar qué responsabilidad debería tener tu DLL.¿Sería posible o tendría sentido exigir que el usuario de su biblioteca pase la cadena de conexión?¿Realmente tiene sentido que su DLL lea un archivo de configuración?

Answer 7

Si la aplicación es una aplicación ASP.NET, simplemente cifre la sección de cadenas de conexión de su web.config.

Si la aplicación es una aplicación cliente que se ejecuta en varias máquinas, en lugar de almacenar la cadena de conexión localmente, considere utilizar un servicio web o algún otro tipo de mecanismo seguro para almacenarla de forma centralizada.Esto facilitaría las actualizaciones en el futuro y no almacenará la cadena de conexión localmente.

Sólo algunas ideas.

Actualizado: @lassevk

"Almacenar la cadena de conexión en un servidor y obtenerla a través de una conexión web suena bien, hasta que te das cuenta de que también necesitas seguridad en esa conexión web; de lo contrario, un atacante podría hacerse pasar por tu programa y hablar con la conexión web. "

La seguridad en el servicio web estaba implícita.Dependiendo del tipo de implementación, existen numerosas opciones... por ejemplo, certificados del lado del cliente.

Answer 8

Varias opciones:

1. Almacenar en web.config y cifrar
2. Almacenar en dll y ofuscar (dotfuscator)
3. Almacene uno en web.config (cifrado, por supuesto) y descanse en la base de datos (si tiene que usar varios y el cifrado/descifrado se vuelve complicado)