Comment préserver le secret du consommateur OAuth et comment réagir lorsqu'il est compromis ?

Question

Cette question vise à comprendre les risques de sécurité liés à la mise en œuvre d'oauth sur une plateforme mobile telle qu'Android. L'hypothèse est que nous avons une application Android dont le code contient la clé/le secret du consommateur.

Dans l'hypothèse où le secret d'un consommateur a été compromis et qu'un pirate informatique a mis la main dessus, quelles en sont les conséquences ?

Hypothèses compromises sur le secret du consommateur
Ai-je raison d'affirmer qu'un secret de consommateur compromis n'a aucun effet sur la sécurité de l'utilisateur, ni sur les données stockées chez le fournisseur compatible avec OAuth avec lequel l'utilisateur a interagi ? Les données elles-mêmes ne sont pas compromises et ne peuvent pas être récupérées par le pirate.

Le pirate devrait mettre la main sur un jeton d'accès d'utilisateur valide, ce qui est beaucoup plus difficile à obtenir.

Que pourrait faire un pirate informatique avec un secret de consommation compromis ?
Ai-je raison d'affirmer ce qui suit :

• Le pirate peut créer/publier un qui imite mon application.
• Le pirate peut attirer des utilisateurs qui iront par le flux OAuth, en récupérant un jeton d'accès via la danse OAuth du pirate (en utilisant la clé/le secret du consommateur compromis).
• L'utilisateur peut penser qu'il a affaire à mon application, car il verra nom familier (clé de consommateur) lors de la procédure d'autorisation.
• Lorsqu'un consommateur émet une demande via le pirate, celui-ci peut facilement intercepter le jeton d'accès et combiné au secret du consommateur, il peut signer des requêtes en mon nom pour accéder à mes ressources.

Impact sur l'utilisateur final
Dans l'hypothèse où

• un pirate informatique a mis en place une application / en utilisant mon secret de consommation
• un de mes utilisateurs s'est fait piéger en autorisant l'accès à cette application / ce site

Les situations suivantes peuvent se produire :

• l'utilisateur final peut s'apercevoir qu'il se passe quelque chose de louche et informer le fournisseur de services (ex : Google) de l'existence de l'application malveillante
• le fournisseur de services peut alors révoquer la clé/le secret du consommateur

Impact du consommateur OAuth (mon application) :
Mon application (contenant le secret du consommateur) devrait être mise à jour, car sinon tous mes clients ne pourraient plus autoriser mon application à effectuer des demandes en leur nom (puisque mon secret du consommateur ne serait plus valide).

Délégation de tout le trafic OAuth
Bien qu'il soit possible de déléguer une grande partie des interactions OAuth via un serveur web intermédiaire (faire la danse OAuth et envoyer le jeton d'accès à l'utilisateur), il faudrait également déléguer toutes les interactions de service, car la clé/secret du consommateur est nécessaire pour signer chaque requête. Est-ce la seule façon de garder la clé/le secret du consommateur en dehors de l'application mobile, et de la stocker dans un endroit plus sûr sur le serveur web intermédiaire ?

Alternatives
Existe-t-il des alternatives à cette procuration ? Est-il possible de stocker le secret du consommateur sur le serveur web intermédiaire et de disposer d'un mécanisme permettant à l'application Android (publiée sur le marché et correctement signée) d'adresser une demande sécurisée au serveur web intermédiaire pour récupérer le secret du consommateur et le stocker en interne dans l'application ? Est-il possible de mettre en place un mécanisme permettant au serveur web intermédiaire de "savoir" qu'il s'agit d'une application Android officielle qui demande à récupérer le secret du consommateur, et que le serveur web intermédiaire ne transmettra le secret du consommateur qu'à cette application Android en particulier ?

Answer 1

Résumé : Je prendrais le risque de garder le secret dans l'application client.

Serveur proxy alternatif :

La seule façon d'atténuer raisonnablement les problèmes que j'énumère ci-dessous et de faire fonctionner le proxy serait d'aller jusqu'au bout, c'est-à-dire de déplacer toute la logique commerciale pour traiter les ressources du service web tiers vers votre serveur proxy, et de faire de l'application client un terminal muet avec une interface utilisateur riche. De cette manière, les seules actions que l'application malveillante pourrait faire exécuter par le proxy en son nom seraient uniquement celles dont votre logique commerciale a légitimement besoin.

Mais on entre alors dans le domaine de toute une série d'autres problèmes liés à la fiabilité et à l'évolutivité.

Longue délibération sur les raisons pour lesquelles une simple procuration ne fonctionnerait pas :

S problème, se disent "Je sais, je vais ajouter mon propre serveur proxy". propre serveur proxy". problèmes. (avec toutes nos excuses à Jamie Zawinski)

Vos hypothèses sont en grande partie justes. Jusqu'au moment où vous commencez à penser à votre propre serveur, qu'il garde le secret et transmette les appels à l'application cliente, ou qu'il tente de déterminer si l'application est légitime et lui donne le secret. Dans les deux cas, vous devez toujours résoudre le problème suivant : "Cette requête provient-elle d'un morceau de code que j'ai écrit ?

Permettez-moi de répéter - il n'y a aucun moyen de distinguer sur le fil le logiciel en cours d'exécution. Si les données contenues dans les messages semblent correctes, rien ne peut prouver que c'est une autre application qui envoie ce message .

En fin de compte, si j'écris une application malveillante, je me fiche de savoir si je connais le vrai secret, tant que je peux faire en sorte que quelqu'un qui le connaît fasse un travail en mon nom. Donc, si vous pensez qu'une application malveillante peut se faire passer pour votre application auprès des serveurs OAuth tiers, pourquoi êtes-vous certain qu'elle ne peut pas se faire passer pour votre application auprès de votre proxy ?

Mais ce n'est pas tout. Le domaine dans lequel se trouve votre service proxy est votre identité à la fois pour vos clients et pour le fournisseur OAuth (tel qu'il est montré à l'utilisateur final par le fournisseur OAuth). Si une application malveillante peut faire faire de mauvaises choses à votre serveur, non seulement votre clé est révoquée, mais votre identité publique sur le web n'est plus fiable.

---

Je commencerai par l'évidence : il n'y a aucun moyen de distinguer sur le câble le logiciel en cours d'exécution. Si les données contenues dans les messages semblent correctes, rien ne peut prouver que c'est une autre application qui envoie ce message.

Ainsi, tout algorithme qui s'appuie sur un secret stocké du côté de l'application peut être usurpé. La force d'OAuth est qu'il ne donne jamais les identifiants de l'utilisateur à l'application, mais plutôt des identifiants temporaires propres à l'application, que l'utilisateur peut révoquer si nécessaire.

Bien sûr, le point faible est qu'une application suffisamment bonne peut amener l'utilisateur à lui faire confiance et à ne pas révoquer les informations d'identification, avant qu'elle n'ait terminé ses actes malveillants.

Toutefois, l'approche de Google, qui consiste à utiliser OAuth à trois pattes au lieu des deux pattes habituelles, permet d'atténuer ce problème. Dans l'OAuth à trois branches, il n'y a pas de secret pré-attribué, mais à chaque authentification, un nouveau secret de jeton d'accès est émis, en même temps que chaque jeton d'accès. Bien qu'en fin de compte cela présente le même inconvénient, puisqu'une mauvaise application peut lire le secret du jeton de la bonne application à partir de son processus, cela signifie que l'utilisateur doit approuver l'accès de l'application chaque fois qu'elle a besoin d'un nouveau jeton d'accès.

Et bien sûr, cela signifie aussi que c'est un peu plus gênant et ennuyeux pour l'utilisateur.