Supongamos que debe elegir uno solo entre los siguientes tipos de autenticación para su propio servidor SMTP:
¿Cuál recomendaría para una seguridad óptima?
PS: La lista son los tipos de autenticación dados en man swaks
Con SSL / TLS está bien usar LOGIN / PLAIN .
Debería proporcionar SMTP sobre una conexión cifrada con SSL. Si bien algunos esquemas de su lista (por ejemplo, DIGEST-MD5 ) pueden mantener una contraseña segura incluso en un canal que no es de confianza, no protegerán a los usuarios de un atacante de hombre en el medio que manipule su sesión. (Normalmente, los servidores de correo electrónico envuelven SMTP a través de TLS directo o una actualización de la conexión con STARTTLS en los puertos 465/587 .)
Cualquier tipo de autenticación SMTP, independientemente de si utiliza PLAIN o un método avanzado, simplemente proporciona autenticación de nivel de aplicación. Pero lo que desea es seguridad de nivel de transporte . Después de que un usuario se autentique a través de SMTP, no habrá una conexión encriptada automáticamente. De acuerdo con el protocolo SMTP, los comandos y los correos electrónicos se intercambian con el servidor en texto sin formato, lo que permite a un atacante de personas intermedias leer y modificar la comunicación e inyectar nuevos comandos. Es por eso que debe proporcionarlo además del cifrado SSL, al igual que HTTPS proporciona HTTP sobre SSL.
La analogía de HTTP: si protege su sitio web con HTTPS, entonces no importa que el formulario de inicio de sesión realmente transmita su contraseña como una cadena simple en el cuerpo de POST de la solicitud HTTP, porque el transporte de datos es SSL. cifrado Habilitar CRAM-MD5 para SMTP es análogo a implementar un esquema challenge-response en Javascript antes de transmitir el inicio de sesión credenciales a un sitio web. (Ocasionalmente puede ver esa técnica en las interfaces de enrutadores que no proporcionan HTTPS pero no es muy común).
En cuanto a un ejemplo de la vida real, GMail está bien con la oferta de autenticación LOGIN / PLAIN (donde las credenciales se envían en el texto del plan) después de haber establecido una conexión SSL segura:
$ openssl s_client -starttls smtp -connect smtp.gmail.com:587 ... 250 SMTPUTF8 EHLO foo 250-smtp.gmail.com at your service, [127.0.0.1] 250-SIZE 35882577 250-8BITMIME 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH 250-ENHANCEDSTATUSCODES 250-PIPELINING ...
(Como puede ver, también proporcionan algunos métodos que no incluyó en la lista, por ejemplo, XOAUTH2 para tokens OAuth2, que podrían ser interesantes si busca autenticación sin contraseña).
Lo que yo llamo una buena autenticación es una que tiene las siguientes propiedades:
el servidor nunca tiene que saber la contraseña real, solo mantiene un hash de ella
Esto garantiza que, incluso si la base de datos de contraseñas se ve comprometida, el atacante solo tendrá dificultades para invertir hashes, y los usuarios tendrán tiempo suficiente para cambiar sus contraseñas
la contraseña nunca se intercambia en texto claro
Lo que se intercambia se puede espiar con demasiada facilidad, y una contraseña que pase un texto sin cifrar a través de un canal no cifrado debería verse comprometida
Siempre que el servidor SMTP permita TLS, PLAIN respeta ambos con el siguiente escenario: HELO, STARTTLS, LOGIN
Además de las mejores recomendaciones para SMTP, aquí está su lista disponible: