¿Por qué no se usan las contraseñas de un solo uso que utilizan la cadena de hash anidada?

El método que describe es un algoritmo clásico para contraseñas de un solo uso, pero tiene algunos inconvenientes:

• Solo es válido para las contraseñas de N , donde se debe elegir N en el momento de la inicialización.
• El cliente debe invocar la función hash R veces, donde R es el número de contraseñas restantes en la cadena, es decir, inicialmente R = N . Esto limita el tamaño de N , de lo contrario, el costo se vuelve insoportable para el sistema cliente.
• El servidor debe conservar algún estado, que es la última contraseña correcta o un contador. El contador tiene el problema de que el costo en el servidor es proporcional al número de contraseña utilizada: si el usuario ha usado 1000 contraseñas, entonces el servidor debe invocar la función hash 1000 veces para validar la siguiente contraseña. Por otro lado, guardar la última contraseña funciona solo si la última contraseña es la salida de hash completa , no un subconjunto derivado, lo que hace que las contraseñas de una sola vez sean muy voluminosas, sean difíciles de escribir (piense 20 + caracteres aleatorios ...).

Para contraseñas de un solo uso, la práctica común es utilizar HOTP , que utiliza un contador en ambos lados (cliente y servidor) y una única HMAC . También depende de que la función hash subyacente sea segura, pero lo hace de una manera mucho más fácil de usar, evitando los problemas descritos anteriormente.

Resumen: el método que describe no se usa porque se conocen métodos mucho mejores, no es que sean más seguros , sino que provocan una sobrecarga mucho menor en el cliente , el servidor y el usuario humano.

Lo que estás describiendo suena vagamente similar en sus objetivos al esquema de contraseña única, HOTP .

Sin embargo, después de muchos miles de inicios de sesión, mi intento de inicio de sesión bajo su esquema consume más tiempo de CPU que el primer inicio de sesión que intenté. Con HOTP, el tiempo para intentar iniciar sesión es constante.

También es el caso con este esquema que no puedo proteger el secreto en el lado del servidor de la misma manera que puedo hacerlo con una contraseña (es decir, usando un KDF), por lo tanto, una infracción del lado del servidor otorgará acceso a todos los secretos del usuario inmediatamente, lo que le permite al atacante hacerse pasar por todos los usuarios con impunidad.

Cualquier atacante que conduzca a un hombre en el ataque central y encuentre el valor de OTP x_n también puede calcular todos los x_i futuros de modo que i > n simplemente usando F en x_i

Este es un problema importante si es probable que el secreto sea utilizado por múltiples sitios (por ejemplo, si se usan tokens de hardware costosos, o si el usuario tiene que recordar el secreto)

En primer lugar, el sistema es complicado y presenta otros problemas: ¿el usuario debe recordar cuántas veces inició sesión? Si no, ¿quién lo hace? No es su navegador, debería poder iniciar sesión desde cualquier lugar.

En segundo lugar, cualquier forma de cifrado del lado del cliente en las conexiones HTTP es inútil . Un hombre en el medio puede modificar fácilmente el javascript, eliminar la función de hashing y obtener la contraseña de texto sin formato. Casi todos los ataques MITM tienen la capacidad para modificar datos (no solo leerlos), por lo que siempre es una opción.

Al final, si desea que su formulario de inicio de sesión sea más seguro, simplemente use HTTPS. El cifrado del lado del cliente no agrega mucha seguridad (si es que agrega cualquier seguridad a cualquier ) y no vale la pena por los otros problemas que trae.