Les commentaires indiquant que SMTP ne nécessite pas d'authentification sont corrects. Cela dit, tous les trois des options que vous avez spécifiées ne sont pas sécurisées, en supposant que le serveur utilise du matériel et des logiciels de base. Je vais montrer pourquoi chacun n'est pas sûr, bien que je ne suive pas votre commande d'origine.
Et si quelqu'un volait le serveur ? Ensuite, ils pourraient simplement ouvrir le fichier ou la base de données, lire le mot de passe et avoir immédiatement accès à toutes les informations importantes de l'entreprise. Donc, à moins que vous n'ayez des gardes armés entourant le serveur jour et nuit, c'est déjà assez dangereux.
Mais ça empire. Aucun système informatique n'est complètement invulnérable aux attaques, et plusieurs attaques très médiatisées (le PlayStation Network de Sony, par exemple) au cours des dernières années ont montré qu'un attaquant peut accéder au contenu des fichiers de disque et des bases de données sans accès physique. De plus, il ressort de votre question que le serveur en question est censé accepter des paquets (requêtes HTTP, emails entrants, etc.) du monde extérieur, ce qui booste votre surface d'attaque.
C'est tentant, mais c'est encore plus pernicieux que l'option 2 ou l'option 3. D'une part, un champ de chaîne final privé est stocké dans le fichier .class généré par le compilateur Java, donc avec cette option, vous stockez déjà le mot de passe non chiffré sur le disque dur du serveur. Après avoir compromis le serveur comme dans l'option 2 ou 3, un attaquant peut simplement exécuter javap afin d'obtenir le mot de passe en clair du fichier .class.
Cette approche élargit encore plus votre surface d'attaque. Si le mot de passe est stocké dans le cadre du code source, il est soudainement disponible pour tous les développeurs qui travaillent sur le code. Selon le principe du moindre privilège, les développeurs ne devraient pas connaître de mots de passe supplémentaires, et il y a une très bonne raison ici. Si l'un des développeurs machines est volée ou compromise de l'extérieur, l'attaquant peut parcourir le disque dur de la machine compromise et obtenir le mot de passe en clair. Ensuite, il y a le contrôle des sources. L'un des avantages les plus importants du contrôle de code source est qu'il vous permet d'inspecter n'importe quelle version antérieure de votre code. Ainsi, même si vous passez à une méthode sécurisée à l'avenir, si le mot de passe est déjà entré dans le contrôle de source, le serveur de contrôle de source est un point d'attaque potentiel.
Tous ces facteurs s'additionnent pour montrer que, même si la sécurité du serveur HTTP/mail est de premier ordre, l'option 1 augmente tellement la surface d'attaque que la sécurité du serveur HTTP/mail n'aide pas vraiment.
Détail supplémentaire :au début, j'ai spécifié "en supposant que le serveur utilise du matériel et des logiciels de base". Si vous n'utilisez pas de matériel et de logiciels de base, vous pouvez, par exemple, démarrer à partir d'un stockage en lecture seule et utiliser uniquement une base de données chiffrée, ce qui oblige une personne à fournir la clé de déchiffrement à chaque démarrage. Après cela, les informations décryptées ne vivent que dans la mémoire et ne sont jamais écrites sur le disque. De cette façon, si le serveur est volé, un attaquant doit débrancher le serveur et perd ainsi toutes les informations déchiffrées qui n'étaient qu'en mémoire. Ce type de configuration est parfois utilisé pour un KDC Kerberos (avec le serveur dans une boîte verrouillée pour plus de sécurité), mais est rarement utilisé autrement, et est franchement exagéré lorsqu'il existe un moyen simple de résoudre votre problème sans passer par tout ce supplément dépense.
