Recientemente tuve una discusión con algunos de mis colegas en mi trabajo porque dijeron que es mejor tener una conexión de cadena cifrada en un .DLL. Y dije, ¿por qué simplemente no usa la conexión de cadena definida en web.config encriptado? es lo mismo y es mejor porque el marco de la entidad, por ejemplo, busca el nombre de la conexión en la configuración web de la aplicación, ahora quiero saber desde un punto de seguridad qué es mejor o cuál es la mejor práctica ??
No hay una diferencia sustancial, excepto que tendrás que crear un binario si quisieras hacer un cambio de configuración si lo pones en una DLL, mientras que un administrador podría simplemente modificar la configuración con un buen entendimiento fuera de la Herramientas de estante si está en la configuración. Ya existe un mecanismo para cifrar cadenas de configuración y guía adicional sobre MSDN . Las versiones actuales de Asp.Net pueden tener mecanismos alternativos, así que haga una investigación adicional antes de comprometerse con un enfoque.
El hecho de que algo esté en una DLL no lo hace más seguro. Un editor de texto también puede abrir archivos binarios, herramientas como Reflector pueden proporcionar una interfaz más agradable para navegar por un DLL .NET; una DLL no proporcionará ningún cifrado "extra".
No importa dónde se almacenan los datos cifrados, importa cómo se cifran.
Las secciones cifradas en un web.config normalmente se cifran con la API de protección de datos , que Es extremadamente difícil de descifrar sin comprometer toda la máquina. También puede usar un contenedor de claves RSA, que es similar (es difícil sacarlos de la máquina).
Si desea almacenar la cadena cifrada en la DLL, está bien, supongo, aunque no es intrínsecamente más seguro que un cifrado web.config (cualquiera puede ver esa DLL con Reflector ), y obviamente es más difícil de cambiar (necesitarías recompilarlo). Pero nuevamente, lo que es mucho más importante es cómo se generó esa cadena encriptada; Es de suponer que no está utilizando los mismos proveedores que usaría para un web.config cifrado, así que, ¿qué está utilizando?
Un esquema de cifrado es tan fuerte como la clave privada o el secreto compartido. Si esa clave está también almacenada en su ensamblaje, entonces es posible que no tenga ningún cifrado. Si está almacenado en alguna base de datos externa, entonces se plantea la cuestión de cómo se protege la cadena de conexión de esa . Esto realmente solo puede llevar a una seguridad general más débil.
Por otra parte, si usted fuera un proveedor de servicios y la cadena de conexión estuviera encriptada con una contraseña de usuario , sería más seguro que usar una máquina estática llave. Nuevamente, si está utilizando contraseñas de usuario para cifrar, es bastante improbable que esté codificando los datos cifrados en su ensamblaje, ya que debe generarse y almacenarse en respuesta a la acción del usuario (no del desarrollador). / p>
Realmente no puedo pensar en muchas situaciones en las que la codificación de una cadena de conexión (encriptada) en la DLL sea más segura que encriptar la sección web.config relevante. En el mejor de los casos, solo se añaden inconvenientes, en el peor de los casos, se basa en una seguridad personalizada y llena de agujeros. Hágase un favor y haga lo que recomienda Microsoft: simplemente cifre su web.config si hay datos confidenciales allí.
La mejor práctica para ASP.NET es poner todas las configuraciones / configuraciones en el archivo web.config o en el archivo app.config (para otros tipos de proyectos).
El cifrado y el motivo para utilizarlo en las cadenas de conexión deben ser un caso muy especial. Debido a que la mayoría de los casos, hasta el 99%, no necesita cifrar las cadenas de conexión. Las aplicaciones empresariales de Microsoft tienen su cadena de conexión expuesta en el archivo web.config / app.config. Creo que estás complicando la seguridad.
Una cosa más, codificar las cadenas de conexión es una mala práctica. Por ejemplo, no coloque ninguna cadena de conexión (también conocida como cadena de conexión) en una DLL o .aspx / .ascx / .cshtml o código subyacente.
Lea otras preguntas en las etiquetas c# web-development security asp.net entity-framework