envío de sales para la generación de claves

Question

envío de sales para la generación de claves

#1 de dr jimbob (1 votos)

1

Estoy trabajando en un proyecto que utiliza una combinación de un marco basado en web (Django) y una aplicación instalada (Python) con el fin de ingresar / subir datos. Tendré que enviar registros médicos a través de la web y he estado tratando de encontrar una manera de hacer un sistema criptográficamente sólido. Me imagino que puedo usar la tabla auth_user de django que contiene nombres de usuario y contraseñas con hash y con sal. El formato predeterminado para este campo es

algorithm_____$#iter$Salt_____$_________hashedpassword_____________________
pbkdf2_sha256$100000$6ID5G1Xym$s2snCtv3UncgSfGIS49d38ksv9LYuLGEsvWQwU66/xE=

Si tengo la contraseña y el salt, puedo volver a crear la contraseña con hash que quiero usar como clave para AES. El problema es que la sal es creada aleatoriamente por django durante la creación de la contraseña.

Mi pregunta es, ¿crearía alguna inseguridad para enviar la sal junto con la información cifrada?

Estoy pensando que no, porque de todos modos se supone que la sal es conocida por un atacante.

Pregunta complementaria: ¿Se considera AES seguro para la información médica? ¿Hay algún error que deba tener en cuenta?

hash salt aes

pregunta horriblyUnpythonic 15.01.2014 - 20:54

fuente

1 respuesta

Lea otras preguntas en las etiquetas hash salt aes

Error al revertir la conexión TCP del SearchIndexer.exe explotado ¿cómo caputre continuamente todo el tráfico de mi red? [cerrado]

score 1 · Accepted Answer

El consejo estándar es: No haga su propio rollo sistema de seguridad y espere que sea seguro, especialmente en un área con regulaciones estrictas para la seguridad de los datos y especialmente si es nuevo en el campo (aunque es bueno hacer preguntas).

Primero, tu intuición es correcta; No hay un gran problema para revelar su sal, que no necesita mantenerse en secreto como la contraseña (y el hash). Todo lo que necesita ser es tener una alta probabilidad de singularidad (por lo que todas las cuentas no son fácilmente atacadas en paralelo).

A continuación, AES es un cifrado de bloque seguro y cuando se usa en un modo de cifrado de bloque adecuado proporciona una buena seguridad. El modo ECB definitivamente debe evitarse ya que a menudo se filtra información. Los modos CBC y CTR son seguros para mantener el contenido de su archivo en secreto, sin embargo, estos modos no vienen con ningún tipo de código de autenticación / MAC incorporado que verifique que nadie haya manipulado sus datos. Probablemente debería usar un modo de cifrado autenticado, preferiblemente cifrar-y-MAC .

Me preocupa si un interlocutor de la red puede escuchar una cookie de sesión del servidor web django, luego usar esa cookie para iniciar sesión como administrador y luego obtener todos los hashes de los usuarios y descifrar toda la información enviada a través del Red a la que no deberían tener acceso.

También desconfiaría de posibles ataques de repetición (agregar datos únicos a las solicitudes cifradas) o filtrar información del tamaño de las respuestas cifradas; por ejemplo, si una persona anónima puede realizar una solicitud al servidor todos los días para obtener los registros médicos de X y buscar el tamaño de la respuesta que ha visitado o que no visitó recientemente. Además, desconfiaría de a dónde van los registros médicos y si se cifrarán en reposo en los discos duros de los usuarios.

También me preocupa si está realizando un registro de auditoría adecuado de quién está viendo qué datos médicos y si esos datos no se pueden manipular fácilmente.

Sin conocer los detalles completos de su escenario y los requisitos de seguridad, creo que puede ser mejor usar TLS (anteriormente conocido como SSL) con un certificado seguro, más una utilidad conocida para proporcionar el cifrado completo del disco.