¿Qué tan seguro es el uso de CRAM-MD5 para la autenticación de correo electrónico cuando no se usa una conexión SSL?

CRAM-MD5 requiere que el servidor conozca la contraseña real, no solo una imagen de la contraseña mediante una función hash. Entonces, si el servidor tiene que soportar HMAC-MD5, tiene que almacenar la contraseña en texto sin formato. (El servidor puede cifrar la contraseña, pero como también tiene que conocer la clave de cifrado, eso no ayuda).

CRAM-MD5 fue diseñado para evitar que la contraseña pase a texto claro. Da cierta cantidad de protección contra un atacante pasivo. Si el atacante puede escuchar la comunicación pero no inyectar mensajes, todo lo que recibe es un desafío C y el valor HMAC-MD5 (P, C) donde P es la contraseña. No hay un método mejor para encontrar la contraseña de esta información por fuerza bruta. Sin embargo, la fuerza bruta es una preocupación con las contraseñas: al menos una función lenta , y la exposición del hash se debe evitar de todos modos y se debe tratar como un compromiso.

En lugar de una contraseña memorable elegida por el hombre, la "contraseña" (más precisamente un secreto compartido) almacenada en el servidor podría ser un hash lento de la contraseña humana, como anotado por Adnan . Esto evitaría los ataques de fuerza bruta del hash MD5, por lo que proporcionaría una mejor seguridad contra los atacantes pasivos. (Sin embargo, cualquiera que haga esto está usando herramientas no estándar, y es presumiblemente lo suficientemente serio acerca de la seguridad para usar SSL). CRAM-MD5 solo autentica el paso de autenticación y no el resto de la sesión. Por lo tanto, un atacante activo que puede suplantar al cliente puede permitir que se realice la autenticación, luego cortar el cliente (o enviarle datos modificados) y enviar sus propios comandos en la sesión. Específicamente, el atacante debe poder recibir paquetes TCP destinados al cliente. Alternativamente, el atacante tiene que poder recibir paquetes TCP destinados al servidor, o enviar respuestas DNS falsas que hagan que el cliente hable con el atacante en lugar del servidor; un atacante de este tipo actúa como un relé entre el cliente y el servidor durante la fase de autenticación, y luego puede seguir hablando con el servidor. Ninguno de estos ataques implica un compromiso de la contraseña, por cierto, excepto a través de la fuerza bruta como se indica arriba.

El uso de CRAM-MD5 sobre SSL resolvería este problema de autenticación. SSL proporciona una sesión segura (es decir, los participantes no pueden cambiar durante la sesión) y autentica el servidor para el cliente (asumiendo que el usuario no aceptará ciegamente un certificado no válido). CRAM-MD5 trae la tercera parte del problema de autenticación: autenticar el cliente con el servidor.

CRAM-MD5 sobre SSL está bien si la contraseña es una cadena suficientemente larga generada aleatoriamente, lo suficientemente larga para resistir la fuerza bruta. Si la contraseña es generada aleatoriamente, no hay razón para no almacenarla en texto plano en el servidor, es solo una clave. CRAM-MD5 es malo si la contraseña es una que un humano puede recordar, porque la mayoría de las contraseñas humanas se pueden descifrar mediante fuerza bruta y son valiosas más allá de ese servidor, ya que a menudo se reutilizan.

Si usa SSL, hay poco valor en usar CRAM-MD5 en lugar de que el cliente envíe la contraseña a través de la conexión SSL. Hay una pequeña ventaja en que si el cliente envía la contraseña a un imitador del servidor inadvertidamente, la contraseña en sí no se compromete de inmediato (solo si está descifrada), aunque tenga en cuenta que un imitador del servidor puede enviar un desafío constante y, por lo tanto, construir una tabla (arco iris o otro) de valores HMAC-MD5 sobre contraseñas plausibles). Cuando la contraseña es una cadena aleatoria, esto puede ser una ventaja (el atacante no puede usar el valor enviado por el cliente para hacerse pasar por él a menos que el servidor envíe el mismo desafío que el atacante, lo que no debería ocurrir). Donde la contraseña es humana, no hay tal ventaja (ya que la contraseña puede ser descifrada de todos modos) y tener que almacenar la contraseña en texto plano es una desventaja definitiva.

Hay tres puntos débiles relevantes en este caso:

• Almacenamiento de contraseña incorrecto: si la base de datos de su proveedor está comprometida, su contraseña está directamente expuesta. Aunque algunas implementaciones de CRAM-MD5 no almacenan contraseñas en texto plano, la contraseña con hash todavía no tiene sal. Hasta ahora, no hay una implementación conocida que elimine la contraseña (el cliente también debe conocer la sal).

• Los datos reales viajan en texto simple: Al no usar SSL, sus correos electrónicos están totalmente expuestos a MiTM .

• Ataque sin conexión: una vez que el atacante adquiere la información utilizada para la autenticación (el desafío enviado por el servidor, la respuesta enviada por el cliente), es capaz de forzar la contraseña fuera de línea.

• Ataque de texto sin formato elegido: Como el atacante puede hacerse pasar por el servidor, también puede enviar los valores de desafío que desea y observar la respuesta del cliente. Esto hace que sea más fácil conocer la contraseña.

Fíjate, ninguno de estos ataques está relacionado con vulnerabilidades en el propio MD5.

En conclusión: CRAM-MD5 no es seguro para este propósito en absoluto. Su proveedor no tiene excusa para almacenar contraseñas en texto plano, el problema aquí es simplemente su renuencia a implementar una mejor solución.

No proporciona protección contra MITM ya que un atacante podría enviar el desafío al cliente. Requerir el almacenamiento de contraseñas de texto simple es malo y el intercambio puede tener un ataque de diccionario ejecutado contra él.

Tiene justificación para preocuparse por este esquema y personalmente sugeriría usar un proveedor de correo electrónico diferente.

En primer lugar, no es necesario usar texto plano:

Mirando la Implementación HMAC-MD5 en psuedocode :

al menos puede almacenar una versión modificada de la contraseña:

    if (length(key) > blocksize) then
        key = hash(key) // keys longer than blocksize are shortened
    end if
    if (length(key) < blocksize) then
        key = key ∥ [0x00 * (blocksize - length(key))] // keys shorter than blocksize are zero-padded ('∥' is concatenation) 
    end if

    o_key_pad = [0x5c * blocksize] ⊕ key // Where blocksize is that of the underlying hash function
    i_key_pad = [0x36 * blocksize] ⊕ key // Where ⊕ is exclusive or (XOR)

Almacene las dos claves XOR'd, hay una mayor seguridad en el hecho de que si su sistema está comprometido, las cuentas de un usuario en otro lugar que usen la misma contraseña no se verán comprometidas. Al parecer, Dovecot hace esto.

MD5 en sí mismo es bastante fácil de fuerza bruta. Un atacante de MITM podría forzar la contraseña de forma bruta, ya que él / ella ya conoce el desafío.

Hoy en día, la solución a casi todos estos problemas es simplemente usar SSL.

En primer lugar, el bit de texto sin formato es una tontería: la mayoría de las soluciones POP / SMTP * nix pueden actualizarse para que no sea necesario. Con esto fuera del camino ...

... CRAM-MD5 tiene vulnerabilidades impactantes, provenientes de su enlace MD5. Sin embargo, todavía es mejor que el texto plano. En orden de aparición y "OMGWTFBBQ-ness":

1. Un servidor que usa CRAM-MD5 puede ser falsificado / MitM-ed, ya que el cliente nunca verifica la autenticidad del servidor
2. Las contraseñas son craqueables sin conexión (lo que debería ser obvio)
3. Se aplican todas las vulnerabilidades de MD5

CRAM-MD5 es efectivamente MD5( (key XOR padding) concat MD5(key XOR morepadding) concat value) junto con desafío-respuestas. La clave es la contraseña del usuario, el valor es el desafío. Entonces, si el desafío es desconocido, sería perfecto. Lamentablemente, no lo es, ya que se transmite en texto sin formato.

Básicamente, evita si puedes. Las GPU pueden calcular un número alarmante de hashes MD5 en estos días. Sin embargo, una solución simple es solo SSL. Un certificado vale los cacahuetes en estos días.