Idea para un algoritmo para autenticar usuarios con prueba de conocimiento cero [necesita pensamientos / revisión]

0

Tengo una idea para un algoritmo. No sé si cometí algún error y necesito algunos pensamientos adicionales / revisión por pares sobre ello.

Esto funcionaría como una prueba de conocimiento (casi) cero para enviar contraseñas que se pueden implementar fácilmente.

registration:

Un usuario envía su contraseña al servidor (riesgo de una sola vez).

El servidor calcula un hash "seguro" de dicha contraseña. Este hash tiene que ser muy largo, digamos 4k caracteres.

login:

Cuando un usuario desea iniciar sesión, primero calcula dicho hash en su máquina local. Luego, el servidor le dice al cliente que una las letras aleatorias a una nueva contraseña única. El servidor solo envía las posiciones de las letras y las envía al azar, de modo que haya suficientes permutaciones para no quedarse sin combinaciones. Tiene que haber un historial de cartas ya usadas, para que al menos una carta nunca expuesta se use. De lo contrario, un MITM podría simular un cliente.

Después de unir todas las letras a una nueva contraseña, dicha contraseña se "revisa" de forma segura y se envía al servidor para su verificación. el servidor realiza las mismas tareas que el cliente y compara su versión con los datos de los clientes.

Incluso si el envío de contraseñas de un solo uso está "seguro", el atacante tiene tiempo. Entonces, después de que se revela la mitad de la contraseña original con hash, se incrementa el contador, y dicha contraseña se hasheado una vez en el lado del servidor y se descartan las contraseñas de hash antiguas. Este contador se envía al cliente cada vez que quiere iniciar sesión, por lo que aumenta las vueltas de hash por el contador para que coincida con los datos del servidor.

Esta es una idea que se me ocurrió hace unos segundos. Parece ser un buen enfoque. Pero me gustaría ver sus pensamientos sobre esto, ¿dónde está la falla? ¿O ya se ha utilizado algo similar?

    
pregunta Kostronor 12.09.2014 - 21:15
fuente

1 respuesta

2

Así es como lo entiendo, corríjame si he interpretado mal algo.

Enviando contraseña en claro

Un riesgo de una sola vez nunca vale la pena cuando se puede evitar. El uso de un algoritmo seguro como bcrypt o PBKDF2 con un salt no requiere que la contraseña se envíe de forma clara. Incluso si la contraseña se envía bajo TLS, ¿debo confiar en que no mantendrá mi contraseña para usted?

Esta respuesta proporciona un mecanismo completamente seguro para la autenticación de inicio de sesión sin enviar una contraseña de forma clara.

Overhead

Hay una gran cantidad de sobrecarga que un atacante puede ver a través del cable.

  

Cuando un usuario desea iniciar sesión, primero calcula dicho hash en su local   máquina. Luego, el servidor le dice al cliente que une letras al azar a un   nueva contraseña de una vez. El servidor solo envía las posiciones de las letras y   Los envía al azar, de modo que hay suficientes permutaciones para   Nunca te quedes sin combinaciones. Tiene que haber una historia de ya   Utiliza letras, para que al menos una letra nunca expuesta se use.   De lo contrario, un MITM podría simular un cliente.

¿Qué está sucediendo exactamente aquí? ¿Estás uniendo letras al azar al hash de la contraseña? Estás enviando las cartas en el claro, entonces, ¿por qué exactamente no puede alguien estar en el medio? Entiendo que solo ha intercambiado un secreto una vez, pero ese secreto se almacena tanto en el cliente como en el servidor. Dos vectores de ataque separados. Si está concatenando las letras hasta el final del hash, todo lo que necesito es el hash y puedo iniciar sesión con el servidor.

Si está creando una contraseña completamente nueva a partir de las cartas enviadas por el servidor, ¿en qué momento verifica que la contraseña original era correcta? De lo contrario, me puedo conectar al servidor y el servidor me proporciona una nueva contraseña.

  

Incluso si el envío de contraseñas de un solo uso está "seguro", el atacante   tiene tiempo.

No estoy realmente seguro de a qué te refieres.

  

Este contador se envía al cliente cada vez que él quiere iniciar sesión, por lo que   aumenta las vueltas de hash por el contador para que coincida con los datos del servidor.

Nuevamente, estás proporcionando alguna otra característica por el cable, si un atacante puede verla, entonces es reproducible. No creo que esto agregue nada a la seguridad, ya que cualquier algoritmo de hash seguro ejecutará suficientes iteraciones por sí mismo.

Requisito de contraseña innecesariamente largo

No hay razón para una contraseña de 4000 caracteres. Para un algoritmo seguro, esto afectará el rendimiento de su servidor. El aseguramiento del algoritmo de hashing se repite 20,000 veces en toda la contraseña. Una cadena de 16 caracteres es el mínimo necesario para una contraseña segura. 4000 caracteres es una exageración.

Hecho antes (tipo de)

Parece que los caracteres aleatorios proporcionados por el servidor actúan como un sal aleatorio. Sin embargo, dado que están restringidos a letras, no serán tan efectivos.

Echa un vistazo a Hash de contraseña con sal: hazlo bien

    
respondido por el RoraΖ 15.09.2014 - 14:17
fuente

Lea otras preguntas en las etiquetas