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

Question

La aplicación de mi equipo está desarrollando actualmente tiene un archivo DLL que se utiliza para llevar a cabo todos los accesos a la base de datos. La aplicación no puede usar una conexión confiable porque la base de datos está detrás de un firewall y el servidor de dominio no. Por lo tanto, parece que la cadena de conexión debe tener un nombre de usuario y contraseña DB. La DLL actualmente con la cadena de conexión de base de datos codificado, pero no quiero hacer esto cuando lancemos como el conjunto puede ser desmontado y el nombre de usuario y la contraseña sería justo allí a la intemperie.

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

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

ACTUALIZACIÓN: Gracias a todos los que han contestado. Voy a tratar de responder a algunas de las preguntas de nuevo a mí ... La DLL de datos es utilizada por ambos formularios Web ASP.NET y Windows Forms VB.NET. Entiendo que las aplicaciones pueden tener sus propios archivos de configuración, pero no he visto nada en los archivos de configuración para las DLL. Lamentablemente, no puedo acceder a la publicación 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 usuario (o ex usuario) puede ser un atacante, ¡lo estamos ocultando a todos!

Answer 1

No estoy seguro, pero creo que se puede poner en un archivo de configuración y cifrar el archivo de configuración.

Actualización: Ver post de Jon Galloway here.

Answer 2

Si la aplicación es una aplicación ASP.NET a continuación, sólo cifrar 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 usar un servicio web u otro tipo de mecanismo seguro para almacenarla de manera central. Esto facilitaría actualizaciones más fáciles en el futuro y no está almacenando la cadena de conexión localmente.

Sólo algunos pensamientos.

Actualizado: @lassevk

"Almacenamiento de la cadena de conexión en el servidor, y obtener a través de una conexión web suena bien, hasta que se da cuenta que necesita la seguridad en esa conexión web, así, de lo contrario una el atacante podría suplantar su programa y hablar con la conexión web ".

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

Answer 3

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

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 de una sola manera.

Almacenar la cadena de conexión en un servidor, y obtenerla a través de una conexión web suena bien, hasta que se da cuenta de que también necesita seguridad en esa conexión web, de lo contrario un atacante podría suplantar su programa y hablar con el conexión web

Déjame hacerte una pregunta. ¿De quién 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 usar la suplantación. Además, puede usar la biblioteca de la empresa (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 soporta la encriptación en los valores de configuración como esta. Podrías dejarlo en un archivo de configuración, pero encriptado.

Answer 6

Usted quiere ser capaz de distribuir el DLL con toda la información de configuración de estar en un lugar configurable, pero el hecho es que no se puede tener uno de los archivos de configuración de .NET práctico-excelente para un archivo DLL a menos que hagas algo personalizado

Quizás necesite replantearse qué responsabilidad debe tener su 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 archivo DLL lea un archivo de configuración?

Answer 7

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

Answer 8

varias opciones:

1. de almacén en web.config y cifrar
2. tienda en DLL y ofuscar (Dotfuscator)
3. tienda una en web.config (cifrada por supuesto) y descansan en la base de datos (si tiene que usar múltiples y el cifrado/descifrado se convierte en un problema)