Cómo Manejar la Autenticación SMTP

¿Cómo se sentiría si cualquiera pudiera enviar emails desde su servidor de email? ¡Luz verde para los spammers, de ninguna manera! Es por eso que Google y otros proveedores de servicios de email protegen sus servidores del uso no autorizado. Los remitentes necesitan autenticarse y demostrar que tienen una cuenta válida. Si no lo hacen, el servidor rechazará su solicitud. Todo esto es posible con la autenticación SMTP, también conocida como SMTP AUTH.

Por qué no debería usar servidores SMTP sin autenticación

Supongamos que su empresa proporciona una dirección de email para sus empleados. Sin embargo, no hay necesidad de autenticación para conectarse al servidor de email. Entonces, no tienen que ingresar un nombre de usuario y contraseña para enviar un email. ¿Qué peligros podría implicar esto?

El anonimato es lo primero a considerar. Todos los que usan el servidor de email permanecen anónimos ya que no tienen que iniciar sesión con ninguna credencial. Esto no es tan grave. Pero, ¿realmente necesita este tipo de anonimato?

La falsificación de emails es algo que definitivamente debería preocuparle. Sin autenticación SMTP, es posible falsificar el remitente. En el mejor de los casos, alguien usará su servidor de email para enviar emails de ventas no autorizados. En el peor, el falsificador puede solicitar información personal del destinatario y usarla para fines de robo de identidad (phishing).

Entonces, ¿cómo proteger el servidor de la falsificación? Anteriormente, hablamos sobre la autenticación de emails a través de registros SPF, DKIM y DMARC. Hoy, hablamos sobre los mecanismos de autenticación para el servidor.

Qué es SMTP AUTH y cómo funciona

La autenticación SMTP o simplemente SMTP AUTH es la extensión del servicio de ESMTP. Requiere que un remitente de email (cliente) tenga permiso para usar el servidor de email. Entonces, solo los usuarios autorizados podrán enviar mensajes salientes.

La autenticación se lleva a cabo según el mecanismo SASL. Por lo general, los servidores usan los tres mecanismos más comunes: PLAIN, LOGIN y CRAM-MD5. También hay otras opciones de las que hablaremos más adelante. Ahora, echemos un vistazo a la autenticación en acción.

Después del handshake SMTP, el cliente envía el comando `EHLO` al servidor. La respuesta es el código `250`. Por lo general, se adjunta con información adicional, incluidos los mecanismos SASL compatibles. Así es como se ve la sesión SMTP:

S: 220 smtp.mailtrap.io SMTP ready
C: EHLO client.railsware.com
S: 250-smtp.mailtrap.io Hello client.railsware.com
S: 250 AUTH LOGIN PLAIN CRAM-MD5

Como ejemplo, usaremos Email Sandbox de Mailtrap ya que responde positivamente a la mayoría de los comandos de los clientes, y no tendremos que preocuparnos por problemas de configuración. Además, nuestro Email Sandbox evita que los emails de prueba lleguen a los destinatarios y sean spammeados.

Intentemos autenticarnos a través del mecanismo SASL LOGIN. Para esto, el cliente envía el comando AUTH LOGIN. El servidor responde con un código 334 y solicita un nombre de usuario. Una vez que el cliente lo proporciona, el servidor sigue con la solicitud de la contraseña. Finalmente, el servidor responde con 235 - Authentication successful.

S: 250 AUTH LOGIN PLAIN CRAM-MD5
C: AUTH LOGIN
S: 334 DYT3jf4sdDR5
C: TXktVXNlcm5hbWU=
S: 334 LIRdf2pekwW3
C: TXktUGFzc3dvcmQ=
S: 235 Authentication successful (autenticación exitosa)

DYT3jf4sdDR5 y LIRdf2pekwW3 por el servidor son los textos codificados en BASE64 para “Username” y “Password” (usuario y contraseña), respectivamente. TXktVXNlcm5hbWU= y TXktUGFzc3dvcmQ= son las respuestas del cliente que también están codificadas en BASE64.

ESMTP reemplazó a POP-before-SMTP

Hoy en día, todos los servidores de email utilizan la autenticación ESMTP a través de mecanismos SASL. Este tipo de autenticación SMTP AUTH reemplazó la autenticación obsoleta POP-before-SMTP. Sin embargo, esta última aún se puede encontrar en algunos servidores antiguos. La idea es autenticar al usuario en el servicio POP3 del mismo servidor y luego conectarlo de nuevo al SMTP. Si necesita saber cómo se diferencia POP3 de SMTP, consulte nuestro artículo detallado IMAP vs. POP3 vs. SMTP.

Este método de autenticación no es muy seguro. Diferentes clientes pueden compartir la misma dirección IP y autenticarse como un solo usuario. Además, el servidor ejecuta ambos servicios POP3 y SMTP en el mismo sistema. La autenticación ESMTP tiene una ventaja ya que implementa mecanismos SASL.

Mecanismos de autenticación SASL

Los mecanismos de autenticación SMTP permiten al servidor verificar si el cliente SMTP está autorizado. Se diferencian en el nivel de seguridad. Por lo general, el servidor enumera los mecanismos SASL que soporta como respuesta al comando EHLO. La mayoría de los servidores soportan las siguientes opciones:

PLAIN – el servidor solicita al cliente que se autorice utilizando el nombre de usuario y la contraseña. Estas credenciales se transmiten como una cadena codificada en Base64.

S: 250 AUTH LOGIN PLAIN CRAM-MD5
C: AUTH PLAIN
S: 334
C: vHRjyADROPsdSDIROu=
S: 235 Authentication successful

Alternativamente, el cliente puede enviar las credenciales junto con el comando AUTH PLAIN en una sola línea:

S: 250 AUTH LOGIN PLAIN CRAM-MD5
C: AUTH PLAIN vHRjyADROPsdSDIROu=
S: 235 Authentication successful

LOGIN – el servidor solicita al cliente que se autorice utilizando el nombre de usuario y la contraseña. La diferencia con PLAIN es que las credenciales codificadas en Base64 se transmiten una por una: nombre de usuario y contraseña.

S: 250 AUTH LOGIN PLAIN CRAM-MD5
C: AUTH LOGIN
S: 334 DYT3jf4sdDR5
C: TXktVXNlcm5hbWU=
S: 334 LIRdf2pekwW3
C: TXktUGFzc3dvcmQ=
S: 235 Authentication successful

CRAM-MD5 – el servidor solicita al cliente que resuelva un desafío computacional utilizando la contraseña. La respuesta del cliente es una cadena que contiene un nombre de usuario y un resumen de 16 bytes en notación hexadecimal. La cadena está codificada en BASE64.

S: 250 AUTH LOGIN PLAIN CRAM-MD5
C: AUTH CRAM-MD5
S: 334 HSU43fnkj47dskmlSH6dsnjn8ndskjnkjnScdDES=
C: adIBUhb7nsddnKsddsfUN8HkjJNJNsdfJIb4LJNKJ=
S: 235 Authentication successful

CRAM-MD5 proporciona un nivel de seguridad más alto en comparación con los mecanismos de autenticación en texto plano, PLAIN y LOGIN. El protocolo utiliza un principio de desafío-respuesta. El servidor envía una cadena de desafío. El cliente decodifica el desafío del servidor y responde con un cálculo HMAC (Código de Autenticación de Mensajes basado en Hash) utilizando la contraseña como clave secreta. Después de eso, el desafío hash se convierte en una cadena de dígitos hexadecimales en minúsculas. Además, el cliente antepone el nombre de usuario y un carácter de espacio a la cadena. El servidor obtiene esta concatenación codificada en BASE64.

Los falsificadores no pueden:

Decodificar las credenciales ya que no se transfieren realmente por el cliente en texto o en código.
Duplicar el hash porque necesitan conocer la contraseña.
Simular el hash, porque el desafío computacional es mutable y cambia con cada inicio de sesión.

Ahora, descubramos otros mecanismos SASL que se pueden usar en servidores SMTP:

XOAUTH/XOAUTH2 – es un mecanismo de autenticación básico en los servidores de email de Gmail, Live.com y Outlook.com. Se basa en las firmas OAuth para autenticar a los usuarios. XOAUTH2 permite al cliente enviar tokens de acceso OAuth 2.0 al servidor. La respuesta del cliente es una cadena codificada en Base64. El comando AUTH consta de una sola línea de texto.

S: 250-AUTH LOGIN PLAIN XOAUTH XOAUTH2
C: AUTH XOAUTH2 dXNlcj1zb21ldXNlckBleGFtcGxlLmNvbQFhdXRoPUJlY
XJlciB5YTI5LnZGOWRmdDRxbVNSbGNrQJoZG1semRHRXVZMjl0Q2cBAQ==
S: 235 Accepted

NTLM es un mecanismo de autenticación de desafío-respuesta. A menudo se utiliza en el modo de Autenticación Integrada de Windows y en algunos productos de Microsoft como MS Exchange. Una vez que el cliente envía el comando AUTH, el servidor permite la autenticación NTLM. El cliente envía un NEGOTIATE_MESSAGE. El servidor responde con un CHALLENGE_MESSAGE para establecer la identidad del cliente. El cliente envía un AUTHENTICATE_MESSAGE como respuesta al desafío. Todos los mensajes están codificados en Base64.

S: 250-AUTH GSSAPI NTLM
C: AUTH NTLM
S: 334 ntlm supported
C: TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==
S:334 lRMTVNTUAACAAAAFgAWADgAAAA1goriZt7rI6Uq/ccAAAAAAAAAAGwAbABOAAAABQLODgAAAA9FAFgAQwBIAC0AQwBMAEkALQA2ADYAAgAWAEUAWABDAEgALQBDAEwASQAtADYANgABABYARQBYAEMASAAtAEMATABJAC0ANgA2AAQAFgBlAHgAYwBoAC0AYwBsAGkALQA2ADYAAwAWAGUAeABjAGgALQBjAGwAaQAtADYANgAAAAAA
C:TlRMTVNTUAADAAAAGAAYAHwAAAAYABgAlAAAABYAFgBIAAAACAAIAF4AAAAWABYAZgAAABAAEACsAAAANYKI4gUCzg4AAAAPZQB4AGMAaAAtAGMAbABpAC0ANgA2AHQAZQBzAHQARQBYAEMASAAtAEMATABJAC0ANgA2AAZKkK42dvN2AAAAAAAAAAAAAAAAAAAAABvqCZdJZ0NxuuMaNT5PPn5aZ6imuk9cPZkPUjEYNIRezkCGmTwS5G0=
S: 235 Authentication successful

GSSAPI se refiere a la Interfaz de Programa de Aplicaciones de Servicios de Seguridad Genéricos. Por sí mismo, GSSAPI se utiliza casi exclusivamente con Kerberos, un protocolo de autenticación de red. Similar a NTLM, este mecanismo de autenticación se utiliza a menudo en los servidores de Windows de Microsoft. La autenticación GSSAPI o Kerberos se ve así:
- El cliente y el servidor negocian una clave secreta compartida, cifrado y hash para la sesión.
- El servidor proporciona una clave de host.
- El cliente se autentica.

Aquí hay un ejemplo:

S: 250-AUTH GSSAPI PLAIN
C: AUTH GSSAPI
S: 334
C: YIICEQYJKoZIhvcSAQICAQBuggIAMIIB/KADAgEFoQMCAQ6iBwMFACAAAACjggETYYIBDzCCAQugAwIBBaENGwtOQURBLktUSC5TRaIjMCGgAwIBAaEaMBgbBHNtdHAbEHNtdHAubmFkYS5rdGguc2Wjgc8wgcygAwIBEKEDAgEJooG/BIG8msq2xygko4Lv0Agu5pW6SEundUbFK5swuopukvx9kTidWULb/Ab490wQbtnKx3lmM3BFvNFvuUyD3zvh9PHggwz7T7eZYSCDaovIL/QZ0ismF3lZejZBSwBhgLDADQuk4nZHbbeoU9Lk+1jzsMJguNh6Ot3G6o8WLqFZoe8pi3NuxzSdjutjg3O9s/fasuSB9T85bq6oIMWGr5HHRNBNUF4x11tK3ytpsVoMNpKng3d4bY8tLgnxxLCmREakgc8wgcygAwIBEKEDAgEBooG/BIG8SPCDQwKGzJfZGg+MgqQquBiGBXA2uy/08gPE19vuTBP7XyL2H4EaVqtl71MeVxExbat/CNAK
3dMXkNqR6VHxZqb+ky8MYMDo452Z1sN6BfIsKcsy2BcYTwFJMtgdn21vTWVHtMPH3wtXPuPFGn3jigjsXiAyytXi1Y4p4Tni+ox5ndlZuqBJGeThVxyZIpCEI+5rWflxDIYVa/8CAcRUPQqoDpQIs5zkwfoPQtTdfRLdph5VxQ79N9PnvnQ=
S: 334 YGwGCSqGSIb3EgECAgIAb10wW6ADAgEFoQMCAQ+iTzBNoAMCARCiRgRE2FBXYUbT0MVIicgLYE/FKy6CcrvfQxZaoxyt05qqxJBL13kqneza/TKe5i0mjsN0Nc90KW/l4rL0eQ76vWMenaE1Lw8=
S: 334
YD8GCSqGSIb3EgECAgIBBAD/////IGqNk7Rz3+kPdzT9oYPRWnQi/ESL0p3EeQ2yNLWArrmdOzxpBwAgAAQEBAQ=
C: Using system username `jas' as authentication identity.
YD8GCSqGSIb3EgECAgIBBAD/////JhNtx+GhzYe54NY92BltbUHD6i02upmatfXUnIGrBR5vT5yuAQAgAGphcwE=
235 OK Authenticated

La conexión SSL es necesaria para los mecanismos de texto plano. Las credenciales sin cifrar se pueden enviar sin problemas. Todos los mecanismos SASL que no sean de texto plano no requieren cifrado SSL/TLS.

Puertos de escucha de SMTP AUTH

587 – Este es el puerto de autenticación SMTP predeterminado. También se conoce como el puerto de envío de mensajes. El 587 está asociado con los servidores de envío o agentes de envío de email (MSA) e implica el uso de autenticación.
25 – En algunos casos, también se puede usar autenticación SMTP en este puerto. El 25 es conocido como el puerto de retransmisión de mensajes.

Código 535 – Autenticación fallida y otros errores de SMTP AUTH

El servidor SMTP puede responder tanto positiva como negativamente al comando AUTH. Los códigos de respuesta positiva son:

334 – el mecanismo de seguridad solicitado es aceptado.
235 – autenticación exitosa.

La respuesta negativa más frecuente es 535 - Authentication failed. Es probable que pueda solucionar este error si sabe qué lo ha causado.

Credenciales incorrectas – O el nombre de usuario o la contraseña (o ambos) son incorrectos. Por lo general, el nombre de usuario es el mismo que su dirección de email. Y la contraseña es la misma que para tu cuenta de email.

Cuenta deshabilitada – Podría haber diferentes razones para esto, como problemas de spam o atrasos en pagos. La mejor manera de solucionar esto es contactar a su proveedor o administrador del servidor de email.

Se requiere conexión SSL/TLS – Algunos servidores pueden responder con 535 cuando se requiere una conexión cifrada.

La autenticación SMTP no está habilitada – Asegúrese de que tanto su cliente como servidor tengan habilitada la autenticación SMTP.

El mecanismo de autenticación no es compatible – El cliente no soporta ninguno de los mecanismos que el servidor utiliza para la autenticación. En este caso, se recomienda habilitar el mecanismo de autenticación básico en el servidor y usarlo.

Además del 535, puede encontrarse con otros errores con el comando AUTH:

530 – problema de autenticación que generalmente requiere el comando STARTTLS.
538 – se requiere cifrado para el mecanismo de autenticación solicitado.

El código 550 indica que su servidor de email requiere autenticación SMTP. Es principalmente una respuesta al intento de enviar un mensaje. Para mayor información sobre comandos y respuestas SMTP, lea nuestro artículo detallado.

Cómo probar la autenticación SMTP

Hace un tiempo escribimos sobre probar el servidor SMTP con una sesión Telnet manual. Ahora, usemos el cliente Telnet para probar la autenticación SMTP en su servidor de email.

Paso 1: Asegúrese de que el cliente Telnet esté instalado/activado en su sistema operativo. Esto se refiere principalmente a los usuarios de Windows que necesitan realizar algunas manipulaciones para activarlo.

Paso 2: Establezca una conexión TCP (puerto 25) con el servidor SMTP usando telnet smtp.suservidor.com 25. El servidor responderá con 220 smtp.suservidor.com. Esto significa que la sesión SMTP ha comenzado.

Paso 3: Salude al servidor con EHLO smtp.suservidor.com. El servidor le dará la bienvenida y ofrecerá una selección de mecanismos de autenticación. Por ejemplo: 250-AUTH PLAIN LOGIN CRAM-MD5.

Paso 4: Debe autenticar vía LOGIN. Pero antes, asegúrese de codificar sus credenciales en Base64. Puede usar esta herramienta para codificar. Ingrese el comando AUTH LOGIN. Como recuerda, el servidor responderá con 334 seguido del texto codificado en Base64. Primero es la solicitud de nombre de usuario, y luego – contraseña. Responda con sus credenciales codificadas en Base64 respectivamente. Si la autenticación es exitosa, el servidor responderá con 235 OK. La prueba de autenticación SMTP fue pasada.

La autenticación SMTP es lo que puede usar para proteger su servidor de email de la falsificación y el phishing. Al mismo tiempo, hay muchas otras amenazas como malware, ataques DoS, y así sucesivamente. Lea nuestro artículo para aprender cómo hacer que SMTP sea seguro y protegerse contra todas las posibles vulnerabilidades.

Qué es la Autenticación SMTP y Por Qué No Puede Ignorarla