Les secrets d'OAuth dans les applications mobiles
Lorsque vous utilisez le protocole OAuth, vous avez besoin d'une chaîne secrète obtenue du service auquel vous souhaitez déléguer. Si vous le faites dans une application Web, vous pouvez simplement stocker le secret dans votre base de données ou sur le système de fichiers, mais quel est le meilleur moyen de le gérer dans une application mobile (ou une application de bureau, d'ailleurs)?
Stocker la chaîne dans l'application n'est évidemment pas une bonne chose, car quelqu'un pourrait facilement la trouver et en abuser.
Une autre approche consisterait à le stocker sur votre serveur et à le faire récupérer par l'application à chaque exécution, sans jamais la stocker sur le téléphone. C'est presque aussi grave, car vous devez inclure l'URL dans l'application.
La seule solution viable que je puisse trouver consiste à obtenir d'abord le jeton d'accès comme d'habitude (de préférence en utilisant une vue Web à l'intérieur de l'application), puis à acheminer toutes les communications supplémentaires via notre serveur, ce qui ajouterait le secret aux données de la demande et communiquerait avec le fournisseur. Là encore, je suis un agent de sécurité et j'aimerais donc connaître l'opinion de personnes bien informées à ce sujet. Il ne me semble pas que la plupart des applications se rendent à ces égards pour garantir la sécurité (par exemple, Facebook Connect semble supposer que vous mettez le secret dans une chaîne directement dans votre application).
Autre chose: je ne crois pas que le secret soit impliqué dans la demande initiale du jeton d'accès. Cela pourrait donc être fait sans impliquer notre propre serveur. Ai-je raison?
Oui, c'est un problème avec le design OAuth auquel nous sommes confrontés. Nous avons opté pour un proxy de tous les appels via notre propre serveur. OAuth n'a pas été entièrement vidé en ce qui concerne les applications de bureau. Il n’existe pas de solution idéale au problème que j’ai trouvé sans changer OAuth.
Si vous y réfléchissez et posez la question pourquoi nous avons des secrets, c'est principalement pour la fourniture et la désactivation d'applications. Si notre secret est compromis, le fournisseur ne peut que révoquer l'application dans son ensemble. Puisque nous devons intégrer notre secret dans l'application de bureau, nous sommes en quelque sorte foutus.
La solution consiste à avoir un secret différent pour chaque application de bureau. OAuth ne rend pas ce concept facile. L’un des moyens consiste à demander à l’utilisateur de créer son secret et de saisir lui-même la clé dans votre application de bureau (certaines applications facebook ont longtemps fait de même, invitant l’utilisateur à créer Facebook pour configurer ses tests personnalisés et merde). Ce n'est pas une bonne expérience pour l'utilisateur.
Je travaille sur la proposition d'un système de délégation pour OAuth. Le concept est que, en utilisant notre propre clé secrète fournie par notre fournisseur, nous pourrions émettre notre propre secret délégué à nos propres clients de bureau (un pour chaque application de bureau essentiellement) et ensuite, pendant le processus d'autorisation, nous envoyons cette clé au niveau supérieur. fournisseur qui nous rappelle et re-valide avec nous. De cette façon, nous pouvons révoquer nos propres secrets que nous transmettons à chaque client de bureau. (Emprunter beaucoup de la façon dont cela fonctionne à partir de SSL). L'ensemble de ce système serait parfait pour les services Web à valeur ajoutée qui transmettent des appels à un service Web tiers.
Le processus peut également être effectué sans rappel de vérification de délégation si le fournisseur de niveau supérieur fournit une API permettant de générer et de révoquer de nouveaux secrets délégués. Facebook fait quelque chose de similaire en permettant aux applications Facebook de permettre aux utilisateurs de créer des sous-applications.
Il y a quelques discussions sur la question en ligne:
http://blog.atebits.com/2009/02/fixing-oauth/http://groups.google.com/group/Twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14 # de1071bf4b820c14
La solution de Twitter et Yammer est une solution de code d’authentification: https://dev.Twitter.com/oauth/pin-basedhttps://www.yammer.com/api_oauth_security_addendum.html
Avec OAUth 2.0, vous pouvez stocker le secret sur le serveur. Utilisez le serveur pour acquérir un jeton d'accès que vous déplacez ensuite vers l'application et vous pouvez passer des appels directement de l'application à la ressource.
Avec OAuth 1.0 (Twitter), le secret est requis pour effectuer des appels d'API. La sollicitation d'appels via le serveur est le seul moyen de s'assurer que le secret n'est pas compromis.
Les deux nécessitent un mécanisme indiquant que votre composant serveur sait que c'est votre client qui l'appelle. Cela a tendance à être fait lors de l'installation et en utilisant un mécanisme spécifique à la plate-forme pour obtenir un identifiant d'application quelconque dans l'appel du serveur.
(Je suis l'éditeur de la spécification OAuth 2.0)
Une solution pourrait consister à coder en dur le secret OAuth dans le code, mais pas en tant que chaîne simple. Le masquer d'une certaine manière - le diviser en segments, décaler les caractères d'un décalage, le faire pivoter - faire tout ou partie de ces choses. Un pirate informatique peut analyser votre code d'octet et rechercher des chaînes, mais le code de dissimulation peut être difficile à comprendre.
Ce n'est pas une solution infaillible, mais bon marché.
Selon la valeur de l'exploit, certains crackers de génie peuvent aller plus loin pour trouver votre code secret. Vous devez peser les facteurs - coût de la solution côté serveur mentionnée précédemment, incitation des pirates à consacrer plus d’efforts à la recherche de votre code secret et de la complexité de l’obfuscation que vous pouvez implémenter.
Ne stockez pas le secret dans l'application.
Vous devez disposer d'un serveur auquel l'application peut accéder via https (évidemment) et vous y stockez le secret.
Lorsque quelqu'un souhaite se connecter via votre application mobile/de bureau, votre application transmettra simplement la demande au serveur qui ajoutera le secret et l'enverra au fournisseur de services. Votre serveur peut alors dire à votre application si elle a réussi ou non.
Ensuite, si vous avez besoin d’obtenir des informations sensibles du service (Facebook, Google, Twitter, etc.), l’application demande à votre serveur et celui-ci ne les communiquera à l’application que s’il est correctement connecté.
Il n'y a pas vraiment d'autre option que de la stocker sur un serveur. Rien du côté client n'est sécurisé.
Remarque
Cela dit, cela ne vous protégera que contre les clients malveillants, mais pas contre les clients malveillants et non contre les clients contre d'autres clients malveillants (phising) ...
OAuth est un protocole bien meilleur dans un navigateur que sur un ordinateur de bureau/mobile.
Avec OAuth 2.0, vous pouvez simplement utiliser le flux côté client pour obtenir un jeton d'accès, puis utiliser ce jeton d'accès pour authentifier toutes les autres requêtes. Ensuite, vous n'avez pas besoin d'un secret du tout.
Vous trouverez une belle description de la manière de mettre en œuvre ceci ici: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps
Voici quelque chose à penser. Google propose deux méthodes OAuth ... pour les applications Web, dans lesquelles vous enregistrez le domaine et générez une clé unique, et pour les applications installées, dans lesquelles vous utilisez la clé "anonyme".
J'ai peut-être passé sous silence quelque chose dans la lecture, mais il semble que le partage de la clé unique de votre application Web avec une application installée est probablement plus sécurisé que d'utiliser "anonyme" dans la méthode des applications installées officielles.
Je suis d'accord avec Felixyz. OAuth, bien que meilleur que l'authentification de base, a encore beaucoup de chemin à faire pour être une bonne solution pour les applications mobiles. Je m'amuse à utiliser OAuth pour authentifier une application de téléphone portable sur une application Google App Engine. Le fait que vous ne puissiez pas gérer de manière fiable le secret du consommateur sur le périphérique mobile signifie que le choix par défaut consiste à utiliser l'accès «anonyme».
L'étape d'autorisation du navigateur de l'implémentation de Google App Engine OAuth vous conduit à une page contenant du texte tel que: "Le site <some-site> demande l'accès à votre compte Google pour le ou les produits répertoriés ci-dessous".
YourApp (yourapp.appspot.com) - non affiliée à Google
etc
Il faut <some-site> dans le nom de domaine/hôte utilisé dans l'URL de rappel que vous indiquez, ce qui peut être n'importe quoi sur Android si vous utilisez un schéma personnalisé pour intercepter le rappel . Donc, si vous utilisez un accès 'anonyme' ou votre secret de consommateur est compromis, alors tout le monde peut écrire un consommateur qui trompe l'utilisateur en lui donnant accès à votre application gae.
La page d'autorisation de Google OAuth contient également de nombreux avertissements qui ont 3 niveaux de gravité, selon que vous utilisez des clés "anonymes", des données confidentielles des consommateurs ou des clés publiques.
Chose assez effrayante pour l'utilisateur moyen qui n'est pas techniquement averti. Je ne m'attends pas à un taux de participation élevé avec ce genre de problème.
Ce billet de blog explique comment le secret du consommateur ne fonctionne pas vraiment avec les applications installées http://hueniverse.com/2009/02/should-Twitter-discontinue-their-basic-auth-api/
Aucune de ces solutions n’empêche un pirate déterminé de renifler les paquets envoyés depuis son périphérique mobile (ou son émulateur) afin d’afficher le secret du client dans les en-têtes http.
Une solution pourrait consister à disposer d’un secret dynamique composé d’un horodatage chiffré avec une clé de chiffrement et un algorithme privés. Le service décrypte ensuite le secret et détermine si l'horodatage est de +/- 5 minutes.
De cette manière, même si le secret est compromis, le pirate informatique ne pourra l'utiliser que pendant 5 minutes maximum.
Ici, je réponds au moyen sûr de stocker vos informations oAuth dans une application mobile
https://stackoverflow.com/a/17359809/998483
http://www.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication
Je n'ai pas beaucoup d'expérience avec OAuth - mais chaque demande ne nécessite-t-elle pas seulement le jeton d'accès de l'utilisateur, mais également une clé consommateur d'application et un secret? Ainsi, même si quelqu'un vole un appareil mobile et tente d'en extraire des données, il lui faut une clé d'application et un secret pour pouvoir faire quoi que ce soit.
J'ai toujours pensé que l'intention derrière OAuth était de faire en sorte que tous les Tom, Dick et Harry ayant un mashup n'aient pas à stocker vos informations d'identification Twitter en clair. Je pense que cela résout assez bien ce problème malgré ses limites. En outre, il n'a pas été conçu pour l'iPhone.
Il existe une nouvelle extension du type d'attribution de code d'autorisation appelée clé de vérification pour l'échange de code (PKCE). Avec cela, vous n'avez pas besoin d'un secret client.
PKCE (RFC 7636) est une technique permettant de sécuriser les clients publics qui n'utilisent pas un secret de client.
Il est principalement utilisé par les applications natives et mobiles, mais la technique peut être appliqué à tout client public aussi. Cela nécessite plus de supporté par le serveur d’autorisation, il est donc uniquement pris en charge sur certains fournisseurs.
from https://oauth.net/2/pkce/
Pour plus d'informations, vous pouvez lire l'intégralité de RFC 7636 ou cette courte introduction .
J'essaie également de trouver une solution pour l'authentification OAuth mobile et de stocker des secrets dans l'ensemble d'applications en général.
Et une idée folle m’a frappé: l’idée la plus simple est de stocker le secret à l’intérieur du fichier binaire, mais en quelque sorte obscurci, ou, en d’autres termes, de stocker un secret crypté. Cela signifie donc que vous devez stocker une clé pour déchiffrer votre secret, ce qui semble nous avoir complètement bouclé. Cependant, pourquoi ne pas utiliser une clé déjà présente dans le système d’exploitation, c’est-à-dire définie par le système d’exploitation, et non par votre application.
Donc, pour clarifier mon idée, c'est que vous choisissez une chaîne définie par le système d'exploitation, peu importe laquelle. Puis chiffrez votre secret en utilisant cette chaîne comme clé et stockez-le dans votre application. Ensuite, pendant l'exécution, décryptez la variable à l'aide de la clé, qui est simplement une constante du système d'exploitation. Tout pirate informatique jetant un coup d'œil dans votre binaire verra une chaîne chiffrée, mais pas de clé.
Ça marchera?
Facebook n'implémente pas encore OAuth à proprement parler, mais ils ont mis en place un moyen de ne pas intégrer votre secret dans votre application iPhone: https://web.archive.org/web/20091223092924/http:// wiki.developers.facebook.com/index.php/Session_Proxy
Quant à OAuth, oui, plus j'y pense, plus nous sommes fourrés. Peut-être que ceci va le réparer.