Comment garder les secrets secrets
(alternatives aux mots de passe codés « en dur »)

« Coder les mots de passe en dur » est le fait de mettre des mots de passe non-encryptés (en texte clair) ainsi que d’autres données secrètes (telles que des clés privées) dans le code source. Des exemples typiques sont :

...
private static String passwd = "mYv3rYSECr3tPWD";
...
db = MySQLdb.connect(host="db.server.com", user="admin", passwd="NOBODYwillEVERguess", db="sales")
...
String url = "jdbc:mysql://" + serverName + "/access?user=webclient&password=ILoveJuliet";
...
for i in 01 02 03 04; do ./remove_temp_files.sh --machine=appserv$i --rootpassword="*d3H%sS-W"; done
...

Bien que les développeurs de logiciels peuvent ne pas le réaliser, leur code source est (ou devient) très souvent disponible publiquement. Le code peut être gardé dans une base centralisée Git (« Git repository »), qui peut être consultée sur le Web. D’autres développeurs ou mainteneurs de code peuvent envoyer des parties de code par e-mail ou les poster sur le Web sans être au courant qu’ils révèlent des mots de passe. Même si le code source est gardé sur un système de fichiers sécurisé durant son développement, il sera certainement déplacé plus tard (peut-être quelques années plus tard), lorsque l’équipe est réorganisée, que les serveurs de fichiers sont upgradés, etc. – et les nouvelles locations peuvent ne plus être protégées. Les programmes compilés peuvent facilement être inversés. Enfin et surtout, les mots de passe doivent être changés régulièrement – et changer des mots de passe codés « en dur » peut se révéler être très embêtant (recompilation du code source, nouvelle « parution » (« release »), etc.). Pour toutes ces raisons, les développeurs de logiciels doivent éviter de coder « en dur » des informations secrètes (mots de passe, etc.) dans le code source.

Mais quelles sont les alternatives au codage « en dur » des mots de passe?
Qu’est-ce que les développeurs peuvent faire d’autre ?

Il n’existe pas une solution simple à ce problème, et celui-ci doit être résolu au cas par cas. Ci-dessous, vous trouverez des suggestions de solutions possibles:

  • Demandez à l’utilisateur un mot de passe: Dans beaucoup de cas, l’utilisateur doit connaitre le mot de passe, et non le programme! C’est la meilleure solution si elle peut être appliquée (malheureusement cela ne va pas marcher pour les « batch scripts », les applications Web se connectant à une base de données, etc.);
  • Utilisez des identifiants déjà existants: Par exemple: les tickets AFS et/ou Kerberos sont disponibles si un script est exécuté depuis acrontab;
  • Gardez les secrets dans un fichier séparé: Il est beaucoup plus facile de protéger un fichier de config/propriétés séparé dont on sait qu’il contient des mots de passe, que de garder un œil sur les différentes locations du code source où se trouvent les mots de passe (cela peut être refactorisé, etc.). De tels fichiers doivent avoir des permissions très restrictives et ne doivent pas se retrouver sur Git or Pastebin, etc. Faites attention : si c’est une application Web, assurez-vous que le fichier de mots de passe n’est pas téléchargeable par tout le monde ! Pour des serveurs gère par « Puppet », utilisez le service « tbag » du CERN IT;
  • Chiffrez: Si votre programmes a/sait déjà un secret (un autre mot de passe, une clé de déchiffrement, etc.), vous pouvez l’utiliser pour chiffrer (et plus tard déchiffrer) d’autres informations secrètes. Les librairies qui fournissent des algorithmes de chiffrement tels que RSA, Rijndael, etc., sont disponibles pour toutes les plateformes et tous les langages de programmation communs. Même chiffrées, il est préférable de mettre les données secrètes dans un fichier séparé (voir ci-dessus);
  • Gardez les secrets dans une base de données: Si elle est bien protégée, la base de données est un bon endroit pour stocker de manière sure vos mots de passe. Evidemment, cela ne va pas marcher pour les mots de passe qui permettent d’accéder à la base de données (ou la fameuse question de savoir qui vient avant, la poule ou l’œuf), alors vous devez choisir une autre solution;
  • Hachez les mots de passe des utilisateurs : Si votre logiciel stocke les mots de passe de vos utilisateurs (clients), gardez-les hachés plutôt qu'en texte clair (en savoir plus);
  • Pour serveurs géré par Puppet: Il est évident que certaines données de serveurs gérées via Puppet doivent être protegés, mais leur gestion directe avec le Puppet master n'est pas suffisamment sécurisée. Ce document explique comment faire de son mieux.

Cette liste contient les solutions les plus communes au problème des mots de passe codés “en dur”. Elle n’est pas complète ni définitive – il existe surement beaucoup d’autres solutions qui pourraient convenir à des cas particuliers. N’hésitez pas à envoyez un e-mail à Computer.Security@cern.ch si vous avez des suggestions ou remarques concernant cette liste.