Hash de contraseña del lado del cliente

El hash en el lado del cliente no resuelve el problema principal que el hash de la contraseña pretende resolver: qué sucede si un atacante obtiene acceso a la base de datos de contraseñas con hash. Dado que las contraseñas (con hash) enviadas por los clientes se almacenan tal como están en la base de datos, dicho atacante puede hacerse pasar por todos los usuarios enviando al servidor las contraseñas con hash de la base de datos tal como están.

Por otra parte, el hash en el lado del cliente es bueno porque garantiza al usuario que el servidor no tiene conocimiento de la contraseña, lo cual es útil si el usuario usa la misma contraseña para múltiples servicios (como la mayoría de los usuarios).

Una posible solución para esto es el hashing tanto en el lado del cliente como en el lado del servidor. Todavía puede descargar la operación pesada PBKDF2 al cliente y hacer una sola operación de hash (en la contraseña hash PBKDF2 del lado del cliente) en el lado del servidor. El PBKDF2 en el cliente evitará los ataques de diccionario y la única operación de hash en el lado del servidor evitará el uso de las contraseñas de hash desde una base de datos robada tal como está.

Hay poco tiempo cuando el hashing del lado del cliente vale la pena. Una de esas circunstancias es cuando el proceso de hash es computacionalmente intensivo, lo que puede ser el caso con PBKDF2.

Respondiendo a sus inquietudes:

1. También evite las sugerencias no validadas sobre la criptografía que encuentre en Internet. (Descargo de responsabilidad: no soy Bruce Schneier).
2. Las sales deterministas no son un problema, el único requisito real de la sal es que sea único para cada usuario. El verdadero propósito de la sal es evitar que una fuerza bruta en una contraseña se convierta en una fuerza bruta en todas las contraseñas en el caso de una base de datos comprometida. Incluso si almacenara un archivo sal aleatorio en su base de datos justo al lado de la contraseña con hash, todavía alcanzaría este objetivo, siempre que cada usuario sea diferente.
3. Como mencioné anteriormente, PBKDF2 está bien porque puedes decidir arbitrariamente la dificultad computacional del hash. Puede seleccionar una c de tal manera que un solo hash en el hardware moderno demore unos segundos, eliminando efectivamente el riesgo de un ataque de fuerza bruta de nivel API. (Por supuesto, es posible que sus clientes no disfruten de un retraso tan largo al iniciar sesión).
4. Los usuarios pueden elegir contraseñas simples, solo se están haciendo daño a sí mismos. Si quisiera eliminar este riesgo, haría que el servidor generara el hash la primera vez, siempre y cuando la contraseña pase por un canal cifrado.
5. Sí, y también necesitarás untar estos. En el caso de un compromiso de la base de datos, debe asegurarse de que el atacante no obtenga información que le permita autentificarse directamente como cualquier usuario en su sistema. Una advertencia aquí es que no desea que su hash del lado del servidor sea computacionalmente intensivo como lo es el hash del lado del cliente. Si su hash del lado del servidor requiere demasiado esfuerzo, se abre a un vector de ataque de Denegación de Servicio que agota la CPU: un atacante simplemente envía por correo basura los intentos de autenticación de contraseñas vacías en Tor, las contraseñas que su servidor debe probar antes de que sepa que son. fraudulento, finalmente te deja con un servidor abrumado ..

Si hash la contraseña en el lado del cliente, cualquiera que sea el resultado ES la contraseña, no obtendrás ninguna seguridad real. Cualquier hack o pérdida de información que hubiera revelado la contraseña de texto sin formato revelará la contraseña con hash, que es la contraseña real.

Esto no debe confundirse con esquemas de autenticación de conocimiento cero, donde un intercambio de mensajes prueba que el cliente conoce la contraseña real, sin transmitirla realmente.

Parece que estás intentando inventar tu propio protocolo criptográfico. A partir de la descripción de su enfoque, no parece que tenga los antecedentes para hacerlo de manera segura. Recomiendo usar los protocolos existentes en lugar de crear los suyos.

Primero, no está claro qué modelo de amenaza crees que estás burlando. Cita algo llamado "ataque de ingeniería inversa" que no tiene una definición o significado real.

Segundo, su comprensión del propósito de una sal y las mejores prácticas para su generación parecen faltar. No se requiere que las sales se mantengan en secreto. Puede (y debe) generar un salt único de un CSPRNG para cada nuevo token de autenticación, y no de algo como una dirección de correo electrónico (que podría cambiar). Las sales fijas para aplicaciones específicas a veces se llaman "pimientos", y no conozco ninguna literatura criptográfica que respalde o aliente su uso.

Tercero, PBKDF2 está bien, pero en serio solo use BCrypt . BCrypt fue diseñado para esto y está en uso generalizado. Las buenas implementaciones de BCrypt manejarán la generación de sal y la calibración / autodetección del factor de trabajo para usted. Deberá implementar estas cosas usted mismo para usar PBKDF2, y casi inevitablemente cometerá errores.

En cuarto lugar, existe un enfoque existente de lo que parece estar intentando hacer. La autenticación de conocimiento cero se puede realizar con SRP . La contraseña del usuario nunca se transmite a través del cable, y un hombre en el medio no puede oler nada útil para autenticarse. Sin embargo, aparentemente es difícil de implementar correctamente y no hay muchas bibliotecas existentes para hacerlo, lo que debería darle una idea de lo difícil que es realmente el problema.

Larga historia corta: no inventes tu propio cripto. Utilice soluciones y protocolos que están ampliamente implementados y han resistido la prueba del tiempo.

Hashing en el cliente puede ser una buena idea en algunas circunstancias y por algunas razones, pero no haría que la "tranquilidad del usuario" sea una de ellas. Estoy totalmente de acuerdo para que los usuarios tengan una mentalidad armoniosa y estén en armonía con el Universo, pero me parece dudosa la idea de promover una forma de inducir a los usuarios a reutilizar la misma contraseña en varios sitios.

Un buen caso para el hashing del lado del cliente es la forma en que funcionan algunas "cajas fuertes de contraseñas": calculan una contraseña específica del sitio al incluir la "contraseña maestra" del usuario junto con el nombre del sitio. Esto brinda la mayor parte de la facilidad de uso de usar siempre la misma contraseña en todas partes, mientras que en realidad no le da su contraseña maestra a docenas de sitios distintos. Pero esto funciona solo mientras el algoritmo de derivación de contraseñas sea genérico y no cambie; esto parece estar mucho mejor abordado por una extensión del navegador web que por un applet proveniente de los sitios (todos los sitios tendrían que cooperar para usar applets que usen el mismo algoritmo de derivación de contraseña, con datos específicos del sitio). / p>

Otro buen caso para el hash de contraseñas en el lado del cliente es cuando se usa un hash lento (para hacer que el descifrado de contraseñas sea más difícil para un atacante que pueda tomar una copia de la base de datos de contraseñas con hash); es tentador tratar de descargar el costo en el cliente, ya que, cuando el cliente desea conectarse, está casi siempre inactivo e interesado activamente en conectarse. Sin embargo, el hashing lento es una carrera de armamentos entre el atacante y el defensor. El uso de Java inducirá una desaceleración (por un factor típico de 3), y algunos sistemas cliente pueden ser bastante débiles (por ejemplo, teléfonos inteligentes baratos o computadoras de diez años). Esto es como levantar una espada en lugar de un rifle de asalto antes de entrar en una batalla donde el oponente traerá un tanque).

Pero si lo que desea, como usuario, es proteger su contraseña contra los procedimientos de almacenamiento descuidados de un sitio, entonces la forma correcta de hacerlo es para elegir una contraseña diferente para cada sitio . (Personalmente, guardo un archivo de contraseñas y todas mis contraseñas se generan de forma aleatoria).

Un empleado de Google está trabajando en algo similar llamado TLS-OBC. Este borrador de RFC permite al cliente codificar la contraseña y vincularla a una sesión TLS.

Específicamente puede estar interesado en este sitio web enlace

y este enlace en Autenticación de usuario fuerte enlace

:: Actualizar

OBC y posiblemente el otro ahora está integrado en el estándar de autenticación FIDO.