Sécurisation des mots de passe DB


18

En regardant la structure de la plupart des sites Web basés sur PHP / MySQL que j'ai vus, il semble qu'il n'est pas très difficile de discerner le mot de passe de la base de données si vous creusez un peu, car il y a toujours un fichier d'installation ou de configuration quelque part qui stocke les informations pour la journalisation dans la DB. Outre la précaution de base de m'assurer que les privilèges de ma base de données sont correctement restreints pour les requêtes distantes, quelles options sont disponibles que je pourrais implémenter dans mes propres projets pour protéger ces informations?


1
Pour clarifier - vous demandez sur le stockage des informations d'identification pour vous connecter à la base de données à partir du site Web, et pas sur la façon de stocker correctement les mots de passe des utilisateurs du site Web dans la base de données, n'est-ce pas?
Joe

Correct; c'est à cela que je veux en venir.
Kaji

Réponses:


10

Pas une réponse directe sur le stockage des mots de passe, mais j'utilise généralement au moins deux connexions à la base de données lors de la création d'applications Web - l'une est utilisée à 99% du temps pour les activités liées à l'utilisateur, avec des privilèges restreints, et l'autre est utilisée pour la fonctionnalité «admin» (supprimer des utilisateurs, etc.).

Dans quelques cas, où j'installe le package de quelqu'un d'autre, j'installe deux instances ... une instance ouverte au public qui n'a accès à la base de données que pour effectuer les tâches générales de type utilisateur, et une deuxième instance limitée par IP à mon sous-réseau local (peut-être même sur une autre machine) qui doit être utilisé pour toutes les activités de type «admin». Aucun des deux n'a accès à la modification des tables, etc., cependant ... Je préfère entrer via les outils de base de données natifs plutôt que de permettre à la webapp d'exécuter ses propres tâches de mise à jour qui n'ont pas été vérifiées.

Vous pouvez aller encore plus loin et ajouter plus de connexions spécifiquement pour des tâches données ... afin que les tâches de création d'utilisateur et de gestion des mots de passe passent par un utilisateur qui a des privilèges supplémentaires sur les tables d'utilisateurs, la connexion a des privilèges de base de données à authentifier et pas grand-chose d'autre , etc.

De cette façon, s'il y a une attaque par injection sql, sur la plupart des pages Web, il ne peut pas vraiment faire quoi que ce soit de significatif - ne peut pas voir les hachages de mot de passe, ne peut pas ajouter un nouvel utilisateur administrateur (pas qu'ils pourraient le faire) quoi que ce soit de toute façon), etc. Cela n'aidera toujours pas s'ils parviennent à obtenir un shell sur votre machine, mais cela les ralentira.


1
Nous faisons quelque chose de similaire. Cependant, nous créons généralement un nouveau compte pour chaque utilisateur / application de la base de données au lieu de le faire par fonctionnalité. Cela résout deux problèmes pour nous - 1) nous pouvons différencier l'utilisation de la base de données dans des outils comme OEM (c.-à-d., Nous pouvons voir qui martèle la base de données avec granularité) et 2) nous pouvons personnaliser individuellement ce que chaque utilisateur voit et a accès dans le base de données.
ScottCher


4

Je suis un grand fan de l'utilisation de l'authentification 'Ident' de PostgreSQL sur les sockets locaux chaque fois que je le peux. De cette façon, les utilisateurs locaux sont directement mappés aux utilisateurs Unix / Windows de l'ordinateur local, et je n'ai pas du tout à me soucier de stocker des mots de passe. Cependant, je ne pense pas que ce soit une option dans MySQL.

Lorsque la base de données et le serveur Web se trouvent sur deux machines distinctes, j'utilise des mots de passe MD5 sur SSL: si un hostile a accès à mon serveur frontal, ce n'est qu'une question de temps avant qu'il ne comprenne comment il communique avec la base de données.


3

Si vous utilisez le .NET Framework, vous pouvez envisager d'utiliser des chaînes de connexion chiffrées. Je ne sais pas si une telle chose est possible dans d'autres langages / frameworks, mais ce serait une autre sauvegarde pour s'assurer que vos connexions ne sont pas compromises.

En dehors de l'utilisation de chaînes de connexion chiffrées, l'utilisation de LDAP / Kerberos / Active Directory sera votre option la plus sûre.


3

Si vos mots de passe sont stockés en texte brut, utilisez les hachages (MD5, SHA), Luke!


L'OP ne demande pas de stocker les mots de passe des utilisateurs. Mais oui, hachez certainement vos mots de passe utilisateur, mais n'utilisez jamais MD5 ou la famille SHA pour le faire! Utilisez bcrypt ou PBKDF2. Sinon, vous vous retrouverez bientôt dans l'actualité comme ces sociétés qui utilisaient MD5 et SHA1 et exposaient ainsi leurs utilisateurs à de simples attaques par force brute.
Nick Chammas

Bien sûr, le salage et d'autres techniques sont nécessaires en plus du hachage. Et il ne faut jamais implémenter lui-même de primitives de chiffrement, mais plutôt utiliser des bibliothèques de chiffrement largement testées.
Yasir Arsanukaev

2

Selon votre langage de programmation, vous pouvez crypter les informations d'identification de connexion, mais si vous exécutez un langage interprété, il n'y a aucun moyen de garantir que quelqu'un ne puisse pas comprendre les informations d'identification s'il accède au système.

Si vous exécutez C ++ ou similaire, je vous recommande de créer / trouver une fonction de cryptage / décryptage salée et d'exécuter les informations d'identification à travers cela et de stocker le hachage résultant sous forme de fichier sur le système.

Si vous exécutez PHP ou similaire, je vous recommande d'écrire un wrapper pour le mcrypt_encrypt()et de saler les informations d'identification, puis d'exécuter un obscurcissement de code pour ralentir les pirates s'ils parviennent à accéder au système.


Si vous chiffrez les informations d'identification, vous avez besoin d'un autre secret pour les déchiffrer à nouveau. Ou bien, la forme cryptée devient le secret, donc un attaquant pourrait l'utiliser. Quelques détails manquants.
Peter Eisentraut
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.