Come gestire l'autenticazione SMTP

Come ti sentiresti se chiunque potesse inviare email dal tuo server di posta? Via libera agli spammer – no grazie! Ecco perché Google e altri fornitori di servizi email proteggono i loro server dall’uso non autorizzato. I mittenti devono autenticarsi e dimostrare di avere un account valido. Se non lo fanno, il server respingerà la loro richiesta. Tutto questo è possibile grazie all’autenticazione SMTP, nota anche come SMTP AUTH.

Perché non dovresti usare server SMTP senza autenticazione

Supponiamo che la tua azienda fornisca un indirizzo email ai tuoi dipendenti. Tuttavia, non è necessaria l’autenticazione per connettersi al server di posta. Quindi, non devono inserire un nome utente e una password per inviare un’email. Quali pericoli potrebbe comportare questo?

L’anonimato è la prima cosa da considerare. Chiunque utilizzi il server di posta rimane anonimo poiché non deve effettuare il login con credenziali. Questo non è un grosso problema. Ma hai davvero bisogno di questo tipo di anonimato?

Il problema principale è lo spoofing dell’email. Senza autenticazione SMTP, è possibile falsificare il mittente. Nel migliore dei casi, qualcuno utilizzerà il tuo server di posta per inviare email promozionali non autorizzate. Nel peggiore dei casi, il falsificatore può richiedere informazioni personali al destinatario e usarle per scopi di furto di identità (phishing).

Quindi, come proteggere il server dallo spoofing? In precedenza, abbiamo parlato dell’autenticazione delle email tramite record SPF, DKIM, e DMARC. Oggi, parliamo dei meccanismi di autenticazione per il server.

Cos’è SMTP AUTH e come funziona?

L’autenticazione SMTP, o semplicemente SMTP AUTH, è l’estensione del servizio ESMTP. Richiede che un mittente di email (client) abbia il permesso di utilizzare il server di posta. Quindi, solo gli utenti autorizzati possono inviare messaggi in uscita.

L’autenticazione viene effettuata secondo il meccanismo SASL. Di norma, i server utilizzano i tre meccanismi più comuni: PLAIN, LOGIN e CRAM-MD5. Ci sono anche altre opzioni di cui parleremo più avanti. Ora, diamo un’occhiata all’autenticazione dal punto di vista pratico.

Dopo l’handshake SMTP, il client invia il comando EHLO al server. La risposta è il codice 250. Di solito, è accompagnata da informazioni aggiuntive, inclusi i meccanismi SASL supportati. Ecco come appare la sessione 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

Come esempio, useremo Email Sandbox di Mailtrap poiché risponde positivamente alla maggior parte dei comandi dei client e non dovremo preoccuparci di problemi di configurazione. Inoltre, il nostro Email Sandbox impedisce che le email di prova raggiungano i destinatari e li spammino.

Proviamo ad autenticarci tramite il meccanismo SASL LOGIN. Per questo, il client invia il comando AUTH LOGIN. Il server risponde con un codice 334 e richiede un nome utente. Una volta che il client lo fornisce, il server segue con la richiesta della password. Alla fine, il server risponde 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

DYT3jf4sdDR5 e LIRdf2pekwW3 del server sono i testi codificati in BASE64 per “Username” e “Password”, rispettivamente. TXktVXNlcm5hbWU= e TXktUGFzc3dvcmQ= sono le risposte del client che sono anch’esse codificate in BASE64.

ESMTP ha sostituito POP-before-SMTP

Oggi, tutti i server di posta utilizzano l’autenticazione ESMTP tramite i meccanismi SASL. Questo tipo di SMTP AUTH ha sostituito la ormai superata autenticazione POP-before-SMTP. Quest’ultima, tuttavia, può ancora essere trovata su alcuni vecchi server. L’idea è di autenticare l’utente al servizio POP3 dello stesso server e poi ricollegarlo all’SMTP. Se hai bisogno di sapere come POP3 si differenzia da SMTP, consulta il nostro post dedicato IMAP vs. POP3 vs. SMTP.

Questo metodo di autenticazione non è molto sicuro. Client diversi possono condividere lo stesso indirizzo IP e autenticarsi come un solo utente. Inoltre, il server esegue sia i servizi POP3 che SMTP sullo stesso sistema. L’autenticazione ESMTP ha un vantaggio poiché implementa i meccanismi SASL.

Meccanismi di autenticazione SASL

I meccanismi di autenticazione SMTP consentono al server di verificare se il client SMTP è autorizzato. Differiscono nel livello di sicurezza. Di norma, il server elenca i meccanismi SASL supportati come risposta al comando EHLO. La maggior parte dei server supporta le seguenti opzioni:

PLAIN – il server richiede al client di autenticarsi utilizzando nome utente e password. Queste credenziali vengono trasmesse come una stringa codificata in Base64.

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

In alternativa, il client può inviare le credenziali insieme al comando AUTH PLAIN in una singola riga:

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

LOGIN – il server richiede al client di autenticarsi utilizzando nome utente e password. La differenza rispetto a PLAIN è che le credenziali codificate in Base64 vengono trasmesse una alla volta: nome utente e password.

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 – il server richiede al client di risolvere una sfida computazionale utilizzando la password. La risposta del client è una stringa contenente un nome utente e un digest a 16 byte in notazione esadecimale. La stringa è codificata in BASE64.

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

CRAM-MD5 fornisce un livello di sicurezza superiore rispetto ai meccanismi di autenticazione in testo semplice, PLAIN e LOGIN. Il protocollo utilizza un principio di sfida-risposta. Il server invia una stringa di sfida. Il client decodifica la sfida del server e risponde con un calcolo HMAC (Hash-based Message Authentication Code) utilizzando la password come chiave segreta. Dopodiché, la sfida hashata viene convertita in una stringa di cifre esadecimali minuscole. Inoltre, il client antepone il nome utente e un carattere spazio alla stringa. Il server riceve questa concatenazione codificata in BASE64.

Gli hacker non possono:

decodificare le credenziali poiché non vengono effettivamente trasferite dal client in testo o in codice
duplicare l’hash perché devono conoscere la password
simulare l’hash, perché la sfida computazionale è mutevole e cambia ad ogni login

Ora, scopriamo altri meccanismi SASL che possono essere utilizzati sui server SMTP:

XOAUTH/XOAUTH2 – è un meccanismo di autenticazione di base nei server di posta di Gmail, Live.com e Outlook.com. Si basa sulle firme OAuth per autenticare gli utenti. XOAUTH2 consente al client di inviare token di accesso OAuth 2.0 al server. La risposta del client è una stringa codificata in Base64. Il comando AUTH consiste in una singola riga di testo.

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

NTLM è un meccanismo di autenticazione a sfida-risposta. È spesso utilizzato nella modalità di Autenticazione Integrata di Windows e in alcuni prodotti Microsoft come MS Exchange. Una volta che il client invia il comando AUTH, il server consente l’autenticazione NTLM. Il client invia un NEGOTIATE_MESSAGE. Il server risponde con un CHALLENGE_MESSAGE per stabilire l’identità del client. Il client invia un AUTHENTICATE_MESSAGE come risposta alla sfida. Tutti i messaggi sono codificati in 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 si riferisce al Generic Security Service Application Program Interface. Di per sé, GSSAPI è quasi esclusivamente utilizzato con Kerberos, un protocollo di autenticazione di rete. Simile a NTLM, questo meccanismo di autenticazione è spesso utilizzato nei server Windows di Microsoft. L’autenticazione GSSAPI o Kerberos appare come segue:
- Il client e il server negoziano una chiave segreta condivisa, un cifrario e un hash per la sessione.
- Il server fornisce una chiave host.
- Il client si autentica.

Ecco un esempio:

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 connessione SSL è necessaria per i meccanismi di testo non cifrato. Le credenziali non cifrate possono essere inviate senza problemi. Tutti i meccanismi SASL non di testo non richiedono la crittografia SSL/TLS.

Porte di ascolto SMTP AUTH

587 – Questa è la porta predefinita per l’SMTP AUTH. È anche conosciuta come porta di invio messaggi. La 587 è associata ai server di invio o agenti di invio della posta (MSA) e implica l’uso dell’autenticazione.
25 – In alcuni casi, l’SMTP AUTH può essere utilizzato anche su questa porta. La 25 è conosciuta come porta di relay dei messaggi.

Codice 535 – Autenticazione fallita e altri errori SMTP AUTH

Il server SMTP può rispondere sia positivamente che negativamente al comando AUTH. I codici di risposta positivi sono:

334 – il meccanismo di sicurezza richiesto è accettato
235 – l’autenticazione è riuscita

La risposta negativa più frequente è 535 - Authentication failed. È probabile che tu possa risolvere questo errore se conosci la causa.

Credenziali errate – Sia il nome utente che la password (o entrambi) sono errati. Di solito, il nome utente è lo stesso del tuo indirizzo email. E la password è la stessa del tuo account email.

Account disabilitato – Ci possono essere diverse ragioni per questo, come problemi di spam o arretrati nei pagamenti. Il modo migliore per risolvere questo problema è contattare il tuo fornitore di server di posta o l’amministratore.

Connessione SSL/TLS richiesta – Alcuni server possono rispondere con 535 quando è necessaria una connessione crittografata.

Autenticazione SMTP non abilitata – Assicurati che sia il tuo client che il server abbiano abilitato l’SMTP AUTH.

Meccanismo di autenticazione non supportato – Il client non supporta nessuno dei meccanismi che il server utilizza per l’autenticazione. In questo caso, è consigliabile abilitare il meccanismo di autenticazione di base sul server e utilizzarlo.

Oltre a 535, potresti incorrere in altri errori con il comando AUTH:

530 – problema di autenticazione che richiede principalmente il comando STARTTLS
538 – crittografia richiesta per un meccanismo di autenticazione richiesto

Il codice 550 indica che il tuo server di posta richiede l’autenticazione SMTP. È principalmente una risposta al tentativo di inviare un messaggio. Per ulteriori informazioni sui comandi e risposte SMTP, leggi il nostro post dedicato.

Come testare l’autenticazione SMTP

Qualche tempo fa abbiamo scritto un blog sul testing del server SMTP con una sessione Telnet manuale. Ora, utilizziamo il client Telnet per testare l’autenticazione SMTP sul tuo server di posta.

Step 1: Assicurati che il client Telnet sia installato/attivato sul tuo sistema operativo. Questo riguarda principalmente gli utenti di Windows che devono effettuare alcuni passaggi per attivarlo.

Step 2: Stabilisci una connessione TCP (porta 25) con il server SMTP utilizzando telnet smtp.tuoserver.com 25 Il server risponderà con 220 smtp.tuoserver.com Questo significa che la sessione SMTP è iniziata.

Step 3: Saluta il server con EHLO smtp.tuoserver.com Il server ti darà il benvenuto e offrirà una selezione di meccanismi di autenticazione. Per esempio: 250-AUTH PLAIN LOGIN CRAM-MD5

Step 4: Autentichiamoci tramite LOGIN. Ma prima, assicurati di codificare le tue credenziali in Base64. Puoi utilizzare questo strumento per la codifica. Inserisci il comando AUTH LOGIN. Come ricordi, il server risponderà con 334 seguito dal testo codificato in Base64. Prima viene richiesto il nome utente, e poi – la password. Rispondi con le tue credenziali codificate in Base64 rispettivamente. Se l’autenticazione ha successo, il server risponderà con 235 OK. Il test dell’SMTP AUTH è stato superato.

L’autenticazione SMTP è ciò che puoi utilizzare per proteggere il tuo server di posta dallo spoofing e dal phishing. Allo stesso tempo, ci sono molte altre minacce come malware, attacchi DoS e così via. Leggi il nostro post per scoprire come rendere sicuro l’SMTP e proteggerti da tutte le possibili vulnerabilità.

Cos’è l’autenticazione SMTP e perché non puoi ignorarla