Uso de AES para cifrar los datos del usuario

3

No sé casi nada acerca de la criptografía, y básicamente estoy buscando a alguien que revise lo que estoy haciendo y me diga si estoy cometiendo errores.

El usuario ingresa información confidencial y una contraseña. Luego uso esa contraseña como clave para que AES cifre la información y almacene el texto cifrado. Más tarde, si el usuario desea recuperar la información, vuelve a ingresar la contraseña y yo uso AES para descifrar el texto cifrado.

¿Esto es seguro? Ahora mismo estoy usando la contraseña directamente como clave de cifrado. He visto que PBKDF2 se menciona mucho en contextos similares, pero no estoy seguro de cuál es el objetivo. Nunca voy a guardar la contraseña en ningún lugar. Si el usuario olvida su contraseña, la información se perderá para siempre.

Si es posible, me gustaría poder almacenar el texto cifrado en las cookies de un navegador web (aunque esto no es totalmente necesario), por lo que es importante que la información esté segura.

Notas de implementación:

Estoy usando CryptoJS, que creo que genera aleatoriamente la sal y IV. No conozco los detalles realmente, parece que lo hace todo por mí.

Parte de la información que estoy almacenando es el nombre del usuario, así que no sé si eso me abre a un ataque de texto sin formato conocido o algo así.

    
pregunta sjelin 13.11.2013 - 05:55
fuente

2 respuestas

4

La respuesta está en el nombre: PBKDF es un acrónimo que significa "Función de derivación de clave basada en contraseña". Todo su trabajo es tomar una contraseña como entrada y generar una clave de cifrado como salida.

La razón principal por la que necesitamos funciones como esta es que los algoritmos de encriptación como AES toman una clave de tamaño fijo. Por definición, AES-128 requiere una clave de 128 bits (16 bytes). Pero la contraseña de un usuario es simplemente una serie de bytes: tal vez sean 50 bytes, tal vez sean solo 5 bytes, dependiendo de lo que ingresó el usuario. Por lo tanto, si desea usar la contraseña para cifrar, de alguna manera tiene que incrustar esa contraseña en los 16 bytes exactos requeridos por AES. Obviamente, ya estás haciendo algo así para introducir tu contraseña actual en AES, incluso si no la reconoces por ese nombre.

Un PBKDF está diseñado para tomar, sin embargo, los bytes que ingresa el usuario, mezclarlos todos usando un algoritmo (llamado hash) y luego producir una cadena de bits adecuada para usar como una clave. Si necesita 16 bytes para su clave AES, simplemente tome los primeros 16 bytes que salen de la función PBKDF.

Piense si no usó un PBKDF, pero en su lugar requirió que sus usuarios ingresen al menos una contraseña de 16 bytes. Sin un PBKDF, ¿qué sucede con todo después del byte 16? Se vuelve sin sentido. Si escribo una contraseña de security.stackexchange.com , también podría escribir una contraseña de security.stackexPOSITION@ORG o simplemente security.stackex y cualquiera de ellas aún funcionaría. Pero como PBKDF mezcla todas esas letras juntas, todas contribuyen a la clave y se comprueba la contraseña completa.

La siguiente razón por la que necesitamos las funciones PBKDF es que las contraseñas tienen mucha predecibilidad, ya que los humanos de habla inglesa usualmente solo usan caracteres en los rangos de a-z, A-Z y 0-9. A pesar del hecho de que hay 8 bits en un byte, una contraseña de 10 caracteres no proporcionará 80 bits de incertidumbre en la clave; la mayoría proporcionará 47 bits (o menos) de incertidumbre, y eso significa que un atacante moderno puede adivinarlo fácilmente. Pero como PBKDF toma en cuenta todas las letras de la contraseña, hace que una contraseña de 20 caracteres sea más fuerte que una contraseña de 10 caracteres, y mejora la seguridad de sus usuarios.

Una rutina más fuerte como PBKDF2 va un paso más allá que un simple PBKDF para ayudar a proteger contra un ataque de adivinación de contraseña, al hacer que la operación requiera una gran cantidad de recursos informáticos. Un atacante que desee intentar adivinar cada palabra del diccionario necesitará solo unos pocos milisegundos para probar cada palabra como clave de descifrado. Un atacante que necesite ejecutar 10,000 hashes con PBKDF2 tardará horas o días en probar todo el diccionario.

    
respondido por el John Deters 13.11.2013 - 20:03
fuente
0

Por lo que sé, esto debería estar bien ... Hice algo similar en PHP para una tarea similar. Además, la memoria del usuario es uno de los mejores lugares para almacenar la clave AES. O al menos parte de ello. Ya sabes, porque si lo guardaras en una base de datos o un archivo en el servidor, una vez que la base de datos o el servidor estén bajo ataque, los datos ya no estarán seguros.

Me aseguraría de que la contraseña del usuario sea lo suficientemente fuerte y lo suficientemente aleatoria. Implementaría algunos controles habituales para las letras mayúsculas, los números y también los puntos o algo. El usuario debe saber que esta es la contraseña utilizada para almacenar sus datos y debe ser diferente de la contraseña que usa para iniciar sesión (si tiene algo así). Y también la sal (o la segunda parte de la llave) debe almacenarse de forma segura, por ejemplo. También AES en la base de datos con clave almacenada en el servidor. Algo así.

Para simplificar el pbkdf, si lo entiendo correctamente: es una forma de "convertir" la contraseña del usuario a la clave de cifrado real. Entonces, si usa eso en relación con AES, sería lo mejor.

Otra cosa que estoy seguro es que algunos de los expertos aquí señalarían más inconvenientes de este enfoque. Sin embargo, creo que AES es lo suficientemente seguro para las próximas décadas. Los chicos de 1Password parecen pensar eso también .

    
respondido por el Jakub Žitný 13.11.2013 - 07:21
fuente

Lea otras preguntas en las etiquetas