Normes de chiffrement des mots de passe dans les fichiers de configuration?
Mon lieu de travail a une norme qui interdit les mots de passe en texte brut dans les fichiers de configuration d'application. Cela est suffisamment logique à première vue, au cas où quelqu'un aurait accès aux fichiers de configuration, il n'aurait pas automatiquement accès à tous les privilèges de cette application. Dans certains cas, il est possible et évidemment préférable d'avoir un accès associé à la connexion ou d'éviter autrement d'avoir un mot de passe, comme dans l'authentification Windows Security for SQL Server, ou de le configurer dans un emplacement tiers, tel que la configuration JDBC dans un environnement J2EE , mais ce n'est pas toujours possible.
- Lorsque je dois avoir un mot de passe dans un fichier de configuration, quel niveau de cryptage doit-il transporter?
- Comment gérez-vous le fait que la clé de cryptage du mot de passe doit être codée en dur ou stockée dans un autre fichier de configuration?
- Les clés de cryptage du mot de passe doivent-elles être lisibles par l'homme?
Donc, ce qui suit était un peu trop long pour un commentaire ...
Il serait peut-être utile de prendre un peu de recul et de comparer les avantages des contrôles préventifs et de détection. Les contrôles préventifs incluent le cryptage, mais vous pouvez également coder le mot de passe pour le rendre moins évident. Cette approche vise à protéger le mot de passe d'un partage accidentel (un codage b32 produirait des caractères moins significatifs (b32 produit une chaîne plus longue que b64). Une telle approche augmente simplement la difficulté de mémoriser la séquence aléatoire de nombres ainsi que la méthode qui devrait Le codage Base32/64 est un moyen simple de protéger les mots de passe qui ne nécessitent pas de logique supplémentaire pour être construits/maintenus.
Les autres approches des contrôles préventifs utiliseraient probablement le chiffrement. Il existe différentes manières de protéger la clé. Sans entrer dans les détails ni réitérer ce que D.W. déjà publié, vous pouvez superposer des contrôles de détection pour améliorer la sécurité. Par exemple, vous pouvez auditer l'accès à un fichier qui contient la clé. Vous pouvez corréler les événements (tels que le redémarrage du serveur/service) avec l'accès au fichier de clés. Toute autre demande d'accès (réussie ou non) au fichier de clé pourrait indiquer une activité anormale.
Pour répondre à vos questions, voici mon avis:
si vous devez stocker le mot de passe dans un fichier de configuration, je vous recommande au moins d'encoder le mot de passe si possible. L'encodage du mot de passe réduirait les risques de fuite dans le cas où quelqu'un ferait défiler le fichier, par exemple avec un représentant du support technique qui regarde. Le cryptage du mot de passe est beaucoup plus sûr, mais cela nécessite une complexité supplémentaire.
Comment gérer le fait qu'une clé doit être codée en dur ou stockée dans un autre fichier. Eh bien, la séparation de la clé de chiffrement dans un autre fichier augmente la difficulté pour quelqu'un d'afficher la clé. Par exemple, vous pouvez utiliser le contrôle d'accès pour limiter l'accès au fichier de clé mais conserver une ACL plus ouverte pour le fichier de configuration. De même, vous pouvez implémenter l'audit pour accéder au fichier de clés, que vous pouvez utiliser pour établir une corrélation avec les événements qui nécessitent l'utilisation de la clé. Le codage en dur de la clé peut être correct si vous limitez l'accès au binaire. Un encodage soigneux du mot de passe peut facilement être détecté en exécutant une "chaîne" contre le binaire. Vous pouvez encoder/chiffrer le mot de passe codé en dur (c'est-à-dire exiger une fonction distincte (peut-être avec un audit) quand décoder le mot de passe, mais cela augmente la complexité pour le développeur et l'administrateur (c'est-à-dire comment changer la clé sans reconstruire/recompiler le binaire) ?).
Les clés de cryptage du mot de passe doivent-elles être lisibles par l'homme? Ça dépend. Il n'y a qu'un nombre limité de façons de protéger la clé. Une clé de chiffrement est généralement considérée comme une chaîne alphanumérique difficile à enregistrer en mémoire. Vous pouvez toujours encoder/chiffrer la clé, mais ces méthodes ne dissuadent pas quelqu'un qui est assez intelligent pour prendre une capture d'écran. Cependant, vous pouvez utiliser de simples "touches" (plus comme des mots de passe) comme entrée pour une fonction d'extension de touches. Dans ces cas, des mesures supplémentaires telles que le codage ajoutent peut-être une valeur supplémentaire par rapport au coût de la complexité.
Si quoi que ce soit, une bonne approche consiste à implémenter plusieurs couches de contrôles. Les contrôles préventifs sont plus difficiles tandis que les contrôles de détection sont généralement plus faciles à mettre en œuvre. La séparation des fichiers clés pourrait simplifier l'architecture globale et la mise en œuvre des contrôles. Indépendamment du fait que des contrôles préventifs ou de détection soient utilisés, l'activation de certaines fonctions d'audit est indispensable ainsi que l'examen des journaux d'audit. De cette façon, si l'improbable se produit (accès à la clé), vous pouvez prendre des mesures correctives.
Si vous exécutez un serveur qui a besoin d'un mot de passe pour accéder à un service distant, il n'y a pas de bonne solution. Le stockage du mot de passe dans un fichier de configuration stocké dans un emplacement approprié fait probablement le meilleur choix parmi de mauvais choix.
Les choix sont les suivants: demander à un utilisateur d'entrer le mot de passe au démarrage (c'est mauvais, car si votre serveur est redémarré, le serveur est désormais inaccessible jusqu'à ce qu'une personne puisse physiquement se rendre sur le serveur et entrer le mot de passe); coder en dur le mot de passe dans le code source du code serveur (c'est bien pire que de le mettre dans un fichier de configuration); ou stockez le mot de passe dans un fichier de configuration (le moins mauvais de toutes les options). La principale chose à surveiller avec le fichier de configuration est de vous assurer qu'il est stocké en dehors de votre racine Web et que ses autorisations de fichier sont verrouillées de manière appropriée.
Le cryptage du mot de passe stocké dans le fichier de configuration n'aide pas, car maintenant où stockez-vous la clé de décryptage? Vous venez de déplacer le problème. "C'est des tortues tout le long" n'est pas une réponse acceptable.
Sous Windows, une autre option que vous pourriez envisager est de stocker le mot de passe dans DPAPI. Cela aide un peu pour les applications de bureau, mais n'est pas très utile pour les serveurs sans surveillance.
Pour en savoir plus, lisez les questions suivantes sur ce site: Stockez un mot de passe pour éviter l'interaction de l'utilisateur , où stocker une clé pour le cryptage , Comment les projets open source gérer des artefacts sécurisés? , Comment puis-je décrypter des données avec Java, sans coder en dur la clé? , Mot de passe dans le fichier .php , Où faire Je stocke en toute sécurité la clé d'un système où la source est visible? .
P.S. En principe, vous pouvez utiliser un module de plateforme sécurisée pour stocker le mot de passe - mais en pratique, cela vous amène à des problèmes de saignement, donc ce n'est probablement pas viable pour la plupart des gens.
Stockez le mot de passe dans une variable d'environnement utilisateur O/S (hors session) et exécutez le programme en tant qu'utilisateur.
Avantages:
Vous ne vérifierez jamais accidentellement le mot de passe dans le contrôle de code source car il n'y a aucun fichier à archiver.
Si vous bousiller les autorisations de fichier sur votre fichier de configuration (ce qui n'arrive jamais?), Vos mots de passe ne sont pas compromis
Ne peut être lu que par l'utilisateur ou root (identique à un fichier de configuration, identique à une clé privée protégeant un fichier crypté)
Si vous cryptez le fichier, comment sécurisez-vous votre clé?
Effacez vos envvars avant de commencer de nouveaux processus, car ils peuvent être transmis
Un avantage d'un HSM est que même si l'utilisateur ou root peut tiliser le HSM pour décrypter une valeur, il ne peut jamais y trouver la clé.
Le stockage de mot de passe local est un long problème que je traitais. puisque le cryptage ne sera pas à l'épreuve des balles, mais peut aider, il y a peu d'autres options:
- stocker les mots de passe sur la machine locale dans un nouveau fichier (qui sera également mieux crypté) et restreindre l'accès au fichier
- stocker les mots de passe sur un autre serveur, qui s'authentifiera via OAUTH ou tout autre service d'authentification - consultez tahoe-lafs: https://tahoe-lafs.org/trac/tahoe- lafs
- à l'aide d'un service local chiffré qui stocke les mots de passe et y accède à l'aide d'un certificat
- certaines organisations stockent ses mots de passe sous forme de clés de registre ou avec DPAPI - http://msdn.Microsoft.com/en-us/library/ms995355.aspx
- en utilisant OTP en utilisant le service de gestion de compte
- utiliser un serveur proxy pour accéder à des données confidentielles et restreindre l'accès au proxy
.
et pour vos questions:
Lorsque je dois avoir un mot de passe dans un fichier de configuration, quel niveau de cryptage doit-il transporter?
vous n'avez jamais besoin d'avoir des mots de passe dans votre code, mais c'est la manière la plus simple et la moins sécurisée.
Comment gérez-vous le fait que la clé de cryptage du mot de passe doit être codée en dur ou stockée dans un autre fichier de configuration?
utilisation des restrictions d'accès et surveillance du fichier
Les clés de cryptage du mot de passe doivent-elles être lisibles par l'homme? si vous voulez dire des mots de passe forts et lisibles par l'homme, il n'y a aucun problème du tout
Mon 2 cents ici est que, pour une sécurité parfaite, vous voudriez que l'application soit capable de faire quelque chose (lire un mot de passe) qu'un attaquant sur la machine physique avec les mêmes privilèges ne devrait pas être capable de faire, ce qui semble une contradiction .
Au mieux, vous pourriez masquer le mot de passe dans la configuration ( Base64 , saisir quelque part sur l'ordinateur, etc ...)