Comment gérer les mots de passe dans la configuration de l'application

Question

Je travaille sur un système qui interagit avec de nombreuses API système externes: s. La plupart d'entre eux nécessitent une authentification quelconque. Pour des raisons de convivialité, il existe un AppConfig "accessible à l'application" qui stocke les informations de configuration, ainsi que les informations d'identification pour les systèmes externes.

Ma question est de savoir si c'est une mauvaise idée de stocker les noms d'utilisateur et mots de passe (en clair) dans les systèmes externes dans le fichier de configuration de l'application. Si oui, comment l'évitez-vous?

Pour accéder au fichier de configuration, vous devez soit compromettre le système de fichiers du serveur, soit le référentiel git sur un autre serveur (ou, bien sûr, tout système de développement). Je pensais que le cryptage du mot de passe dans le fichier de configuration n'augmente pas le niveau de sécurité, car la clé de cryptage doit également être stockée quelque part. Ai-je tort à ce sujet?

J'apprécierais vraiment les réponses expliquant comment vous avez résolu ce problème.

Solution

Ok, alors voici ma solution finale. J'ai créé une bibliothèque simple en utilisant OpenSSL pour crypter et décrypter mes données sensibles. La clé est extraite de l'utilisateur lorsque la configuration est chargée, sauf sur les serveurs de production où il est stocké dans le fichier. Ce n'est toujours pas une solution optimale, mais c'est bien mieux que la «solution» que j'avais auparavant.

Merci pour vos réponses. J'accepterai la réponse de Wayne car c'était la plus informative.

Answer 1

Une bonne sécurité est difficile. Comme le dit Bruce Schneier, «la sécurité est un compromis.». Vous devez décider si vous voulez obtenir cette information en toute sécurité et combien de temps vous voulez consacrer à la sécurisation de cette information. Et vous ne voulez surtout pas laisser vos mots de passe simplement en texte clair, c'est un non-non. Si vous êtes dans une situation où c'est OK, vous êtes dans une situation où vous ne devriez pas avoir d'authentification de l'utilisateur.

Même si la sécurité est difficile, vous pouvez faire certaines choses.

1) Utilisez un certain type de programme compilé pour effectuer le cryptage/décryptage. Vous ne voulez pas que quelqu'un ouvre un script Python/Perl et dise "aha, c'est juste un simple cryptage XYZ", mais idéalement, vous ne voulez pas un cryptage simple.

2) La sécurité par l'obscurité n'est pas une réelle sécurité, mais elle peut aider contre l'espionnage occasionnel. Par exemple, nommer votre fichier "mot de passe.txt" n'est pas une très bonne idée, mais crypter vos mots de passe, puis utiliser steganography pour cacher l'utilisateur/passer dans un fichier image est préférable.

3) Recherchez des algorithmes de chiffrement/déchiffrement puissants. Certains d'entre eux sont déjà implémentés dans la plupart des langues et vous pouvez simplement importer une bibliothèque. Cela peut être mauvais ou bon, selon la sécurité avec laquelle vous pensez que vous voulez ce genre de choses.

Mais honnêtement, ce système est vraiment mauvais - sécurité sage. Idéalement, vous avez une authentification à deux parties, puis l'intermédiaire de confiance fait tout le tour et traite. Par exemple, lorsque vous vous connectez à votre ordinateur, vous dites à l'ordinateur que vous êtes un utilisateur autorisé. De là, vous exécutez tous vos programmes et ils ne demandent pas ou ne se soucient pas de votre combinaison utilisateur/passe - juste que vous êtes un utilisateur autorisé. Ils obtiennent cette information de l'OS (l'intermédiaire). Heck, même SO utilise openID pour décider que vous êtes un utilisateur de confiance - ils ne se soucient pas de ce que vos informations d'identification sont sur les autres sites, seulement que les autres sites disent "Oui oui, c'est un utilisateur valide."

Si vous avez la possibilité, je considérerais sérieusement passer votre modèle d'authentification. Sinon, bonne chance.

Answer 2

En ce qui concerne des exemples concrets en direct, les serveurs Web les informations de connexion de base de données de stockage sur le serveur, dans le texte brut. Si Quelqu'un obtient l'accès à votre serveur, vous êtes foutu de toute façon, mais protéger ces mots de passe de l'intrus indésirable non désiré, bien personnellement, j'aime la couche supplémentaire pour se sentir plus en sécurité. systèmes, il serait prudent de sécuriser ceux qui ont une autre couche: le cryptage, mais la sécurité à travers l'obscurité est mauvaise, mais ne pensez-vous pas que c'est un excellent terrent si quelqu'un devait trébucher sur eux - Les mots de passe en texte simple ne demandent qu'à être pris. Je recommande l'utilisation du cryptage 1024 bit, il y a a couple good algorhytms. Je recommande également d'utiliser un bit random salt 64/128 pour chaque entrée que vous chiffrez, de sorte que même si le mot de passe d'une entrée est forcé, la solution ne fonctionnera pas sur les autres entrées. Le salage aléatoire empêche les attaques de la table arc-en-ciel, ce qui oblige votre pirate à utiliser la force brute, beaucoup plus de temps.

Oui ces précautions semblent paranoïaques, mais si je tente de craquer mes propres mots de passe (pour l'intérêt de la recherche, bien sûr) je peux imaginer ce que quelqu'un pourrait essayer d'esprit malveillant.

Edit:An example of how the salt makes encryption more secure, even if the encryption key is known.

Answer 3

Certains webbservers doivent charger des certificats chiffrés symétriquement au démarrage. Pour faire face à cela, ils demandent une saisie de mot de passe au démarrage. Alors que c'est seulement stocké en mémoire.

Plus:

• mot de passe principal ne sont jamais stockées sur le disque.
• Le mot de passe principal ne peut pas être extrait de ps fax.

Moins:

• mot de passe principal peut encore être extrait par vidage de la mémoire (par l'utilisateur exécutant le webbserver et la racine).
• Votre processus ne peut pas être redémarré automatiquement sans intervention de l'utilisateur. C'est probablement la principale raison pour laquelle plus de gens ne vont pas avec cette option. Heureusement, les serveurs web tombent rarement en panne.