Sicurezza delle password di posta elettronica (SMTP / POP)

3

Nella mia app di posta client (ThunderBird) ho scelto SMTP (e il mio server di posta elettronica accettato) con STARTTLS, POP (o POP3) con SSL / TLS. Capisco che questo è per il contenuto della posta dalla mia app client al mio solo server di posta ISP.

La mia domanda è specifica per la sicurezza di questa connessione al server di posta elettronica, ad esempio la connessione di ThunderBird Le opzioni di sicurezza a discesa sono, Nessuna autenticazione, password normale, password crittografata, Kerberos / GSSAPI, NTLM e OAuth2. ThunderBird può anche sondare il mio server di posta elettronica per ciò che è in grado di soddisfare o implementare alla sua fine. Che ho trovato per il mio server era solo "Password normale".

Quindi apparentemente il mio server di posta elettronica non offre una connessione criptata e suppongo che la mia password possa essere vista da qualcuno con competenze sufficienti. Inoltre, sono curioso di sapere se ci sono server e-mail (ISP forniti o altri) che offrono la crittografia password.

    
posta RWB 28.11.2018 - 20:07
fonte

1 risposta

3

Qui ci sono due aspetti separati della configurazione: la sicurezza a livello di connessione e la sicurezza a livello di autenticazione. In pratica, poiché il livello di connessione (TLS) protegge entrambi, è comune che la sicurezza a livello di autenticazione sia bassa ("Password normale"). Finché utilizzi TLS (SMTP / POP / IMAP su SSL / TLS o STARTTLS), stai bene.

Perché?

Tornare indietro, prima che SSL / TLS / STARTTLS diventasse comune, le credenziali erano l'unica parte della connessione interessata alla protezione. Come dici tu, l'e-mail può essere trasmessa non criptata non appena lascia il tuo server, quindi le persone non erano profondamente preoccupate del potenziale per la lettura. Tuttavia, erano preoccupati per le loro credenziali. E quelle credenziali passavano sopra un link SMTP / POP / IMAP non criptato.

Per questo motivo sono stati ideati numerosi protocolli appositamente progettati per crittografare le credenziali. Digest-MD5, GSSAPI e OAUTH erano tutti metodi più sicuri SMTP AUTH che potevano essere utilizzati su una connessione non crittografata. I tipi più comuni PLAIN e LOGIN, che non crittografano le credenziali, lascerebbero la password vulnerabile se non ci fosse la crittografia a livello di connessione .

Ma poi il mondo ha iniziato a crittografare la connessione. I client ei server SMTP, POP e IMAP hanno aggiunto il supporto per SSL / TLS o STARTTLS per proteggere l'intera connessione. Una volta diventati comuni, c'era poca motivazione ad usare i metodi SMTP AUTH più complessi protetti, perché TLS avrebbe fornito tutta la protezione necessaria. Ecco perché il tuo ISP è a suo agio solo offrendo "Password normale" (che è PLAIN e / o LOGIN) - sanno che il livello TLS ti protegge.

(In effetti, alcuni metodi più potenti indeboliscono la sicurezza, richiedendo che il server memorizzi un testo in chiaro o una copia crittografata della password di ciascun utente, piuttosto che un hash unidirezionale di esso. Per citare Wikipedia sull'autenticazione del digest ), " Alcuni server richiedono che le password vengano archiviate utilizzando la crittografia reversibile. Tuttavia, è possibile memorizzare il valore digerito del username, realm e password. "Il link alla nota a piè di pagina per quest'ultima affermazione va a RFC 2617 che fornisce maggiori dettagli sui compromessi della sicurezza di Digest Authentication ... Ho considerato l'implementazione dell'autenticazione del Digest con Postfix, Dovecot, Courier e Cyrus nel corso degli anni; ogni volta ho deciso che non mi piaceva il trade-off.)

    
risposta data 28.11.2018 - 20:23
fonte

Leggi altre domande sui tag