¿Hay alguna razón para usar AesManaged sobre DPAPI en este escenario?

Question

¿Hay alguna razón para usar AesManaged sobre DPAPI en este escenario?

#1 de Justin Moore (2 votos)
#2 de BrunoMCBraga (0 votos)

7

Tengo una situación en la que mi aplicación web se implementará en varios servidores web, y desearé almacenar algunos datos cifrados de forma segura en los servidores DB (cada servidor web tiene un servidor DB asociado).

Ahora, lo que pensaba hacer era implementar las funciones de biblioteca Encrypt y Decrypt que utilizan la clase AesManaged . Estos utilizarían una clave AES que sería diferente para cada servidor (generaríamos una nueva para cada servidor en implementación); de esa manera, cada servidor usaría una clave diferente. Luego usaríamos SectionInformation.ProtectSection() para cifrarlos en Web.config , por lo que estaban seguros.

Sin embargo, he llegado a través de ProtectedData clase. Esto se enlaza con la funcionalidad DPAPI de Windows y permite el cifrado y descifrado simétricos. Ahora me pregunto, ¿hay algún punto en mi uso de AesManaged con mis propias claves generadas, o debo simplemente cifrar y descifrar datos usando ProtectedData ? ¿Cuáles son los pros y los contras de cada uno?

encryption aes .net windows-dpapi

pregunta Jez 25.03.2015 - 01:41

fuente

2 respuestas

Lea otras preguntas en las etiquetas encryption aes .net windows-dpapi

Usando múltiples servicios de identidad oAuth simultáneamente Verificación de archivos firmados criptográficamente cuando la clave ha sido revocada

score 2 · Answer 1

Probablemente sea un poco tarde, pero solo como una recomendación para otras personas que se topan con esto. Para este tipo de problema, siempre usaría ProtectedData para rodar su propia implementación con AesManaged por dos razones. Primero, no necesita lidiar con la administración de claves criptográficas con ProtectedData, lo cual es una molestia para hacerlo correctamente. En segundo lugar, hay un puñado de consideraciones de seguridad que un desarrollador debe entender antes de lanzar su propio criptografía e incluso así existe la posibilidad de que el desarrollador pueda cometer un error y hacer que el criptografía sea inútil. ¿Por qué arriesgarse y arriesgarse a tener un dolor de cabeza cuando ya está disponible una solución perfectamente aceptable y ya examinada?

score 0 · Answer 2

Como lo mencionó Justin, usar sus propias llaves y luego administrarlas es un no ir. Es por eso que tiene un sistema operativo o mecanismos de lenguaje para hacer esto por usted. En java tienes almacenes de claves locales protegidos por contraseñas. La desventaja de confiar en el sistema operativo para proteger sus claves es que, en caso de que el sistema operativo subyacente esté dañado de alguna manera, probablemente perderá esas claves para siempre. ¿Por qué no utilizas RSACryptoServiceProvider con CspParameters para crear una tienda con tus propias claves?

Leer: enlace

enlace

Creo que esto podría ayudarte. De esta manera, no está limitado a las opciones clave del sistema operativo y puede mantener sus propias claves a salvo mientras las protege localmente en las tiendas.

Mantente seguro;)