Comment stocker des mots de passe en toute sécurité sur un service Web tiers dans ma base de données?

Question

J'ai besoin de stocker un mot de passe tiers dans notre base de données de configuration, afin que l'utilisateur puisse sauvegarder ses informations de connexion pour un service web accessible via notre serveur.

J'ai besoin de passer le mot de passe au service Web, donc je ne peux pas simplement hacher le mot de passe et stocker le hachage. Je dois être en mesure d'obtenir le mot de passe réel pour l'envoi au service. Pour des raisons de sécurité, je voudrais crypter le mot de passe que nous stockons dans la base de données. Tout ce que je recherche en ce qui concerne le cryptage des mots de passe semble dire «hachez-le, ne le cryptez pas! mais je ne pense pas que cela s'applique dans ce cas.

Je me demande s'il est préférable de gérer le cryptage/décryptage dans le code VB.NET ou utiliser SQL Server pour l'accomplir (ce que je vois here, il est au moins possible de le faire dans SQL, mais je Je ne sais pas si cela a du sens, je dois en faire plus pour connaître les problèmes de déploiement.

Answer 1

Je suis d'accord avec George Stocker. Si vous pouvez utiliser le protocole existant - allez-y (cela réduira de dix fois le nombre de problèmes possibles et de vulnérabilités de sécurité). Juste dans le cas, si vous n'avez plus d'options (vous ne pouvez utiliser aucun protocole). Si vous avez besoin d'accéder à webserver 3ème partie uniquement lorsqu'un utilisateur fait quelque chose sur votre serveur, je recommande ce qui suit:

• Ne pas stocker les mots de passe dans votre DB

• Créer un cookie avec un mot de passe Service tiers et crypter avec une clé secrète. Envoyer ce cookie à un utilisateur.

• Dès que l'utilisateur reviendra sur votre site, vous obtiendrez des cookies, le décrypter, obtenir un mot de passe de cookie et l'utiliser pour accéder à un service web de tiers.

Ainsi, dans le cas, si quelqu'un va pirater votre serveur et copier la base de données, ils ne seront pas des mots de passe à webservices 3ème partie. Dans ce cas, si quelqu'un pirate les ordinateurs des utilisateurs, tous les cookies sont cryptés, de sorte qu'ils ne pourront rien faire avec eux.

La seule faiblesse de sécurité, si quelqu'un sera en mesure d'injecter du code dans votre serveur et capturer les mots de passe des sessions utilisateurs actifs.

Answer 2

D'une manière générale, il est préférable de hacher les mots de passe, mais dans votre cas cela ne semble pas possible. Je ne recommanderais certainement pas le cryptage avec une clé symétrique sur le serveur SQL lui-même, la raison en est que si votre serveur SQL est compromis, votre cryptage est également compromis (parce que la clé sera sur ce même serveur).

Une chose que je recommanderais est que vous utilisiez un magasin temporaire quelque part, cela pourrait être quelque chose comme dans la session. Cependant, faites attention aux sessions et aux cookies car vous pouvez devenir vulnérable aux attaques CSRF et aux attaques de détournement de session/cookie. Une chose que vous pouvez faire est de demander à l'utilisateur de saisir le mot de passe, puis de le chiffrer et de le stocker dans son cookie, en ajoutant son adresse IP dans le cookie, puis d'ajouter un horodatage pour l'expiration au début. vous changez les bits au début de votre texte en clair).Exiger que pour qu'une demande au service Web soit faite qu'ils attachent un jeton CSRF qui est rendu sur le côté client et que ce soit un POST pas un get, enfin valider l'IP client et que l'horodatage ne soit pas plus ancien que x minutes/heures (en fonction de la façon dont vous voulez être paranoïaque). Si le cookie des utilisateurs est volé, ils ne pourront pas faire la demande car elle est spécifique à leur IP client (à moins qu'ils usurpent l'adresse IP de l'utilisateur mais à ce moment-là vous vous rendez compte que cet attaquant n'est pas très intelligent Je suis sûr qu'il y a d'autres vecteurs d'attaque plus faciles qui leur donneront une plus grande charge utile). Si l'utilisateur est en mesure d'usurper l'adresse IP, il ne pourra pas l'utiliser longtemps car le délai d'expiration rendra le cookie nul. Et si l'utilisateur est assez intelligent pour briser votre algorithme de cryptage bien ... alors vous n'avez pratiquement aucune chance en premier lieu.