i * doit * stocker les informations d'identification de tiers dans ma base de données. meilleur moyen?

Question

Mon application doit lire une URL SSL d'un tiers. Comment puis-je mieux stocker les informations d'identification de tiers dans ma propre base de données, ce qui protège les informations d'identification de tiers d'être compromises? Considérez à la fois la sécurité absolue et la praticité. Le hachage unidirectionnel des informations d'identification n'est pas utile car je dois restaurer les informations d'identification en texte brut pour l'appel SSL. J'utilise python sur google app engine, et mon application s'authentifie avec les informations d'identification google.

• crypter les informations d'identification en utilisant par ex. AES et enregistrer la clé de chiffrement quelque part ailleurs (juste déplace le problème), ou derive it from the credentials and keep the algorithm secret (juste déplace le problème)
• informations d'identification Chiffrer à l'aide d'un synchronous stream cipher, déduire la (non) entropie des informations d'identification et keep the algorithm secret (juste déplace le problème)
• sur une application Web distincte dédiée à stocker les informations d'identification de tiers, fournir une URL SSL pour recevoir les informations d'identification de tiers, cette URL est accessible avec google credentials (même que mon application) et peut utiliser authsub ou quelque chose pour transférer l'autorisation à l'autre application web Cela semble plus sûr car il est plus difficile de pirater une application web trivialement simple, et si mon application principale complexe est compromise, les informations d'identification de tiers ne sont pas exposées.

Que pensez-vous de toutes les approches?

Answer 1

C'est une tâche difficile, et aucune approche ne vous évitera de vous assurer qu'il n'y a pas de maillon faible. Pour commencer, je ne saurais pas si l'hébergement sur Google est la meilleure solution, car vous perdrez le contrôle (je ne sais vraiment pas si App Engine est conçu avec le niveau de sécurité requis à l'esprit, vous devriez trouver que out) et ne peut probablement pas effectuer de tests de pénétration (ce que vous devriez faire.)

Avoir une petite application séparée est probablement une bonne idée, mais cela ne vous évite pas d'avoir à crypter d'une façon ou d'une autre les informations d'identification dans ce cas. application plus petite Il vous achète simplement la simplicité, ce qui rend les choses plus faciles à analyser.

Personnellement, j'essaierais de concevoir l'application de manière à ce que la clé change de façon aléatoire après chaque utilisation, en adoptant une approche similaire à one time pad. Vous ne spécifiez pas l'application de manière suffisamment détaillée pour voir si cela est faisable.

Answer 2

Si vous devez stocker de manière réversible des informations d'identification, il n'y a tout simplement pas de solution. Utilisez AES et gardez la clé secrète sous garde armée bien payée. Si vous utilisez Windows, je vérifierais l'API Cred * Win32 (advapi32.dll) cela vous permettrait au moins de rediriger la gestion des clés vers windows syskey où TPM et/ou mot de passe de démarrage peuvent fournir une protection contre les compromis de bas niveau (volés lecteurs de disque)

De toute évidence, si votre application ou le contexte de sécurité dans lequel elle s'exécute est compromise, rien de ce qui précède ne serait d'une grande aide.

Answer 3

Comment les informations d'identification sont-elles utilisées? Si leur utilisation est uniquement déclenchée par le propriétaire d'origine (par exemple, vous stockez un numéro de carte bancaire et qu'ils effectuent leur 2ème achat), ils peuvent alors fournir un mot de passe qui est utilisé comme clé de chiffrement. Vous n'auriez alors jamais besoin de stocker cette clé localement et le contenu de la base de données seul est inutile pour un attaquant.

Answer 4

Un livre décent qui couvre ce genre de situation est Cryptography In The Database.