Je débute dans l’installation de Discourse et je l’ai récemment configuré sur un Droplet Digital Ocean pour servir de forum et de page communautaire à notre entreprise.
Lors de l’installation, j’ai remarqué que la saisie du mot de passe SMTP n’est pas protégée et qu’il est stocké en clair dans le fichier app.yml.
Cela semble être un problème de sécurité potentiel. Cependant, je ne suis pas un expert en réseau ou en sécurité, il se peut donc que cela soit acceptable pour plusieurs raisons. Mais afin de rassurer notre responsable informatique, il m’aiderait de mieux comprendre pourquoi cela est fait de cette manière.
Je sais que Discourse est largement utilisé par de nombreuses entreprises, je soupçonne donc que ce sujet a déjà été suffisamment abordé.
Les hachages sont à sens unique, ils ne peuvent pas être inversés pour retrouver les données d’origine.
Les mots de passe des utilisateurs sont hachés car ils n’ont pas besoin d’être réversibles. Un hachage de mot de passe dans la base de données n’est consulté que lorsque l’utilisateur tente de se connecter. Le hachage du mot de passe fourni est comparé au hachage du mot de passe stocké dans l’enregistrement de cet utilisateur.
Il est assez courant que des éléments tels que les mots de passe SMTP et les clés API soient stockés en texte brut. Ils doivent être transmis sous leur forme originale, donc les hacher empêcherait leur utilisation. Si le tiers acceptait un hachage du mot de passe, il n’y aurait aucun avantage à le hacher comme forme de protection.
Comme Jay l’a dit plus haut, si l’intégrité physique de votre serveur est compromise et que votre app.yml est accessible, vous avez des problèmes bien plus importants à résoudre que la nécessité de réinitialiser un mot de passe SMTP.
Une mise en garde importante ici : vous ne devriez pas utiliser ce mot de passe SMTP ailleurs, mais cela ne concerne pas spécifiquement Discourse. C’est une bonne pratique de sécurité pour tous les systèmes et tous les comptes.
Comme l’a dit Jay, si quelqu’un obtient un accès à votre fichier app.yml, vous avez d’autres problèmes. Cela signifie qu’ils ont probablement un accès root complet à votre serveur, y compris à votre base de données de production.
La meilleure pratique ici consiste à s’assurer que votre serveur est sécurisé.
Je suis d’accord pour dire que la protection du serveur constitue la première ligne de défense. Cependant, dans ce cas précis, cela échappe à mon contrôle, car j’ai installé Discourse sur un Droplet Digital Ocean.
@Stephen — merci pour les informations de contexte concernant les mots de passe SMTP. Je ne savais pas qu’il était courant de les stocker en clair pour ce type d’utilisation. Comme je l’ai dit, cela relève de mon domaine d’expertise. C’est simplement quelque chose qui a attiré mon attention et que je voulais soulever.
Pas tout à fait Vous pouvez restreindre les connexions à une clé SSH uniquement, activer un pare-feu fonctionnel et vous assurer que les correctifs de sécurité sont appliqués régulièrement. Cela couvre une part significative de la sécurisation d’une instance Droplet.
C’est exact. Et sauf si vous avez chiffré votre système de fichiers, ce qui est difficile à réaliser, vous devez également leur faire confiance. Ils ont un accès physique aux serveurs et au réseau.
Comme expliqué, il vous suffit d’avoir le mot de passe pour l’utiliser.
Vous pouvez restreindre les connexions à une clé SSH uniquement, activer un pare-feu fonctionnel et vous assurer que les correctifs de sécurité sont appliqués régulièrement. Cela couvre une part significative de la sécurisation d’une instance Droplet.