Estoy encriptando datos (industria del cuidado de la salud) utilizando las clases de cifrado aes en .NET Framework. ¿Cuáles son algunas de las ubicaciones recomendadas para almacenar de forma segura la llave? Lo tengo en la web.config para el desarrollo, pero eso no lo hace digno de producción, por decir lo menos.Dónde almacenar la clave de cifrado
Si la aplicación requiere autenticación usando las teclas a continuación
aproximación normal en máquinas UNIX es almacenar las contraseñas en formato hash.
Puede usar sha-512 + salt.
Luego puede calcular el hash cuando el usuario ingresa la contraseña y verificar en contra de usted.
Las contraseñas/clave en sí se pueden almacenar en cualquier lugar si se trata de hash. Si no lo almacena en el directorio de usuarios técnicos donde ninguno tiene acceso.
EDITAR para aquellos que no quieren poner demasiado esfuerzo en la comprensión CASO DE USO, que me he presentado
Johny tiene algunos datos cifrados AES.
Él almacena su llave en la cabeza.
Quiere guardar esto en alguna parte de su PC para automatizar el acceso.
Puede almacenarlo como ASCII en web.config.
Pero puede decir que no es más ASCII sino hash.
Durante la aplicación de autenticación calcula las comprobaciones de hash es la clave adecuada, luego utiliza esta clave ....
Probablemente bajo de colisión con el algoritmo adecuado.
ps. simplemente publicando mi punto de vista sobre el tema.
¿Por qué eres tan sensible a la palabra "hash" ???
EDIT 2
sé lo que es hachís,
Yo sé lo que se llama así el cifrado de 2 vías ....
Puede cifrar los valores de web.config utilizando una función en los métodos de la marco:
http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
Esto es probablemente un lugar razonable para almacenar su clave - si alguien ha conseguido acceder a su servidor para recuperar estos datos, es probable que tenga bi preocupaciones de Gary.
cierto. ¿Es DPAPI más "seguro"? – Saraz
@Saraz - Lo siento, no sé la respuesta a eso ... – Paddy
@Saraz: ¿Más seguro que qué? Es más seguro en el sentido de que "no es posible recuperarlo sin acceso a nivel de administrador * en esa máquina específica *" (ya que el algoritmo de cifrado depende de los datos que son exclusivos de la máquina). En otras palabras, si alguien logró obtener su web.config, todavía no pudieron descifrar en una máquina diferente. – Piskvor
Lo que necesita hacer es ocultar esta clave en algún lugar, y una ubicación segura estaría dentro de una base de datos. Preferiblemente una base de datos diferente a la que contiene sus datos. Como los datos requieren combinaciones de nombre de usuario/contraseña para abrirlos, simplemente agrega una segunda capa de seguridad a su aplicación. Su aplicación necesitaría iniciar sesión en la base de datos de claves, recuperar la clave X para la aplicación Y y luego poder usarla. Sin embargo, tendría que almacenar la cadena de conexión para esta base de datos en alguna parte.
Incluso si almacenase solo una clave en una base de datos de claves, valdría la pena. Obliga a un hacker a tomarse un poco más de problemas para abrir esta base de datos y encontrar la clave antes de que pueda acceder a los datos. Como no existe una seguridad perfecta, sus opciones se limitan a retrasar el tiempo que le tomaría a un hacker obtener acceso.
Cifrar el archivo o datos web.config dentro de él también ayudará a retrasar al pirata informático, pero si la clave está dentro del archivo de configuración, todo lo que necesita hacer es descifrarlo de nuevo.
Esto no es realmente diferente de almacenar una clave en el archivo de configuración; necesita almacenar la cadena de conexión en su base de datos de claves en alguna parte, y si su hacker tiene acceso suficiente para acceder a su archivo de configuración, probablemente pueda obtener esto ... – Paddy
cierto. Pero agrega una segunda capa. Necesita acceder a la base de datos para obtener la clave y, en general, las bases de datos se almacenan en un sistema diferente. Si el servidor de la base de datos está configurado para aceptar llamadas solo desde la ubicación del servidor web, hará que sea más difícil para un hacker remoto acceder a la clave. Y si la base de datos almacenó unos cientos de claves (ficticias), el hacker aún no sabe cuál usar. –
Un enfoque que proporcionará una buena seguridad si se puede confiar completamente en las únicas personas que necesitarán usar la clave para cualquier propósito, es almacenar la clave cifrada con otra clave, una copia de la cual se almacena para cada usuario , cifrado con un hash de la contraseña de ese usuario (salado de forma diferente a la almacenada para la validación de contraseña). Incluso una persona malvada con acceso a cada bit de datos, en cualquier parte del universo, asociada a la clave de esa base de datos, no podría acceder a la base de datos sin la ingeniería inversa de al menos una de las contraseñas.
Tenga en cuenta que si las contraseñas de todas las cuentas válidas alguna vez se perdieran u olvidaran, los datos serían irrecuperables. Eso es parte de la naturaleza de la seguridad real. Si se quiere evitar la posibilidad de perder datos, se debe asegurar que las copias de seguridad de las claves y/o contraseñas necesarias se almacenen de forma segura.
En su lugar, quizás desee utilizar el cifrado basado en certificado. Consulte http://en.wikipedia.org/wiki/Certificate-based_encryption y http://msdn.microsoft.com/en-us/library/ms867080.aspx y http://msdn.microsoft.com/en-us. /library/ms229744.aspx –