Quel est le meilleur moyen de garder les mots de passe configurables, sans les avoir trop facilement accessibles au lecteur humain occasionnel?

Question

J'ai une base de données à laquelle de nombreuses applications clientes différentes (une poignée de services Web, certaines applications java et quelques applications réseau net) se connectent. Tous ne fonctionnent pas sous Windows (malheureusement, sinon, la question serait facile à répondre en activant simplement l'authentification Windows pour les connexions à la base de données). Pour le moment, les mots de passe sont stockés dans divers fichiers de configuration / propriétés situés autour des systèmes. Idéalement, seul le personnel de support a accès aux serveurs sur lesquels les fichiers sont en cours d'exécution, mais si quelqu'un d'autre accédait à l'un des serveurs, il disposerait d'autorisations de base de données suffisantes pour obtenir une quantité raisonnable de données telles qu'elles sont actuellement.

Ma question alors, quelle est la meilleure façon de garder les mots de passe configurables, sans l'avoir trop facilement accessible au lecteur humain occasionnel?

Modifier À titre d'information, le serveur de base de données est Windows Server 2003, exécutant MSSQL 2005.

PS: Je ne vois aucune question que cela duplique, mais s'il y en a, n'hésitez pas à fermer celle-ci.

Answer 1

Je suppose que vous voulez cacher les mots de passe des observateurs occasionnels. S'ils étaient méchants, les observateurs aux yeux d'acier qui ont accès à tout le code source de l'une des machines connectées peuvent alors obtenir le mot de passe avec un peu d'ingénierie inverse.

N'oubliez pas qu'il n'est pas nécessaire d'utiliser la même protection pour chaque client différent. Quelques étapes: -

1. Créez différents comptes de base de données pour différents systèmes accédant à votre base de données
2. Limitez l'accès à la base de données à ce dont ils ont besoin en utilisant vos GRANT de base de données intégrés
3. Stockez une clé triple DES (ou autre) dans une classe de gestionnaire de mots de passe sur votre base de données. Utilisez-le pour déchiffrer une valeur chiffrée dans votre fichier de propriétés.

Nous avons également envisagé de demander à l’application de saisir une phrase secrète au démarrage, mais nous ne l’avons pas mise en œuvre car cela semble être une douleur et votre personnel des opérations doit alors connaître le mot de passe. C'est probablement moins sécurisé.

Answer 2

Supposons le scénario commun suivant:

• Vous utilisez la même base de code pour tous les environnements et cette base de code contient les mots de passe de base de données pour chaque environnement.

• Le personnel (administrateurs système, gestionnaires de configuration) ayant accès à votre serveur d'applications de production est autorisé à connaître les mots de passe de la base de production et personne d'autre.

• Vous ne voulez pas que quiconque ayant accès au code source connaisse les mots de passe de production.

Dans un scénario comme celui-ci, vous pouvez chiffrer et stocker les mots de passe de production dans les fichiers de propriétés de votre application. Dans l'application, vous pouvez inclure une classe qui lit les mots de passe dans le fichier de propriétés et les déchiffre avant de les transmettre au pilote de base de données. Cependant, la clé et l'algorithme utilisés pour déchiffrer le mot de passe ne font pas partie du code source mais sont plutôt transmis à l'application en tant que propriété système au moment de l'exécution. Cela dissocie la connaissance de la clé du code source de l'application et toute personne ayant accès uniquement au code source de l'application ne sera plus en mesure de déchiffrer le mot de passe car elle n'a pas accès à l'environnement d'exécution de l'application (serveur d'applications).

Si vous utilisez Java, consultez this pour un exemple plus concret. L'exemple utilise Spring et Jasypt. Je suis convaincu que quelque chose comme ceci peut être extrapolé à d'autres environnements tels que .Net

Answer 3

Dans mon ancien lieu de travail, nous avions un système qui chiffrait tous les mots de passe (en utilisant Triple DES ou tout ce que nous utilisions à l’époque). Les mots de passe étaient souvent stockés dans des fichiers de propriétés (c'était dans un système Java).

Lorsque le mot de passe doit être modifié, vous pouvez simplement utiliser "! texte clair". en tant que valeur, puis notre code le chargerait, le chiffrerait, puis stockerait la valeur chiffrée dans le fichier de propriétés.

Cela signifiait qu'il était possible de changer le mot de passe sans connaître la valeur d'origine - vous ne savez pas si c'est le genre de chose que vous demandez!

Answer 4

On dirait qu’il n’ya pas de réponse facile (en raison des différents types d’applications qui se connectent) ... en réalité, le seul problème que je vois est celui des applications Java qui semblent se connecter directement à votre base de données. Est-ce correct?

Si oui, voici ce que vous pouvez faire:

1) Modifiez les applications côté client qui se connectent directement à la base de données pour passer par un service. (S'ils doivent se connecter directement, accordez-leur au moins une première étape pour obtenir le mot de passe d'un service, puis connectez-vous directement).

2) Stockez les mots de passe dans le fichier web.config (si vous avez choisi de faire des services Web .Net), puis chiffrez les "chaînes de connexion". section du fichier.

Answer 5

N'utilisez pas de mots de passe, l'authentification de serveur à serveur peut généralement être effectuée à l'aide d'un fichier de clé, d'un certificat client ou d'une autre manière qu'un mot de passe.

Answer 6

Vous pouvez utiliser un algorithme de chiffrement réversible, par exemple. Blowfish pour stocker les mots de passe comme une solution de rechange. Il devrait y avoir un certain nombre de bibliothèques gratuites que vous pouvez utiliser pour intégrer cela dans tous vos programmes qui ont besoin de cet accès.

La page de Bruce Schneier sur Blowfish

Article sur Wikipedia sur Blowfish

Answer 7

Pour les contenus Java, si vous utilisez un serveur d'applications, voyez si vous pouvez définir une source de données et vos applications peuvent accéder à la source de données à l'aide de JNDI. De cette façon, la gestion de la source de données (y compris les détails de la connexion) est gérée par le serveur d'applications et le code de votre application doit demander une source de données.

Answer 8

L'authentification NTLM ou l'authentification basée sur LDAP (Active Directory) devrait vous être disponible avec un peu d'effort. Cela vous permettrait d'utiliser votre " authentification Windows " à travers les applications.

Cela peut signifier un peu une migration pour votre personnel d'exploitation, mais la connexion unique pour un ensemble d'applications est agréable.

Answer 9

Oui, je suis d’accord avec l’option de stocker les hashs (salés). Je recommanderais un hachage SHA256 (salé) du mot de passe stocké dans la base de données. N'oubliez pas non plus d'appliquer des règles de mot de passe sécurisées.

Answer 10

Utiliser le cryptage n’est pas une bonne idée. Si quelqu'un compromet la clé, il peut la déchiffrer. Utilisez un algorithme de hachage avec salt pour stocker les mots de passe. Les algorithmes de hachage sont à sens unique, donc ce n'est pas réversible. Mais ils sont vulnérables aux attaques par dictionnaire, utilisez donc salt (texte clair concatane avec quelque chose de plus long et plus détaillé que le hachage). Il protège également la base de données contre les attaques internes.