Los comentarios que señalan que SMTP no requiere autenticación son correctos. Dicho esto, los tres de las opciones que especificó son inseguras, suponiendo que el servidor utilice hardware y software estándar. Mostraré por qué cada uno es inseguro, aunque no seguiré tu orden original.
¿Qué pasaría si alguien robara el servidor? Luego, podrían simplemente abrir el archivo o la base de datos, leer la contraseña e inmediatamente tener acceso a toda la información importante de la empresa. Entonces, a menos que tenga guardias armados rodeando el servidor día y noche, esto ya es bastante inseguro.
Pero se pone peor. Ningún sistema informático es completamente invulnerable a los ataques, y varios ataques muy publicitados (por ejemplo, PlayStation Network de Sony) en los últimos años han demostrado que un atacante puede acceder al contenido de los archivos del disco y las bases de datos sin acceso físico. Además, de su pregunta parece que el servidor en cuestión está diseñado para aceptar paquetes (solicitudes HTTP, correos electrónicos entrantes, etc.) del mundo exterior, lo que aumenta su superficie de ataque.
Esto es tentador, pero es incluso más pernicioso que la opción 2 o la opción 3. Por un lado, un campo de cadena final privado se almacena en el archivo .class generado por el compilador de Java, por lo que con esta opción ya está almacenando la contraseña sin cifrar. en el disco duro del servidor. Después de comprometer el servidor como en la opción 2 o 3, un atacante puede simplemente ejecutar javap para obtener la contraseña de texto sin formato del archivo .class.
Sin embargo, este enfoque amplía aún más la superficie de ataque. Si la contraseña se almacena como parte del código fuente, de repente está disponible para todos los desarrolladores que están trabajando en el código. Bajo el principio de privilegio mínimo, los desarrolladores no deberían saber contraseñas adicionales, y hay una muy buena razón aquí. Si alguno de los desarrolladores máquinas es robada o comprometida desde el exterior, el atacante puede mirar a través del disco duro de la máquina comprometida y obtener la contraseña de texto sin formato. Luego está el control de fuente. Uno de los beneficios realmente importantes del control de fuente es que le permite inspeccionar cualquier versión anterior de su código. Entonces, incluso si cambia a un método seguro en el futuro, si la contraseña alguna vez ingresó al control de fuente, entonces el servidor de control de fuente es un punto de ataque potencial.
Todos estos factores se suman para mostrar que, incluso si la seguridad del servidor de correo/HTTP es de primera categoría, la opción 1 aumenta tanto la superficie de ataque que la seguridad del servidor de correo/HTTP realmente no ayuda.
Detalle adicional:al principio especifiqué "asumiendo que el servidor usa hardware y software básicos". Si no está utilizando hardware y software básicos, puede hacer cosas como arrancar desde el almacenamiento de solo lectura y usar solo una base de datos cifrada, lo que requiere que una persona proporcione la clave de descifrado en cada arranque. Después de eso, la información descifrada vive solo en la memoria y nunca se escribe en el disco. De esta manera, si el servidor es robado, un atacante tiene que desconectar el servidor y así pierde toda la información descifrada que solo estuvo en la memoria. Este tipo de configuración a veces se usa para un KDC de Kerberos (con el servidor en una caja cerrada para mayor seguridad), pero rara vez se usa de otra manera, y es francamente excesivo cuando hay una manera fácil de resolver su problema sin tener que hacer todo este trabajo adicional. gasto.
