Qual è il tipo di autenticazione SMTP più sicuro?

Con SSL / TLS va bene usare LOGIN / PLAIN .

È necessario fornire SMTP su una connessione crittografata con SSL. Mentre alcuni schemi del tuo elenco (ad esempio DIGEST-MD5 ) possono mantenere una password protetta anche su un canale non affidabile, non proteggeranno gli utenti da un aggressore man-in-the-middle che manomette la loro sessione. (In genere, i server di posta elettronica racchiudono SMTP tramite TLS diretto o un aggiornamento di connessione con STARTTLS alle porte 465/587 .)

Qualsiasi tipo di autenticazione SMTP, indipendentemente dal fatto che si usi PLAIN o un metodo avanzato, fornisce solo autenticazione a livello di applicazione. Ma quello che si desidera è sicurezza del livello di trasporto . Dopo che un utente è stato autenticato tramite SMTP, non ci sarà alcuna connessione crittografata automaticamente. Secondo il protocollo SMTP, i comandi e le e-mail vengono scambiate con il server in testo normale, consentendo a un aggressore man-in-the-middle di leggere e modificare la comunicazione e iniettare nuovi comandi. Ecco perché dovresti fornirlo sulla crittografia SSL, proprio come HTTPS fornisce HTTP su SSL.

L'analogia HTTP: se proteggi il tuo sito web con HTTPS, non importa che il modulo di login trasmetta effettivamente la tua password come una stringa semplice nel corpo POST della richiesta HTTP, perché il trasporto dei dati è SSL- criptato. Abilitare CRAM-MD5 per SMTP è analogo all'implementazione di uno schema challenge-response in Javascript prima di trasmettere l'accesso credenziali per un sito web. (Puoi vedere occasionalmente quella tecnica nelle interfacce del router che non forniscono HTTPS ma non è molto comune.)

Come per un esempio di vita reale, GMail sta bene offrendo l'autenticazione LOGIN / PLAIN (dove le credenziali sono inviate nel testo del piano) dopo aver stabilito una connessione SSL sicura:

$ 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
...

(Come puoi vedere, forniscono anche alcuni metodi che non hai elencato, ad esempio XOAUTH2 per i token OAuth2 che potrebbero essere interessanti se stai cercando l'autenticazione senza password.)

Quello che chiamo una bella autenticazione è uno che ha le seguenti proprietà:

• il server non deve mai conoscere la password attuale ma mantiene solo un hash di esso

  Questo garantisce che anche se il database delle password viene mai compromesso, l'hacker non farà altro che invertire gli hash e gli utenti avranno abbastanza tempo per cambiare le loro password

• la password non viene mai scambiata in testo chiaro

  Ciò che viene scambiato può essere spiato troppo facilmente e una password che passa in chiaro su un canale non crittografato dovrebbe essere vista come compromessa

Se il server SMTP consente a TLS, PLAIN di rispettare entrambi i seguenti scenari: HELO, STARTTLS, LOGIN

Oltre ai migliori consigli per SMTP, ecco il tuo elenco disponibile:

• LOGIN, PLAIN: la password viene trasferita in chiaro.
• CRAM-MD5: debole nei confronti di testo in chiaro scelto e presenta problemi di archiviazione delle password.
• DIGEST-MD5: Meglio di CRAM-MD5 in quanto è più strong contro l'attacco in chiaro in chiaro e consente l'utilizzo di server di autenticazione di terze parti
• NTLM / SPA / MSN: autenticazione NTLM che è anche vulnerabile a testo in chiaro scelto .