Dónde almacenar contraseñas de db cuando se usan aplicaciones de Windows .NET o ASP.NET

Question

Tengo un escenario que me ha estado preocupando durante años. Si tiene que conectarse a una base de datos u otro servicio (como un servicio web) usando un nombre de usuario y contraseña, ¿cuál sería el lugar más seguro para almacenar esta información si se está conectando mediante un ensamblado .NET? Entiendo que tendrías que encriptar la contraseña, pero luego te toparías con una especie de problema de huevo de gallina. Bien, puedes encriptarlo, pero ¿dónde pones la llave?

En .NET, no puede codificar la contraseña porque puede descompilar el código .NET.

Analicé el uso de derechos basados ​​en ensamblaje con Almacenamiento aislado, pero MS recomienda no almacenar elementos secretos no encriptados allí porque los usuarios privilegiados pueden obtener acceso, así que, de nuevo, estamos trasladando el problema del punto A al punto B. Por ejemplo, un administrador de dominio sin necesidad de conocer la información en una base de datos podría obtener acceso debido a la capacidad de ser administrador en cualquier estación de trabajo del dominio.

Puede cifrar App.Config y Web.Config, pero creo que los usuarios de priveledges pueden acceder a las claves.

Creo que se encuentra con el mismo problema con DPAPI.

Consideré almacenar las contraseñas, cifrarlas en una base de datos remota y obtenerlas a través de la autenticación del sistema operativo, pero nuestro departamento prohíbe el almacenamiento de contraseñas en los servidores de la base de datos. Estoy bastante seguro de que estoy atascado y quería confirmación.

Answer 1

No desea guardar la contraseña en el conjunto, y reinventar la rueda solo crea más problemas (e introduce más vulnerabilidades) de lo que vale. Si está utilizando la plataforma MS tanto en la base de datos como en el servidor web, la forma más fácil de manejar esto es use a trusted connection, y otorgue derechos en el servidor SQL a la identidad que su aplicación está usando.

En segundo lugar, yo solo let DPAPI do its job to encrypt your connection settings.

Answer 2

Aquí hay un par de opciones.

1. almacenarlos en el archivo de configuración de cifrado
2. almacenarlos en un archivo externo que se cifra con una semilla generada. Ofuscar el código que almacena esta semilla base o almacenarla en un dll C++ (endurecido para descompilar).

Answer 3

Esta es una buena pregunta y he estado buscando una respuesta yo mismo. El problema que tuve fue mantener las contraseñas db seguras en caso de que el servidor fuera pirateado y se pudieran recuperar archivos individuales. Una opción muy interesante que he encontrado es que las secciones de web.config pueden ser cifradas y descifradas automáticamente sobre la marcha por .NET Framework que usaría Windows secure store para mantener y recuperar la clave de cifrado por usted. En mi situación, eso no estaba disponible porque mi proveedor de hosting no lo soportaba, pero puede echarle un vistazo a esta opción. Por qué creo que puede funcionar es que usted puede administrar de forma independiente la seguridad de lo que los usuarios pueden acceder a la tienda segura de Windows y limitar significativamente las posibles infracciones. Un pirata informático que irrumpe en el servidor podría obtener una copia de sus archivos de configuración y todos sus ensamblajes, pero acceder a la clave de descifrado sería otro obstáculo para él.

Answer 4

Se pueden utilizar los siguientes métodos de la .NET Framework para proteger sus datos, utilizan la DPAPI internamente para proteger sus datos, y se puede utilizar directamente en C# o VB.NET y sin tener que jugar un poco con las llamadas DLL del sistema:

namespace System.Security.Cryptography 
{ 
    // Summary: 
    //  Provides methods for protecting and unprotecting data. This class cannot 
    //  be inherited. 
    public sealed class ProtectedData 
    { 
     public static byte[] Protect(byte[] userData, 
      byte[] optionalEntropy, DataProtectionScope scope); 
     public static byte[] Unprotect(byte[] encryptedData, 
      byte[] optionalEntropy, DataProtectionScope scope); 
    } 
} 

Para usarlo, agregar la referencia System.Security a su proyecto. Recomiendo utilizar la matriz de bytes optionalEntropy para agregar SALT a sus datos protegidos (agregue algunos valores aleatorios a la matriz de bytes que son únicos para los datos que pretende proteger).

Para scope puede usar scope, que cifrará los datos para proteger con las credenciales del usuario actual.

En algunos casos, DataProtectionScope.LocalMachine es útil también. En este caso, los datos protegidos están asociados con el contexto de la máquina. Con esta configuración, cualquier proceso que se ejecute en la computadora puede desproteger los datos. Por lo general, se usa en aplicaciones específicas del servidor que se ejecutan en un servidor donde no se permite el acceso a los usuarios que no son de confianza.

Utilice el método Protect para cifrar los datos y descifrarlos con Unprotect. Puede almacenar la matriz de bytes devuelta según los requisitos de su aplicación (archivo, base de datos, registro, etc.).

Más acerca de estos métodos se puede encontrar aquí en MSDN:

• Windows data protection - información general acerca de la funcionalidad DPAPI,
• Protected data class - especificación de la clase ProtectedData,
• Protect method - descripción sobre el uso de el Protect método

Para muestras de código y en el caso usted está interesado en la encriptación de las partes de las aplicaciones .config, mira esto:

• Encrypt passwords in config - artículo que explica cómo cifrar partes de la web/app.config

Te recomiendo usar una SAL (es decir, utilizando el parámetro optionalEntropy) - protege contra los ataques de tabla de arco iris.

---

Hay un inconveniente de la solución DPAPI me gustaría mencionar: Se genera la clave basada en las credenciales de Windows, lo que significa el que tiene acceso a las credenciales de Windows tiene, posiblemente, el acceso a los datos protegidos. Un programa que se ejecuta bajo su cuenta también puede acceder a los datos protegidos.