Conserver les mots de passe en toute sécurité lorsque l'accès au texte en clair est toujours nécessaire

Question

Possible Duplicate:
Chiffrement à double sens en PHP : j'ai besoin de stocker des mots de passe qui peuvent être récupérés

Je sais que la meilleure pratique pour stocker les mots de passe des utilisateurs est de stocker uniquement un hachage irréversible du mot de passe.

Cependant, je développe une application où j'aurai besoin de stocker les informations de connexion d'un utilisateur pour un autre service web - je devrai les connecter périodiquement et effectuer certaines tâches de maintenance. Malheureusement, le service n'offre pas de jetons d'autorisation, je dois donc stocker les mots de passe d'une manière qui me permet d'accéder à leurs valeurs en texte brut. Je ne possède ni ne contrôle le service auquel je m'authentifie, et la seule méthode consiste à 'emprunter' un nom d'utilisateur et un mot de passe d'un utilisateur et à s'authentifier.

Je prévois de chiffrer les mots de passe avec AES_ENCRYPT dans la base de données, ce qui signifie que si quelqu'un parvient d'une manière ou d'une autre à accéder à la base de données, il ne pourra pas obtenir de texte en clair. Cependant, mon code devra avoir accès à la clé pour les déchiffrer, donc si tout le serveur est compromis, il n'y a pas de protection et les mots de passe seront révélés.

En dehors du chiffrement décrit ci-dessus, existe-t-il des meilleures pratiques ou des mesures que je peux prendre pour faire cela le plus sûrement possible ?

ÉDITION

Je sais que quoi que je fasse, finalement les mots de passe doivent être accessibles en clair et donc un serveur compromis signifie que les mots de passe seront révélés, mais je me demande quelles mesures je peux prendre pour atténuer mon risque. Par exemple, chiffrer la base de données me protège dans la situation où la base de données est compromise mais pas l'ensemble du serveur. D'autres mesures d'atténuation similaires seraient grandement appréciées.

Answer 1

Cependant, je développe une application où j'aurai besoin de stocker les informations de connexion d'un utilisateur pour un autre service web -- je devrai les connecter périodiquement et effectuer certaines tâches de maintenance.

D'accord... J'ai lu les réponses et les commentaires, et tout ce que je peux dire, c'est que j'espère que vous avez une équipe juridique solide. Il me semble que le service que vous offrez repose sur la confiance des utilisateurs. C'est bien que ce soit un interrupteur contrôlé par l'utilisateur, et non quelque chose qui se fait discrètement dans leur dos, mais je pense que vous avez besoin d'un accord de service vraiment solide à ce sujet.

Cela dit, il y a beaucoup de paranoïa en matière de sécurité que vous pouvez invoquer. Vous devrez déterminer dans quelle mesure vous voulez aller en fonction du préjudice causé à votre produit, à votre entreprise et aux utilisateurs en cas d'intrusion. Voici quelques réflexions :

• Stockage des données - stockez les mots de passe loin de l'endroit où un attaquant pourrait y accéder. Fichiers hautement contrôlés, une base de données sur une machine en arrière-plan, etc. Faites en sorte qu'un attaquant doive passer par des couches de défense pour accéder à l'endroit où les données sont stockées. De même, mettez en place une protection réseau comme des pare-feu et des correctifs de sécurité à jour. Aucun élément ne fonctionne isolément ici.
• Chiffrement - toute technique de chiffrement est une tactique de retardement - une fois que l'attaquant a vos données, il finira par casser votre chiffrement avec un temps infini. Donc, surtout, vous visez à les ralentir suffisamment longtemps pour que le reste du système découvre que vous avez été piraté, alerte vos utilisateurs et leur donne le temps de changer de mot de passe ou de désactiver leurs comptes. À mon avis, soit la cryptographie symétrique, soit la cryptographie asymétrique fonctionnera - tant que vous stockez la clé de manière sécurisée. Étant donné que je suis une personne de PKI, j'opterais plutôt pour le cryptage asymétrique simplement parce que je le comprends mieux et je connais un certain nombre de solutions matérielles COTS qui rendent possible le stockage de ma clé privée de manière extrêmement sécurisée.
• Stockage des clés - votre chiffrement n'est aussi bon que votre stockage de clés. Si la clé est juste à côté des données chiffrées, il est logique que l'attaquant n'ait pas besoin de casser votre chiffrement, il utilise simplement la clé. Les HSM (modules matériels de sécurité) sont le choix haut de gamme pour le stockage des clés - dans les gammes supérieures, ce sont des boîtes sécurisées qui sont à l'épreuve des intrusions et qui contiennent vos clés et effectuent également le chiffrement pour vous. Dans les gammes inférieures, un jeton USB ou une carte à puce pourrait remplir la même fonction. Une partie critique de cela est qu'en fin de compte, il est préférable que vous fassiez en sorte qu'un administrateur active l'accès à la clé lors du démarrage du serveur. Sinon, vous vous retrouvez avec un scénario du "œuf ou de la poule" alors que vous essayez de trouver comment stocker de manière sécurisée le mot de passe ultime.
• Détection d'intrusion - mettez en place un bon système qui a de bonnes chances d'émettre des alarmes en cas de piratage. Si vos données de mot de passe sont compromises, vous voulez informer vos utilisateurs bien avant toute menace.
• Journalisation des audits - gardez de très bons enregistrements de ce que les utilisateurs ont fait sur le système - notamment à proximité de vos mots de passe. Bien que vous puissiez créer un système assez impressionnant, la menace des utilisateurs privilégiés faisant quelque chose de mauvais (ou stupide) est tout aussi grave que les menaces externes. Les systèmes de journalisation haut de gamme typiques suivent le comportement des utilisateurs à haut privilège d'une manière qui ne peut être consultée ou modifiée par l'utilisateur à haut privilège - à la place, il existe un deuxième compte "auditeur" qui ne s'occupe que des journaux d'audit et rien d'autre.

Ceci est un résumé des points forts de la sécurité du système. Mon point général est le suivant : si vous prenez au sérieux la protection des mots de passe des utilisateurs, vous ne pouvez pas vous permettre de ne penser qu'aux données. Le simple chiffrement des mots de passe n'est probablement pas suffisant pour protéger vraiment les utilisateurs et sauvegarder leur confiance.

La méthode standard pour aborder cela est de considérer le coût de l'exploitation par rapport au coût de la protection. Si les deux coûts sont trop élevés par rapport à la valeur de la fonction, alors vous avez une bonne indication que vous ne devriez pas vous embêter à le faire...

Answer 2

Comme vous l'avez dit, votre code finira par avoir besoin de la clé et donc si le serveur est compromis, les mots de passe le seront également. Il n'y a pas moyen de contourner cela.

Ce que vous pouvez faire est d'avoir un proxy très minimal dont le seul travail sera d'avoir les mots de passe, d'écouter les requêtes de votre application principale, de se connecter au service en question, et de renvoyer la réponse à votre application. Si ce proxy très simple est tout ce qui s'exécute sur un serveur, il sera bien moins susceptible d'être compromis qu'une application compliquée tournant sur un serveur avec de nombreux services.