Seguridad de las contraseñas de correo electrónico (SMTP / POP)

3

En la aplicación de correo de mi cliente (ThunderBird) elegí (y mi servidor de correo aceptó) SMTP con STARTTLS, el POP (o POP3) con SSL / TLS. Entiendo que esto es solo para el contenido de correo de mi aplicación cliente a mi servidor de correo ISP.

Mi pregunta es específicamente para la seguridad de esta conexión al servidor de correo, es decir, las opciones desplegables de seguridad de la conexión de ThunderBird son, Sin autenticación, contraseña normal, contraseña cifrada, Kerberos / GSSAPI, NTLM y OAuth2. ThunderBird también puede probar mi servidor de correo electrónico para lo que es capaz de cumplir o implementar en su extremo. Lo que encontré para mi servidor era solo "Contraseña normal".

Al parecer, mi servidor de correo electrónico no ofrece una conexión cifrada y supongo que mi contraseña puede ser vista por alguien con suficientes habilidades. Además, tengo curiosidad por saber si hay algún servidor de correo electrónico (ISP proporcionado u otro) que ofrezca un cifrado de contraseña.

    
pregunta RWB 28.11.2018 - 20:07
fuente

1 respuesta

3

Aquí hay dos aspectos separados de la configuración: la seguridad a nivel de conexión y la seguridad a nivel de autenticación. En la práctica, como el nivel de conexión (TLS) protege a ambos, es común que la seguridad del nivel de autenticación sea baja ("Contraseña normal"). Mientras esté utilizando TLS (SMTP / POP / IMAP sobre SSL / TLS o STARTTLS), está bien.

¿Por qué?

Hace mucho tiempo, antes de que SSL / TLS / STARTTLS se hicieran comunes, las credenciales eran la única parte de la conexión que a la gente le importaba proteger. Como usted dice, el correo electrónico puede transmitirse sin cifrar tan pronto como sale de su servidor, por lo que las personas no estaban profundamente preocupadas por la posibilidad de que se lea. Sin embargo, estaban preocupados por sus credenciales. Y las credenciales utilizadas para pasar por un enlace SMTP / POP / IMAP sin cifrar.

Por esa razón, se diseñaron varios protocolos especialmente diseñados para cifrar las credenciales. Digest-MD5, GSSAPI y OAUTH eran métodos SMTP AUTH más seguros que se pueden usar en una conexión no cifrada. Los tipos más comunes PLAIN y LOGIN, que no cifran las credenciales, dejarían la contraseña vulnerable si no hubiera cifrado a nivel de conexión .

Pero entonces el mundo comenzó a cifrar la conexión. Los clientes y servidores SMTP, POP e IMAP agregaron soporte para SSL / TLS o STARTTLS para proteger toda la conexión. Una vez que se volvieron comunes, hubo poca motivación para usar los métodos SMTP AUTH protegidos más complejos, porque el TLS proporcionaría toda la protección necesaria. Es por eso que su ISP solo se siente cómodo al ofrecer "Contraseña normal" (que es PLAIN y / o LOGIN) - ellos saben que la capa TLS lo protege.

(De hecho, algunos métodos más sólidos debilitan la seguridad al requerir que el servidor almacene una copia cifrada reversible o de texto simple de la contraseña de cada usuario, en lugar de un hash de una sola vía. Para citar Wikipedia en Autenticación de resumen ), " Algunos servidores requieren que las contraseñas se almacenen utilizando un cifrado reversible. Sin embargo, es posible almacenar el valor digerido del nombre de usuario, dominio y contraseña. "El enlace de la nota al pie de esta última declaración va a RFC 2617 lo cual explica más detalladamente las compensaciones de seguridad de Autenticación Digest ... He considerado implementar la Autenticación Digest con Postfix, Dovecot, Courier y Cyrus a lo largo de los años; cada vez que decidí que no me gustaba la compensación.)

    
respondido por el gowenfawr 28.11.2018 - 20:23
fuente

Lea otras preguntas en las etiquetas