¿La aplicación web encripta los datos del cliente con la contraseña de inicio de sesión?

1

Estoy escribiendo una aplicación web para la gestión de información personal que se ejecuta en la nube. Para eso, estoy considerando el cifrado del lado del cliente utilizando AES256 con window.crypto y SJCL como respaldo para los navegadores más antiguos. El cifrado se basaría entonces en la contraseña de inicio de sesión del usuario. Además, también estoy pensando en hacer el hashing de contraseñas en el lado del cliente.

¿Eso está aumentando la privacidad del usuario? ¿O me estoy perdiendo algo? Sé que la forma estándar es simplemente almacenar datos "texto sin formato" y hacer hashing del lado del servidor.

EDIT Para agregar un alcance más claro, la intención es: en caso de que la base de datos sea robada, los datos del usuario deberían ser difíciles de leer. (Al menos no serán datos simples en ese caso). Al mismo tiempo, cuando el usuario [email protected] usa 123456 para su cuenta de correo y para su cuenta PIM de aplicación web, un atacante aún tiene que revertir el hash de contraseña en Para acceder a Gmail.com de Foo.

En particular, imagine el siguiente escenario: un atacante puede obtener la base de datos y verifica los registros de la base de datos del usuario [email protected]. Obtiene el hash, y algunos datos de usuario encriptados. Con el hash, puede iniciar sesión en la API de PIM de la aplicación web. Sin embargo, no puede leer los datos del usuario.

Con el hash filtrado, el atacante podría comprometer fácilmente los datos a través de la API, pero eso no importa mucho para este escenario. El objetivo principal es aumentar la privacidad de los datos del usuario en caso de una pérdida de la base de datos.

(Además, me gustaría permitir que el usuario desconfíe, al menos ligeramente, del host de aplicación web que lee datos privados. Estoy seguro de que esta solución no se acerca a eso, pero al menos podría ser un primer paso).

Respecto al rendimiento: la API de Web Crypto puede hacer PBKDF2, que me parece bien para el hashing. ( Ejemplo de Github ) SJCL puede ser demasiado lenta como alternativa, por lo que podría tener sentido transpilar C ++ a (asm. ) js.

    
pregunta Philip 04.03.2017 - 20:57
fuente

1 respuesta

2

Consulte this y esta preguntas y todas las respuestas sobre el hashing / encriptación del lado del cliente.

Para resumir, el JavaScript del navegador es demasiado lento para la función de hashing de contraseñas como bcypt o scrypt, que se usará para obtener una clave para AES a partir de la contraseña del usuario. Deberá reducir el número de iteraciones y / u otros parámetros de hash y, por lo tanto, reducir la seguridad general de la implementación. Si desea el cifrado / cifrado del lado del cliente, deberá crear extensiones de navegador como lo hacen los administradores de contraseñas en línea populares.

EDITAR:

Si usted o el usuario desconfían de la aplicación web de lectura de datos privados ¿cómo puede confiar en que la aplicación de la aplicación web proporcione un código confiable? ¿Qué es detener la aplicación de la aplicación web de la aplicación de código JavaScript que filtrará información antes del cifrado?

Para elaborar más directamente los problemas con la criptografía del navegador, consulte estos enlaces: enlace

enlace

Para una opinión más reciente:

enlace

Con respecto a la privacidad del usuario, no almacenará texto sin formato. Puede usar SSL para transmitir texto sin formato y almacenarlo encriptado usando una clave derivada de la contraseña del usuario. Almacenar contraseña hash para la autentificación. Hacer todo el cifrado y hash del lado del servidor. O eso o entregar una aplicación nativa / extensión de navegador web que se puede firmar y verificar. En ese caso, no tiene que confiar en el proveedor de aplicaciones web, solo lo usará para el almacenamiento de datos (encriptados).

    
respondido por el Marko Vodopija 04.03.2017 - 23:04
fuente

Lea otras preguntas en las etiquetas