¿Es este un algoritmo de autenticación válido y un mecanismo seguro de intercambio de claves de criptografía y un método de comunicación?

Lo que desea aquí se denomina protocolo de “intercambio de clave autenticada por contraseña” (PAKE). Sin embargo, el protocolo que diste no es un PAKE fuerte. La razón es, como dijo Bill Vanyo, que al haber observado RAND1, RAND2 y MD5 (RAND1, contraseña, RAND2), cualquiera, un espía o simplemente alguien sin una cuenta, puede realizar un ataque de diccionario [editar: fuera de línea] contra la contraseña. Un protocolo de PAKE fuerte como SPEKE o SPAKE2 garantiza que incluso un atacante hombre en el medio no puede hacerlo mejor que adivinar en línea.

Además, el protocolo que proporcionó no protege el nombre de usuario del espionaje. Si bien no conozco ningún protocolo práctico sin certificación que proteja el nombre de usuario del ataque activo + diccionario, al menos es posible hacerlo mejor que enviarlo de forma clara.

UH oh

En un protocolo de enlace de autenticación segura, el servidor no conoce la contraseña del usuario. Simplemente porque si el servidor es pirateado (o un amigo copia sus datos a un USB), las contraseñas deberían estar seguras.

Entonces, lo que suele hacer un servidor es solicitar una versión hash y salada de la contraseña y luego compararla con la versión hash y salada en su base de datos.

Le deseo buena suerte al tratar de implementar eso.

El problema no es solo que los miembros de terceros deben mantenerse fuera, sino también que no se puede confiar en el servidor con el que está hablando. Así que sí.

Gracias por sus útiles respuestas.

Hoy descubrí que mi método es lo que se implementa y se está utilizando en el protocolo de autenticación de cuatro vías WPA2 , el sistema de autenticación WiFi. Aunque hay pequeñas diferencias en los detalles, pero el método y el procedimiento en su conjunto son los mismos.

Esto muestra que el método es en teoría válido y seguro. Puede haber algunas vulnerabilidades en las implementaciones. Pero podemos confiar fácilmente en el método para autenticar tanto al cliente como al servidor utilizando una sola contraseña compartida.

Más información:

• Apretón de manos de cuatro vías en WPA-Personal (WPA-PSK)
• http://etutorials.org/Networking …

Sí, así que … sigues mencionando una “base de datos” en el servidor.

“porque sabemos que tiene la contraseña del usuario”.

Esa no es una forma muy segura de almacenar contraseñas … el servidor sabe cuál es la contraseña del usuario o requiere que la contraseña se almacene o codifique de la misma manera en ambos extremos … sin importar el hash de intercambio que esté utilizando.

De lo contrario, ¿cómo sabe el usuario la contraseña, a menos que el usuario establezca la contraseña en primer lugar?

¿Por qué no envío una clave SSH pública al administrador de mi sistema y digo: aquí, conecte esto?

¿Es válido y / o seguro? No lo sé. A primera vista, parece que podría ser, pero hay mejoras definitivas que se pueden hacer.

La otra pregunta es: ¿por qué usar este sistema en comparación con muchos otros similares? ¿Qué es más seguro sobre esto? ¿Por qué este enfoque específico? ¿Cómo romperías este enfoque si quisieras violar un sistema protegido de esa manera? (Sugerencia, vea mi crítica arriba).

Formalice estos pensamientos, desarrolle el sistema, ejecútelo y póngalo a prueba de forma independiente (dado a quien se le suministre una copia del algoritmo y realice la prueba A / B) … Puede que tengas una buena idea. Tal vez.

A menos que pueda probarlo formalmente, cualquier técnica criptográfica está rota. Nunca debe intentar crear alogoritmos o técnicas criptográficas a menos que sea un experto.

Me he encontrado con muchas personas que pensaron “Oye, podría hacer X, Y y Z y obtener un sistema / algoritmo / sistema criptográfico seguro”

Ellos siempre están equivocados.

El nivel de conocimiento necesario para construir sistemas criptográficos sólidos es extremadamente alto. La gente ni siquiera puede entender correctamente los algoritmos existentes, y mucho menos crear otros nuevos.