(Remarque :je ne suis pas un expert en sécurité. J'ai un intérêt pour le domaine, mais c'est tout. Gardez cela à l'esprit.)
Si possible, ne stockez pas du tout les mots de passe
Cela dépend beaucoup de vos besoins. La meilleure option est de ne pas utiliser du tout le cryptage bidirectionnel; si vous ne pouvez stocker que salé et one-way-hash des résumés de mots de passe, c'est l'idéal. Vous pouvez toujours les tester pour voir s'ils correspondent à un mot de passe fourni par l'utilisateur, mais vous ne le stockez jamais.
Mieux encore, si vos clients utilisent un protocole sain (c'est-à-dire :pas HTTP tel qu'il est couramment implémenté), vous pouvez utiliser un mécanisme d'authentification challenge-réponse cela signifie que votre application ne jamais a besoin de voir le mot de passe de l'utilisateur, pas même lors de son authentification. Malheureusement, cela est rarement possible sur le Web public, dont la sécurité ferait honte aux programmeurs des années 80.
Si vous devez stocker le mot de passe, isolez les clés de l'application
Si vous devez être capable de déchiffrer les mots de passe, idéalement, vous ne devriez pas avoir tous les détails pour le faire en un seul endroit, et certainement pas un seul endroit copiable et facilement accessible.
Pour cette raison, je préférerais personnellement ne pas utiliser PgCrypto (comme vous le faites) à cette fin, car cela vous oblige à révéler la clé privée et (s'il en a une) la phrase secrète au serveur, où elle pourrait être exposée dans PostgreSQL. fichiers journaux ou autrement potentiellement sniffés. Je voudrais faire mon côté client crypto, où je pourrais utiliser PKCS # 11, un agent de clé ou d'autres outils qui me permettent de déchiffrer les données sans jamais que mon code puisse accéder à la clé.
Le problème du stockage sécurisé des clés fait partie de ce que PKCS#11 a été inventé pour. Il fournit une interface générique pour les applications et les fournisseurs de chiffrement pour parler à tout ce qui peut fournir certains services de signature et de déchiffrement sans jamais révéler sa clé . L'utilisation habituelle, mais pas seulement, est avec la cryptographie basée sur le matériel comme les cartes à puce et les modules cryptographiques matériels. Ces appareils peuvent être invités à signer ou à déchiffrer les données qui leur sont transmises, et peuvent le faire sans jamais révéler la clé. Si possible, envisagez d'utiliser une carte à puce ou un HSM. Autant que je sache, PgCrypto ne peut pas utiliser PKCS#11 ou d'autres HSM/cartes à puce.
Si vous ne pouvez pas le faire, vous pouvez toujours utiliser un agent de gestion de clés, où vous chargez manuellement votre clé dans un programme de gestion de clés lorsque le serveur démarre, et le programme de gestion de clés fournit une interface PKCS#11 (ou une autre) pour la signature et le déchiffrement via un socket. De cette façon, votre application Web n'a jamais besoin de connaître la clé. gpg-agent peuvent être éligibles à cet effet. Encore une fois, pour autant que je sache, PgCrypto ne peut pas utiliser d'agent de gestion de clés, même si ce serait une excellente fonctionnalité à ajouter.
Même une petite amélioration peut aider. Il est préférable que la phrase secrète de votre clé ne soit pas stockée sur le disque. Vous devrez donc peut-être la saisir au démarrage de l'application afin que la clé puisse être déchiffrée. Vous stockez toujours la clé déchiffrée en mémoire, mais tous les détails pour la déchiffrer ne sont plus sur le disque et faciles à obtenir. Il est beaucoup plus difficile pour un attaquant de voler la clé déchiffrée de la mémoire que de récupérer un "password.txt" sur le disque.
Ce que vous choisissez de faire dépend beaucoup des détails de vos besoins en matière de sécurité et des données avec lesquelles vous travaillez. Dans votre position, je ne stockerais tout simplement pas les mots de passe si possible, et si je devais le faire, je voudrais utiliser un périphérique matériel compatible PKCS#11.
