¿Por qué no usamos nuestro teléfono móvil a través de una contraseña y luego ingresamos la contraseña en un sitio web como contraseña?
De esta manera, la contraseña para el sitio web sería mucho más compleja.
¿Esto incluso aumentaría la seguridad?
Ejemplo
Esto es esencialmente idéntico a la simple generación de una contraseña que no esté hash, en términos de seguridad. No importa si usa su nombre para una contraseña o la suma de comprobación de la hora actual; Si lo que envías a través de Internet se compara con una cadena almacenada directamente en una lista en el lado del servidor, entonces la contraseña no se oculta de forma útil.
El punto de almacenar contraseñas usando un hash en el lado del servidor (incluso si el "servidor" es local) es que un buen algoritmo de hashing es de una sola vía. Por lo tanto, si la lista es robada, alguien que la tenga no podrá obtener las contraseñas directamente. La autenticación contra una contraseña con hash requiere que se aplique un proceso a la cadena proporcionada y que los resultados sean los mismos. Por lo tanto, un conjunto robado de hashes solo proporciona el resultado de ese procedimiento, no los valores reales que otorgarían la autenticación.
Si el hashing se realiza en el lado del cliente, sin embargo, la lista en el lado del servidor son los valores reales utilizados para la autenticación. Lo que significa que no se necesita trabajo adicional para usar esos valores para iniciar sesión en la aplicación como cualquier usuario una vez que se revela la lista.
Supongo que depende de lo que haga el servidor, pero no agrega mucha protección (o es peor). (Además, ¿el usuario promedio sabe cómo calcular un hash en el móvil? Me suena bastante complicado).
Esto significa que el cliente envía H = hash(password) al servidor, el servidor busca a los clientes con la contraseña hash H' en la base de datos y valida al cliente marcando H == H' . Esto es realmente malo. Ahora, si ocurre una violación de la base de datos, el atacante puede ingresar la contraseña con hash que se almacenó en la base de datos para iniciar sesión. Básicamente, elimina el punto de hash en primer lugar y es como si se almacenara la contraseña de texto sin formato.
Esto significa que el cliente envía H = hash(password) al servidor, el servidor busca el hash de los clientes con la contraseña hash H' en la base de datos y valida al cliente al verificar H' == hash(H) . Ahora, si ocurre una brecha en la base de datos, el atacante debe verificar si hash(hash(guess)) == recovered_hash , por lo que el costo para el atacante es aproximadamente 2 veces lo que sería sin el hashing del lado del cliente (es decir, el atacante puede verificar las contraseñas un 50% más lento, lo que no es mucho una victoria). La seguridad en este caso aún depende de que hash sea una función (no invertible) resistente a los ataques de diccionario, el hashing del lado del cliente hace poco para ayudar.
Resumiendo, lo mejor que puede hacer es hacer que el cliente ingrese la contraseña en texto simple, transmitir la contraseña al servidor a través de HTTPS y hash la contraseña en el servidor con algo como bcrypt o scrypt, almacenando solo el hash en el servidor. servidor. La razón por la que su construcción no es una mejora es que la "semilla" si no obtiene ninguna entropía y es tan fácil (o no fácil) de adivinar, simplemente está agregando una etapa intermedia.
¿Esto aumentaría la seguridad? No. Cualquier aplicación moderna ya almacena sus contraseñas en la base de datos. Cada vez que se realiza un intento de autenticación, la entrada del usuario se revisa y se compara con lo que haya en la base de datos. En su mayoría, esto sucede con un cifrado de 1 vía (el hash no se puede descifrar a su valor original).
Cuando crearías un hash en un teléfono móvil, hay 3 problemas:
No veo ningún beneficio de seguridad importante al hacer esto. Por supuesto, podría usar un teléfono móvil en un proceso de autenticación de dos factores para aumentar la seguridad de las cuentas de usuario.
Lea otras preguntas en las etiquetas passwords authentication hash