Quelle est la meilleure façon de garder les mots de passe configurable, sans avoir trop facilement disponibles pour le simple lecteur humain?

Question

J'ai une base de données que beaucoup de différentes applications client (une poignée de services web, certaines applications java et un peu de dot net applications) connecter. Pas tous ces éléments sont en cours d'exécution sur windows (Malheureusement, sinon, il pourrait faire de ce facile à répondre à la question avec juste l'activation de l'authentification windows pour les connexions de base de données). Pour le moment, les mots de passe sont stockés dans différentes configuration / propriétés des fichiers qui traînent les systèmes. Idéalement, seul le personnel de soutien ont accès aux serveurs où les fichiers sont en cours d'exécution, mais si quelqu'un d'autre accède à l'un des serveurs, ils ont assez d'autorisations de base de données pour obtenir une juste whack de données tel qu'il est actuellement.

Ma question alors, Quelle est la meilleure façon de conserver les mots de passe configurable, sans l'avoir trop facilement disponibles pour le simple lecteur humain?

Edit Juste pour clarifier, DB server Windows Server 2003, l'exécution de MSSQL 2005.

PS: je ne vois pas à toutes les questions que cette doublons, mais si il existe, n'hésitez pas à fermer celui-ci.

Answer 1

Je suis en supposant que vous souhaitez masquer les mots de passe de l'observateur occasionnel. Si elles étaient mauvaises, steely aux yeux des observateurs, avec accès à tout le code source sur une des machines qui se connecte, ensuite, ils peuvent obtenir le mot de passe avec un peu de reverse engineering.

N'oubliez pas que vous n'avez pas besoin d'utiliser le même niveau de protection différent pour chaque client. Quelques étapes:-

1. Créer différents comptes de base de données pour les différents systèmes d'accès à votre base de données
2. Limiter l'accès de la base de données que ce qu'ils ont besoin de l'aide de votre intégré de la base de données des Subventions
3. Stocker une triple DES (ou autre) de la clé à l'intérieur d'un gestionnaire de mot de passe classe de votre base de données. L'utiliser pour déchiffrer une valeur chiffrée dans votre fichier de propriétés.

Nous avons également examiné l'application demande un mot de passe au démarrage, mais n'ont pas mis en œuvre ce qu'il semble comme une douleur et votre personnel d'exploitation alors besoin de connaître le mot de passe. C'est probablement moins sûr.

Answer 2

Supposons le même scénario:

• Vous utilisez le même code de base pour tous les environnements et votre base de code a la base de données des mots de passe pour chaque environnement.

• Le personnel (les administrateurs système, configuration des gestionnaires) qui ont accès à votre application en production du serveur sont autorisés à savoir la production de la base de données des mots de passe et personne d'autre.

• Vous ne voulez pas que quiconque ayant accès au code source pour savoir ce que la production de mots de passe.

Dans un tel scénario, vous pouvez crypter et stocker la production de mots de passe dans les fichiers de propriétés de votre demande. Au sein de l'application, vous pouvez inclure une classe qui lit les mots de passe du fichier de propriétés et déchiffre à l'avant de la transmettre au pilote de base de données. Toutefois, la clé et de l'algorithme utilisé pour déchiffrer le mot de passe ne font pas partie du code source, mais plutôt passés à l'application en tant que système de la propriété au moment de l'exécution. Cette découple la connaissance de la clé à partir du code source de l'application et de toute personne ayant accès à l'application du code source ne sera plus en mesure de décrypter le mot de passe car ils n'ont pas accès à l'application de l'environnement d'exécution (serveur d'application).

Si vous utilisez Java jeter un oeil à ce pour un exemple plus concret. L'exemple utilise le Printemps et l'Jasypt. Je suis convaincu que quelque chose comme cela peut être extrapolés à d'autres environnements, comme .Net

Answer 3

Dans mon ancien lieu de travail, nous avons utilisé pour avoir un système dans lequel tous les mots de passe chiffrés (à l'aide de Triple DES ou ce que nous utilisions à l'époque). Les mots de passe sont souvent stockées dans des fichiers de propriétés (ce qui était un système Java).

Lorsque le mot de passe doit être modifié, on peut simplement utiliser "!en clair" comme valeur, et notre code de la charge vers le haut, chiffrer et stocker la valeur chiffrée de retour dans le fichier de propriétés.

Cela signifiait qu'il était possible de changer le mot de passe sans savoir ce que la valeur d'origine - pas sûr si c'est le genre de chose qui vous demandant!

Answer 4

Il sonne comme il n'y a pas de réponse facile (en raison des différents types d'applications qui se connectent)... vraiment, le seul problème que je vois est la Java des Applications qui semblent se connecter directement à votre base de données. Est-ce exact?

Si oui, voici ce que vous pouvez faire:

1) Changer toutes les applications client qui se connectent directement à la DB de passer par un service. (S'ils ont à se connecter directement, du moins de leur donner une première étape pour obtenir "mot de passe" à partir d'un service, alors ils peuvent se connecter directement).

2) Stocker les mots de passe dans le web.fichier de configuration (si vous avez choisi de faire .Net web services), puis crypter les "chaînes de connexion" de la section du fichier.

Answer 5

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