Esquema de autenticación de hash doble

No importa cuál sea la contraseña porque, en efecto, H1 se trata como la contraseña, es decir, un atacante no necesita conocer la contraseña original, pero H1 es suficiente. Pero este paso al menos garantiza que el servidor no vea la contraseña original (¿débil?) Sino una contraseña derivada (fuerte) y que las mismas contraseñas se almacenen en el servidor con H1 diferente (si S1 es diferente), lo que hace que la fuerza bruta contraseña original más difícil.

La forma de llegar de H1 a H2 usando S2 es similar a Autenticación Digest en que no es la contraseña (o la contraseña equivalente, es decir, H1) se transfiere, pero un hash de la contraseña (o equivalente) y un servidor que se proporciona de forma aleatoria. Se aplican las mismas ventajas y desventajas: protege contra el olfateo (bueno) pero la contraseña o equivalente (H1) debe almacenarse de forma sencilla en el servidor. El último es malo ya que alguien que ataca el servidor podría obtener acceso a H1 y usarlo directamente para autenticarse como el usuario original. Contrariamente a esto, la forma habitual de almacenar contraseñas con hash necesita que el atacante encuentre la contraseña original que da como resultado el hash almacenado.

El último paso con el envío de una C aleatoria sin más protección, ya que el token de autenticación del servidor al cliente anula de manera efectiva toda la protección contra el rastreo que tenía hasta ahora, ya que es suficiente para que el atacante pueda olfatear este token aleatorio para secuestrar la sesión.

Mi sugerencia no es reinventar la seguridad, sino usar tecnologías bien establecidas y analizadas como TLS para transferir contraseñas simples y luego almacenarlas de manera segura mediante el uso de función hash adecuada .

  

No estoy usando TLS porque es para un videojuego; Estoy tratando de minimizar la latencia tanto como sea posible.

Dudo que usted autentique al usuario una y otra vez y que un pequeño retraso en la autenticación de la contraseña inicial sea un problema. Pero debe proteger el token de autenticación C contra el rastreo o la reutilización, lo que actualmente no hace. Una forma sería nunca reutilizar el token, sino que tenga un algoritmo que cree uno nuevo todo el tiempo desde un secreto compartido o use el secreto compartido en un HMAC sobre la carga útil.

  

Cuando se establece una contraseña, esta se revisa inmediatamente con un sal S1 aleatorio y se almacena como H1.

Hashed en el lado del cliente? De lo contrario, la contraseña debe enviarse al menos una vez en texto sin cifrar.

  

El punto aquí es garantizar que la contraseña nunca se envíe en texto claro; se supone que el canal de comunicación entre el usuario y el servidor es "razonablemente" seguro,

¿Por qué no usar tráfico cifrado, como TLS?

Un aspecto agradable de / siempre / hacer hashing en el lado del servidor es que nunca tendrá un ataque de tiempo. La comparación ingenua de la contraseña almacenada en el servidor con la que proviene de la red revelará la contraseña a través del tiempo que demora la autenticación (después de varias fallas).

El hash no es la única forma de evitar un ataque de tiempo, por supuesto, puede usar una función de comparación de tiempo constante. Pero como guía, es mucho más seguro recomendar hash en el servidor también.