O que é Autenticação SMTP e Por Que Não Pode Ignorá-la

Zakhar Yung

5 meses atrás

Como você se sentiria se qualquer pessoa pudesse enviar emails do seu servidor de email? Um sinal verde para spammers – de jeito nenhum! É por isso que o Google e outros provedores de serviços de email protegem seus servidores contra uso não autorizado. Os remetentes precisam se autenticar e provar que possuem uma conta válida. Se não o fizerem, o servidor rejeitará sua solicitação. Tudo isso é possível com a autenticação SMTP, também conhecida como SMTP AUTH.

Por que você não deve usar servidores SMTP sem autenticação

Vamos supor que sua empresa fornece um endereço de email para seus funcionários. No entanto, não há necessidade de autenticação para se conectar ao servidor de email. Portanto, eles não precisam inserir um nome de usuário e senha para enviar um email. Que riscos isso pode envolver?

Anonimato é a primeira coisa a considerar. Todos que usam o servidor de email permanecem anônimos, pois não precisam fazer login com quaisquer credenciais. Isso não é um grande problema. Mas você realmente precisa desse tipo de anonimato?

Falsificação de email é algo com o que você definitivamente deve se preocupar. Sem autenticação SMTP, é possível falsificar o remetente. No melhor dos casos, alguém usará seu servidor de email para enviar emails de vendas não autorizados. No pior dos casos, o falsificador pode solicitar informações pessoais do destinatário e usá-las para roubo de identidade (phishing).

Então, como você protege o servidor contra falsificação? Anteriormente, escrevemos sobre autenticação de email via SPF, DKIM e DMARC. Hoje, vamos falar sobre os mecanismos de autenticação para o servidor.

O que é SMTP AUTH e como funciona?

A autenticação SMTP, ou simplesmente SMTP AUTH, é a extensão do serviço ESMTP. Ela exige que um remetente de email (cliente) tenha permissão para usar o servidor de email. Portanto, apenas usuários autorizados podem enviar mensagens de saída.

A autenticação é realizada de acordo com o mecanismo SASL. Como regra, os servidores usam os três mecanismos mais comuns: PLAIN, LOGIN e CRAM-MD5. Existem também outras opções sobre as quais falaremos mais tarde. Agora, vamos ver a autenticação em ação.

Após o handshake SMTP, o cliente envia o comando EHLO para o servidor. A resposta é o código 250. Normalmente, ele vem acompanhado de informações adicionais, incluindo mecanismos SASL suportados. Aqui está como a sessão SMTP se parece:

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

Como exemplo, usaremos o Email Sandbox do Mailtrap, pois ele responde positivamente à maioria dos comandos dos clientes e não precisaremos nos preocupar com problemas de configuração. Além disso, nosso Email Sandbox impede que emails de teste cheguem aos destinatários e os spammem.

Vamos tentar autenticar via o mecanismo SASL LOGIN. Para isso, o cliente envia o comando AUTH LOGIN. O servidor responde com um código 334 e solicita um nome de usuário. Assim que o cliente o fornece, o servidor segue com a solicitação de senha. Eventualmente, o servidor responde com 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

DYT3jf4sdDR5 e LIRdf2pekwW3 pelo servidor são os textos codificados em BASE64 para “Username” e “Password”, respectivamente. TXktVXNlcm5hbWU= e TXktUGFzc3dvcmQ= são as respostas do cliente que também são codificadas em BASE64.

ESMTP substituiu POP-before-SMTP

Hoje em dia, todos os servidores de email usam autenticação ESMTP via mecanismos SASL. Esse tipo de SMTP AUTH substituiu a autenticação POP-before-SMTP obsoleta. Esta última, no entanto, ainda pode ser encontrada em alguns servidores antigos. A ideia é autenticar o usuário no serviço POP3 do mesmo servidor e depois conectá-lo de volta ao SMTP. Se você precisar saber como o POP3 difere do SMTP, confira nosso post dedicado no blog IMAP vs. POP3 vs. SMTP.

Esse método de autenticação não é muito seguro. Diferentes clientes podem compartilhar o mesmo endereço IP e autenticar-se como um único usuário. Além disso, o servidor executa os serviços POP3 e SMTP no mesmo sistema. A autenticação ESMTP tem vantagem, pois implementa mecanismos SASL.

Mecanismos de autenticação SASL

Os mecanismos de autenticação SMTP permitem que o servidor verifique se o cliente SMTP está autorizado. Eles diferem no nível de segurança. Como regra, o servidor lista quais mecanismos SASL ele suporta como resposta ao comando EHLO. A maioria dos servidores suporta as seguintes opções:

PLAIN – o servidor solicita que o cliente se autorize usando o nome de usuário e a senha. Essas credenciais são transmitidas como uma única string codificada em Base64.

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

Alternativamente, o cliente pode enviar as credenciais junto com o comando AUTH PLAIN em uma única linha:

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

LOGIN – o servidor solicita que o cliente se autorize usando o nome de usuário e a senha. A diferença do PLAIN é que as credenciais codificadas em Base64 são transmitidas uma a uma – nome de usuário e senha.

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 – o servidor solicita que o cliente resolva um desafio computacional usando a senha. A resposta do cliente é uma string contendo um nome de usuário e um digest de 16 bytes em notação hexadecimal. A string é codificada em BASE64.

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

O CRAM-MD5 oferece um nível de segurança mais alto em comparação com os mecanismos de autenticação de texto simples, PLAIN e LOGIN. O protocolo usa o princípio de desafio-resposta. O servidor envia uma string de desafio. O cliente decodifica o desafio do servidor e responde com um cálculo HMAC (Código de Autenticação de Mensagem com Hash) usando a senha como chave secreta. Depois disso, o desafio com hash é convertido em uma string de dígitos hexadecimais minúsculos. Além disso, o cliente adiciona o nome de usuário e um caractere de espaço à string. O servidor recebe essa concatenação codificada em BASE64.

Os spoofers não podem:

decodificar as credenciais, pois elas não são realmente transferidas pelo cliente em texto ou código
duplicar o hash porque precisam conhecer a senha
simular o hash, porque o desafio computacional é mutável e muda a cada login

Agora, vamos descobrir outros mecanismos SASL que podem ser usados em servidores SMTP:

XOAUTH/XOAUTH2 – é um mecanismo de autenticação básico em servidores de email do Gmail, Live.com e Outlook.com. Ele é baseado em assinaturas OAuth para autenticar usuários. O XOAUTH2 permite que o cliente envie tokens de acesso OAuth 2.0 para o servidor. A resposta do cliente é uma string codificada em Base64. O comando AUTH consiste em uma única linha de texto.

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

NTLM é um mecanismo de autenticação de desafio-resposta. Ele é frequentemente usado no modo de Autenticação Integrada do Windows e em alguns produtos da Microsoft, como o MS Exchange. Uma vez que o cliente envia o comando AUTH, o servidor permite a autenticação NTLM. O cliente envia uma NEGOTIATE_MESSAGE. O servidor responde com uma CHALLENGE_MESSAGE para estabelecer a identidade do cliente. O cliente envia uma AUTHENTICATE_MESSAGE como resposta ao desafio. Todas as mensagens são codificadas em 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 refere-se à Interface de Programa de Aplicação de Serviço de Segurança Genérica. Por si só, o GSSAPI é quase exclusivamente usado com o Kerberos, um protocolo de autenticação de rede. Semelhante ao NTLM, esse mecanismo de autenticação é frequentemente usado nos Servidores Windows da Microsoft. A autenticação GSSAPI ou Kerberos funciona da seguinte forma:
- O cliente e o servidor negociam uma chave secreta compartilhada, cifra e hash para a sessão.
- O servidor fornece uma chave de host.
- O cliente se autentica.

Aqui está um exemplo:

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

A conexão SSL é necessária para mecanismos de texto simples. Credenciais não criptografadas podem ser enviadas sem problemas. Todos os mecanismos SASL não baseados em texto simples não requerem criptografia SSL/TLS.

Portas de escuta SMTP AUTH

587 – Esta é a porta padrão do SMTP AUTH. Ela também é conhecida como porta de submissão de mensagem. 587 está associada a servidores de submissão ou agentes de submissão de email (MSAs) e implica o uso de autenticação.
25 – Em alguns casos, o SMTP AUTH pode ser usado nesta porta também. 25 é conhecida como porta de retransmissão de mensagem.

Código 535 – Falha de autenticação e outros erros SMTP AUTH

O servidor SMTP pode responder tanto positivamente quanto negativamente ao comando AUTH. Códigos de resposta positiva são:

334 – o mecanismo de segurança solicitado é aceito.
235 – a autenticação foi bem-sucedida.

A resposta negativa mais frequente é 535 - Authentication failed. É provável que você consiga corrigir esse erro se souber o que o causou.

Credenciais incorretas – O nome de usuário ou a senha (ou ambos) estão incorretos. Normalmente, o nome de usuário é o mesmo que o seu endereço de email. E a senha é a mesma da sua conta de email.

Conta desativada – Podem haver diferentes motivos para isso, como problemas de spam ou atrasos no pagamento. A melhor maneira de corrigir isso é entrar em contato com o provedor ou administrador do servidor de email.

Conexão SSL/TLS necessária – Alguns servidores podem responder com 535 quando uma conexão criptografada é necessária.

Autenticação SMTP não está habilitada – Verifique se tanto o cliente quanto o servidor têm o SMTP AUTH habilitado.

Mecanismo de autenticação não é suportado – O cliente não suporta nenhum dos mecanismos que o servidor usa para autenticação. Nesse caso, é recomendável habilitar o mecanismo de autenticação básico no servidor e usá-lo.

Além de 535, você pode encontrar outros erros com o comando AUTH:

530 – problema de autenticação que geralmente requer o comando STARTTLS para ser executado.
538 – criptografia necessária para um mecanismo de autenticação solicitado.

O código 550 indica que seu servidor de email requer autenticação SMTP. É principalmente uma resposta à tentativa de enviar uma mensagem. Para mais informações sobre comandos e respostas SMTP, leia nosso post dedicado no blog.

Como testar a autenticação SMTP

Algum tempo atrás, escrevemos sobre testar o servidor SMTP com uma sessão Telnet manual. Agora, vamos usar o cliente Telnet para testar a autenticação SMTP em seu servidor de email.

Passo 1: Certifique-se de que o cliente Telnet está instalado/ativado no seu sistema operacional. Isso se refere principalmente aos usuários do Windows, que precisam realizar algumas manipulações para habilitá-lo.

Passo 2: Estabeleça uma conexão TCP (porta 25) com o servidor SMTP usando telnet smtp.yourserver.com 25. O servidor responderá com 220 smtp.yourserver.com. Isso significa que a sessão SMTP começou.

Passo 3: Cumprimente o servidor com EHLO smtp.yourserver.com. O servidor lhe dará as boas-vindas e oferecerá uma seleção de mecanismos de autenticação. Por exemplo: 250-AUTH PLAIN LOGIN CRAM-MD5.

Passo 4: Vamos nos autenticar via LOGIN. Mas antes, certifique-se de codificar suas credenciais em Base64. Você pode usar esta ferramenta para codificação. Insira o comando AUTH LOGIN. Como você se lembra, o servidor responderá com 334 seguido pelo texto codificado em Base64. Primeiro é a solicitação de nome de usuário e depois – senha. Responda com suas credenciais codificadas em Base64 respectivamente. Se a autenticação for bem-sucedida, o servidor responderá com 235 OK. O teste de autenticação SMTP foi aprovado.

A autenticação SMTP é o que você pode usar para proteger seu servidor de email contra falsificação e phishing. Ao mesmo tempo, existem muitas outras ameaças, como malware, ataques DoS e assim por diante. Leia nosso post no blog para aprender como tornar o SMTP seguro e se proteger contra todas as possíveis vulnerabilidades.