¿Qué tan segura es la técnica de intercambio de claves anti-MITMA Diffie-Hellman de Samy Kamkar?

Desde un vistazo rápido, esto es razonablemente seguro contra un atacante de red. Sin embargo, requiere que el servidor almacene la contraseña como texto sin formato, lo que no se recomienda. El almacenamiento seguro de contraseñas ha sido discutido en detalle en este sitio.

Un protocolo algo similar es SRP que logra los mismos objetivos que Samy Kamkar sin almacenar una contraseña de texto simple en el servidor. Como beneficio adicional, en realidad es un poco más rápido ya que se necesita un viaje de ida y vuelta menos para iniciar sesión.

Como punto más general, el protocolo SRP ha sido sujeto a un análisis detallado y se cree que es seguro. El protocolo de Samy no ha estado sujeto (por lo que puedo decir) al mismo rigor, por lo que puede haber problemas sutiles. Debe usar el SRP para no roll tu propio criptográfico .

Actualización : otra consideración es que el protocolo de Samy revela un hash de contraseña a un atacante MITM activo, que luego podrían atacar con fuerza bruta. Esta es una gran debilidad, a la que SRP no es vulnerable.

No es exactamente una respuesta directa, pero la sección de comentarios es demasiado limitada, así que ...

Podría ser ciego (una noche sin dormir puede hacer eso por ti) pero ese documento describe una situación en la que no quieres ni necesitas un intercambio de llaves Diffie-Hellman. De hecho, no agrega nada a la seguridad de todo el asunto.

Si ambas partes ya tienen un secreto compartido ( password en este caso), y ese secreto no es conocido por el adversario malicioso (Mallory en este caso), entonces ¿por qué tendría que pasar por todos esos problemas en primer lugar? ? Después de todo, DHKE se utiliza para compartir un secreto a través de un canal inseguro, si ya lo ha hecho, no tiene uso para DHKE *. Simplemente puede derivar una clave simétrica a partir de ese secreto y estar bastante seguro de que nadie puede MITM a menos que obtenga una retención de dicho password . En pseudocódigo, un ejemplo sencillo:

a:
    password = 54321
    kdfParams = [salt, iterations, other] // depends on the KDF, some or all may be random
    secretKey = KDF(password, kdfParams)
    data = ENCRYPT(secretKey, "Hello, Bob!")
    a->b (data, kdfParams)

m:
    b->m<-a (data, kdfParams)
    // Doesn't know the password and have no use for the publically transmitted kdfParams
    // Can derive the secretKey only through brute-force,
    // so choose your KDF and password carefully

b:
    b<-a (data, kdfParams)
    password = 54321
    secretKey = KDF(password, kdfParams)
    data = DECRYPT(secretKey, data) // << "Hello, Bob!"

También funciona al revés.

Por supuesto, si Mallory descubre de alguna manera el password , todo el infierno se desata, pero el documento de referencia tampoco ayuda con eso. Si le preocupa el secreto hacia adelante y hacia atrás, puede usar secretKey para HMAC en la parte pública de DHKE para frustrar cualquier ataque MITM y tener un sessionKey nuevo para el cifrado cada vez.

Para concluir, el 'método' explicado no es una explicación y el autor no entiende para qué se utiliza DHKE o necesito dormir un poco.

* en este ejemplo en particular, CodesInChaos plantea un punto válido sobre la utilidad general de DHKE.