Stockage sécurisé des identifiants OpenID et des jetons OAuth
Je crée une application Web qui utilisera des connexions OpenID et des jetons OAuth avec Youtube. Je suis en train de stocker l'identité OpenID et le jeton/le secret de jeton OAuth en texte brut dans la base de données.
Est-il inapproprié de stocker ces valeurs sous forme de texte brut? Je pourrais utiliser un cryptage à sens unique pour l'identifiant OpenID, mais je ne sais pas si cela est nécessaire. Pour les jetons OAuth, je devrais utiliser un cryptage bidirectionnel car mon application dépend de l'obtention du jeton de session pour certaines utilisations.
Est-il nécessaire de chiffrer l'identité OpenID? Quelqu'un pourrait-il l'utiliser pour accéder au compte d'un utilisateur?
Premièrement, il y a une application enregistrée qui a consumer_key et consumer_secret.
Lorsque les utilisateurs s'authentifient et "autorisent" votre application enregistrée, vous récupérez: Un access_token considéré comme le "mot de passe" de l'utilisateur et permettant à JUST YOUR d'agir d'agir au nom de celui-ci.
Ainsi, obtenir uniquement le access_token de l'utilisateur dans votre base de données ne vous aidera pas beaucoup s'il ne dispose pas des codes consumer_key et consumer_secret pour un accès complet.
Le prestataire de services compare les 4 paramètres sur demande. Il serait judicieux de chiffrer ces 4 paramètres avant le stockage et de les déchiffrer avant la réponse.
Ceci est juste au moment où vous devez mettre à jour ou modifier le propriétaire de la ressource de l'utilisateur pour le compte d'un utilisateur. Pour garder un utilisateur connecté sur votre site, utilisez des sessions.
Le jeton OAuth et le secret doivent évidemment être conservés dans votre base de données, mais vous ne pouvez pas les stocker en utilisant le cryptage à sens unique de la même manière que vous le feriez pour un mot de passe. La raison en est que vous avez besoin du jeton et du secret pour pouvoir signer la demande.
Ce serait également le cas si vous exécutez un serveur OAuth, vous avez toujours besoin du jeton/secret d'origine pour vérifier la demande.
Si vous le souhaitez, vous pouvez toujours les chiffrer à l'aide d'un algorithme de chiffrement à 2 voies, tel qu'AES, pour assurer la sécurité en cas de compromission de vos bases de données ou de vos sauvegardes.
Il y a deux écoles de pensée ici.
Le premier argument est le suivant: vous devez traiter les jetons OAuth comme des mots de passe. Si quelqu'un devait accéder à votre base de données, obtenir toutes les paires OpenID/OAuth et lancer une attaque par interception, il pourrait emprunter l'identité de n'importe quel utilisateur de votre site.
Le deuxième argument est le suivant: au moment où une personne a accès à votre base de données et à un accès suffisant à votre réseau pour lancer une attaque de type "man-in-the-middle", vous êtes de toute façon condamné.
Personnellement, je ferais preuve de prudence et les chiffrerais simplement; C’est une pratique courante pour les mots de passe, vous pouvez donc aussi vous donner une petite tranquillité d’esprit.
En attendant, Google a ce conseil:
"Les jetons doivent être traités de manière aussi sécurisée que toute autre information sensible stockée sur le serveur."
source: http://code.google.com/apis/accounts/docs/OAuth.html
Et un type aléatoire sur le Web a des conseils de mise en œuvre spécifiques:
- Si elles se trouvent sur un fichier de disque normal, protégez-les à l'aide des autorisations Du système de fichiers, assurez-vous qu'elles sont cryptées, et cachez bien le mot de passe.
- S'ils se trouvent dans une base de données, chiffrez les champs, stockez la clé Well et protégez soigneusement l'accès à la base de données *
- Si elles sont dans LDAP, faites la même chose.
http://brail.org/wordpress/2009/05/01/implementing-oauth-take-care-with-those-keys/
Les URL OpenID ne doivent pas être cryptées car il s’agit de votre "identifiant ouvert", tout le monde devrait connaître la valeur. De plus, l'URL doit être un index dans la base de données et il est toujours problématique de chiffrer l'index dans la base de données.
Le jeton/secret OAuth doit être secret et le chiffrement peut améliorer la sécurité si vous devez stocker le jeton à long terme. Dans notre application client OAuth, le jeton/secret n'est stocké dans la session que pendant un court instant et nous choisissons de ne pas le chiffrer. Je pense que c'est assez sécurisé. Si quelqu'un peut jeter un coup d'œil dans notre stockage de session, il possède probablement aussi notre clé de cryptage.
Oui, ceux-ci doivent être cryptés de manière symétrique (par exemple, AES-256 en mode CBC) au repos dans une base de données. Un moyen simple de chiffrer ces jetons consiste à utiliser les API RESTful de chiffrement en tant que service de SecureDB .
Divulgation: Je travaille chez SecureDB.