¿Por qué no es seguro enviar a un usuario su contraseña a través de una comunicación cifrada con SSL en lugar de enviar siempre un enlace de restablecimiento?

Tres grandes problemas con esto:

• El servidor debe poder enviar la contraseña, lo que significa que el servidor conoce la contraseña, lo que significa que el administrador / propietario del servidor también puede leerla. Esto nunca debería ser (vea muchos temas sobre hashes, sales y funciones de derivación de múltiples rondas). Si bien un administrador con acceso a todos los servidores ya puede suplantar a los usuarios, etc., según lo deseado, muchos usuarios utilizan su contraseña para varias cosas. El administrador no debería poder acceder a estos.
• Si el servidor es pirateado, lo mismo es válido para el atacante: no deberían poder leer las contraseñas, ya que no deberían poder reutilizarlas en otros lugares.
• Y no, SSL no es "completamente seguro". Especialmente, TLS existe porque SSL es bastante inseguro (pero TLS tampoco es perfecto).

Aún no se ha mencionado un problema importante:
La autenticación (faltante) del Cliente en SSL / TLS .

Si bien @deviantfan tiene algunos puntos válidos, me gustaría agregar este problema básico, por qué su propuesta no es viable.

TLS sin autenticación de cliente:

Normalmente, SSL / TLS se realizan con el Servidor autenticándose ante el Cliente, pero no al revés. Esto significa que cualquier cliente puede configurar una conexión TLS segura con el servidor y asegurarse de que el servidor sea legítimo. Sin embargo, si no hay una autenticación de cliente, el servidor no puede estar seguro, si la persona que se conecta a él es la persona que dice ser. Por lo tanto, no tendría sentido que el servidor envíe una contraseña a ningún cliente en esta configuración.

TLS con autenticación de cliente:

En caso de que la autenticación del cliente se realice para configurar la sesión TLS, el servidor puede estar seguro de que el cliente es quien dice ser. Sin embargo, para habilitar la autenticación del cliente, en el lado del cliente se debe instalar un certificado (+ clave privada). Si este tipo de autenticación mutua ya está establecida, no sería necesario tener una contraseña para iniciar sesión en primer lugar.

En general, los servidores no almacenan la contraseña, en su lugar almacenan el hash de la contraseña junto con un 'salt'. La sal son datos aleatorios que se utilizan como una entrada adicional a la función unidireccional que contiene la contraseña.

Agregar la sal y el hashing de la contraseña evitará que se produzcan ataques de diccionario o ataques de tabla arco iris precalculados.

Las respuestas son bastante puntuales. Sin embargo, desde un punto de vista lógico, debo señalar que dicho:

  

"cuando probablemente prefieras mantenerlo igual, simplemente lo olvidaste."

no es posible. Dado que los sitios que se consideran seguros ni siquiera conocen su contraseña, y solo el usuario que la conoce, si la olvida por completo, significa que se perdió ... para siempre.

En segundo lugar, si olvidó su contraseña, es una buena indicación de que eligió una contraseña para satisfacer el algoritmo de ingreso de contraseña en lugar de una contraseña que sea buena para usted el usuario. Gran parte de la culpa está generalmente en el lado de los diseñadores del sitio, ya que no deberían intentar proteger al usuario de sí mismo (al hacer que elijan una contraseña "segura") y en su lugar deberían mejorar su juego y trabajar en mejores técnicas de protección de contraseñas. En ese sentido, el sitio le está diciendo sutilmente que "hey, eligió una contraseña incorrecta; esta es su oportunidad de obtener una mejor y más fácil de recordar".