Où et comment devrais-je stocker les mots de passe DB de base?

Question

J'ai une application Web de base qui utilise un DB distinct mais identique pour chaque «locataire» du système. Il y a un DB principal qui contient une table reliant chaque utilisateur à leur copie de la DB.

À l'heure actuelle, tous les détails de la connexion BD de client sont stockés en clair dans la table principale. Je sais que ce n'est pas bon et n'est qu'une mesure temporaire afin que je puisse continuer à écrire des fonctionnalités.

Je ne peux penser à deux façons de sécuriser les détails de connexion (voir ci-dessous), qui semblent toutes deux imparfaites, alors j'espérais des conseils, si cela ne vous dérange pas, s'il vous plaît?

1. utiliser une certaine forme de méthode de sel et de hachage pour stocker les mots de passe, la clé stockée dans un fichier local sur l'application a accès.

2. Utilisez un service tiers (tel que Amazon KMS) pour chiffrer l'intégralité de la base de données maître.

La deuxième option que je suppose est la plus sûre, mais je suis dépendante sur un plugin DB Je ne comprends pas bien et un service 3ème partie qui réduira les performances. Mon problème avec ces deux choses, c'est que si quelqu'un était capable d'injecter une requête SELECT dans mon code et accéder à la table maître (FYI, toutes les variables de requête sont liées comme paramètres), il décryptera toujours les mots de passe indépendamment de quelle méthode j'utilise. Est-ce toujours le cas et quelque chose que nous acceptons, ou y a-t-il une autre couche de sécurité pour empêcher les éventuels attaquants?

Merci!

Answer 1

Bonne question. Pas sûr que j'ai la réponse, mais quelques considérations:

Considérons d'abord la solution (1) - hachage de mot de passe.

En cas d'injection SQL ou d'une vulnérabilité similaire dans votre base de données master, le mot de passe ne sera pas déchiffré. Au lieu de cela, il permet au hacker d'obtenir le hash du mot de passe, qu'il pourrait essayer d'inverser via une force brute ou une attaque connexe. Si vous faites password hashing the wrong way, alors l'attaquant va probablement réussir. D'autre part, si vous utilisez un algorithme comme bcrypt (/ scrypt/argon2/pbkdf2) avec de bons paramètres, alors vous avez une meilleure chance de résister. De plus, si un attaquant peut injecter des requêtes SQL dans votre base de données master, il peut aussi y lire et y écrire (vous pouvez tenter d'atténuer ce risque en utilisant des requêtes de lecture). avec un compte DB qui n'a pas d'accès en écriture). Si l'attaquant peut écrire dessus, alors il peut écraser le vrai mot de passe avec un mot de passe de son choix, donc il gagne quand même. En regardant la deuxième solution, je crois que vous avez raison de dire qu'une vulnérabilité d'injection sera simplement transmise au service tiers. Le cryptage ne vous aide pas dans ce cas. Toutefois, si vous avez également correctement haché les mots de passe, le scénario de l'attaquant devient le même que celui du scénario (1). Par conséquent, ce que vous obtenez du service tiers n'atténue pas votre inquiétude.

Donc, en général, je dis que vous devez absolument faire une solution (1). Cependant, la question devient vraiment ce que vous pouvez faire de plus? C'est une longue conversation en soi. Une réponse facile est l'authentification à deux facteurs, mais cela peut devenir ennuyeux pour les utilisateurs.D'un autre côté, vous pouvez envisager une authentification à deux facteurs uniquement lorsque l'utilisateur provient d'une nouvelle adresse IP ou d'un nouvel appareil, ce qui allie sécurité et exigences d'utilisation.