encryption - ¿Es inseguro pasar el vector de inicialización y la sal junto con el texto cifrado?

passwords password-protection

Question

Soy nuevo en la implementación del cifrado y todavía estoy aprendiendo lo básico, parece.

Tengo necesidad de capacidades de cifrado simétricas en mi base de código de código abierto. Hay tres componentes para este sistema:

• Un servidor que almacena algunos datos de usuario, e información sobre si está o no cifrada, y cómo
• Cliente AC # que permite a un usuario cifrar sus datos con una contraseña simple al enviar al servidor y descifrar con la misma contraseña al recibir
• Un cliente de JavaScript que hace lo mismo y, por lo tanto, debe ser compatible con el método de cifrado del cliente C #

Mirando varias bibliotecas de JavaScript, encontré SJCL, que tiene una página de demostración encantadora aquí: http://bitwiseshiftleft.github.com/sjcl/demo/

A partir de esto, parece que lo que un cliente necesita saber (además de la contraseña utilizada) para descifrar el texto cifrado es:

• El vector de inicialización.
• Cualquier sal utilizada en la contraseña.
• El tamaño de la llave
• Fuerza de autenticación (no estoy totalmente seguro de qué es esto)

¿Es relativamente seguro mantener todos estos datos con el texto cifrado? Tenga en cuenta que este es un código base de código abierto, y no hay manera de que pueda ocultar estas variables de manera razonable a menos que le pida al usuario que las recuerde (sí, a la derecha).

Cualquier consejo apreciado.

Answer 1

Los vectores de inicialización y las sales se llaman así, y no claves, precisamente porque no es necesario que se mantengan en secreto. Es seguro y habitual codificar dichos datos junto con el elemento cifrado / hash.

Lo que necesita una IV o sal es para usarse solo una vez con una clave o contraseña determinada. Para algunos algoritmos (por ejemplo, cifrado CBC) puede haber algunos requisitos adicionales, cumplidos al elegir el IV al azar, con probabilidad uniforme y un generador de números aleatorios criptográficamente fuerte. Sin embargo, la confidencialidad no es una propiedad necesaria para una IV o sal.

El cifrado simétrico rara vez es suficiente para proporcionar seguridad; por sí mismo, el cifrado protege contra ataques pasivos , donde el atacante observa pero no interfiere. Para protegerse contra ataques activos , también necesita algún tipo de autenticación. SJCL utiliza los modos de cifrado CCM o OCB2 que combinan el cifrado y la autenticación, por lo que está bien. La "fuerza de autenticación" es la longitud (en bits) de un campo dedicado a la autenticación dentro del texto cifrado; una fuerza de "64 bits" significa que un atacante que intenta alterar un mensaje tiene una probabilidad máxima de 2 ^-64 para lograrlo sin ser detectado por el mecanismo de autenticación (y no puede saber si lo ha logrado sin intentarlo, es decir, tener el mensaje modificado enviado a alguien que conoce la clave / contraseña). Eso es suficiente para la mayoría de los propósitos. Una mayor fuerza de autenticación implica un texto cifrado más grande, por (aproximadamente) la misma cantidad.

No he mirado la implementación, pero a partir de la documentación parece que los autores de SJCL conocen su oficio e hicieron las cosas correctamente. Recomiendo usarlo.

Recuerda las advertencias habituales de las contraseñas y Javascript:

• Javascript es un código que se ejecuta en el lado del cliente pero se descarga desde el servidor. Esto requiere que la descarga esté protegida de integridad de alguna manera; de lo contrario, un atacante podría inyectar algo de su propio código, por ejemplo, un parche simple que también registra una copia de la contraseña ingresada por el usuario en algún lugar. En la práctica, esto significa que el código SJCL debe servirse a través de una sesión SSL / TLS (es decir, HTTPS).

• Los usuarios son seres humanos y los seres humanos son malos para elegir contraseñas. Es una limitación del cerebro humano. Además, las computadoras se vuelven cada vez más poderosas, mientras que los cerebros humanos se mantienen más o menos sin cambios. Esto hace que las contraseñas sean cada vez más débiles hacia los ataques de diccionario , es decir, búsquedas exhaustivas de contraseñas (el atacante intenta adivinar la contraseña del usuario al intentar contraseñas "probables"). Un texto cifrado producido por SJCL se puede usar en un ataque de diccionario fuera de línea : el atacante puede "probar" las contraseñas en sus propias computadoras, sin tener que compararlas con su servidor, y solo está limitado por sus propias capacidades informáticas. SJCL incluye algunas características para dificultar los ataques de diccionario sin conexión:

  1. SJCL usa una sal, que evita el costo compartido (generalmente conocido como "tablas precomputadas", en particular "tablas de arco iris", que son un tipo especial de tablas precomputadas). Al menos el atacante tendrá que pagar el precio total de la búsqueda del diccionario para cada contraseña atacada.
  2. SJCL usa la sal repetidamente , al codificarla con la contraseña una y otra vez para generar la clave. Esto es lo que SJCL llama el "factor de fortalecimiento de contraseña". Esto hace que la transformación de contraseña a clave sea más costosa para el cliente, pero también para el atacante, que es el punto. Hacer la transformación de la clave 1000 veces más larga significa que el usuario tendrá que esperar, tal vez, medio segundo; pero también multiplica por 1000 el costo para el atacante.