OAuth secrets dans les applications mobiles

Lorsque vous utilisez le protocole OAuth, vous avez besoin d’une chaîne secrète obtenue à partir du service auquel vous souhaitez déléguer. Si vous le faites dans une application Web, vous pouvez simplement stocker le secret dans votre firebase database ou sur le système de fichiers, mais quelle est la meilleure façon de le gérer dans une application mobile (ou une application de bureau)?

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 à la stocker sur votre serveur et à l’appliquer à 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 réalisable que je puisse trouver est d’obtenir tout d’abord le jeton d’access de la manière habituelle (de préférence en utilisant une vue Web à l’intérieur de l’application), puis de avec le fournisseur. Là encore, je suis un noob de sécurité, alors j’aimerais vraiment entendre l’opinion de personnes bien informées à ce sujet. Il ne me semble pas que la plupart des applications vont aussi loin 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’access, cela pourrait se faire sans impliquer notre propre serveur. Ai-je raison?

Oui, c’est un problème avec le design OAuth auquel nous sums confrontés. Nous avons choisi de traiter tous les appels par notre propre serveur. OAuth n’a pas été entièrement vidé en ce qui concerne les applications de bureau. Il n’y a pas de solution idéale au problème que j’ai trouvé sans changer OAuth.

Si vous y réfléchissez et que vous vous posez la question de savoir pourquoi nous avons des secrets, il s’agit principalement de la fourniture et de la désactivation des applications. Si notre secret est compromis, le fournisseur ne peut vraiment révoquer l’application entière. Comme nous devons intégrer notre secret dans l’application de bureau, nous sums en quelque sorte foutus.

La solution consiste à avoir un secret différent pour chaque application de bureau. OAuth ne facilite pas ce concept. L’un des moyens consiste à demander à l’utilisateur de créer lui-même un secret et de saisir lui-même la clé dans votre application de bureau (certaines applications facebook ont ​​fait quelque chose de similaire pendant longtemps, l’utilisateur a créé merde). Ce n’est pas une grande expérience pour l’utilisateur.

Je travaille sur une proposition pour 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) et ensuite, pendant le processus d’authentification, nous enverrions 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 émettons à chaque client de bureau. (Emprunt beaucoup de comment cela fonctionne de SSL). Ce système entier serait préfet pour les services Web à valeur ajoutée, qui transmettent les 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 pour générer et révoquer de nouveaux secrets delegates. 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 le sujet 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 de Yammer est une solution d’identification automatique: https://dev.twitter.com/oauth/pin-based https://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’access que vous déplacez ensuite vers l’application et vous pouvez effectuer des appels directement depuis l’application vers la ressource.

Avec OAuth 1.0 (Twitter), le secret est requirejs pour effectuer des appels API. Faire des 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 que votre composant serveur sait qu’il appelle votre client. 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 à votre serveur.

(Je suis l’éditeur de la spécification OAuth 2.0)

Une solution pourrait être de coder en dur le secret OAuth dans le code, mais pas en tant que chaîne simple. Obscurcissez-le d’une certaine façon – divisez-le en segments, déplacez les caractères d’un décalage, faites-le pivoter – faites tout ou partie de ces choses. Un pirate peut parsingr votre code d’octet et trouver des chaînes, mais le code d’obscurcissement peut être difficile à comprendre.

Ce n’est pas une solution infaillible, mais une solution bon marché.

Selon la valeur de l’exploit, certains crackers de génie peuvent aller plus loin pour trouver votre code secret. Vous devez évaluer les facteurs – le coût de la solution côté serveur mentionnée précédemment, l’incitation pour les crackers à consacrer plus d’efforts à la recherche de votre code secret et la complexité de l’obscurcissement que vous pouvez implémenter.

Ne stockez pas le secret à l’intérieur de l’application.

Vous devez avoir un serveur accessible par l’application via https (évidemment) et y stocker le secret.

Lorsque quelqu’un veut se connecter via votre application mobile / bureau, votre application va simplement transmettre la demande au serveur qui appenda le secret et l’enverra au fournisseur de services. Votre serveur peut alors indiquer à 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 votre serveur le donnera à l’application uniquement s’il est correctement connecté.

Il n’y a pas vraiment d’option, sauf le stockage 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.

Voici quelque chose à penser. Google propose deux méthodes d’OAuth … pour les applications Web, où vous enregistrez le domaine et générez une clé unique, et pour les applications installées où vous utilisez la clé “anonyme”.

Peut-être ai-je caché quelque chose dans la lecture, mais il semble que partager la clé unique de votre webapp avec une application installée est probablement plus sûr que d’utiliser «anonyme» dans la méthode des applications installées officielles.

Avec OAuth 2.0, vous pouvez simplement utiliser le stream côté client pour obtenir un jeton d’access et utiliser ensuite ce jeton d’access pour authentifier toutes les demandes supplémentaires. Alors vous n’avez pas besoin de secret du tout.

Une belle description de la façon de mettre en œuvre cela peut être trouvée ici: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

Je n’ai pas beaucoup d’expérience avec OAuth – mais chaque demande ne nécessite-t-elle pas seulement le jeton d’access de l’utilisateur, mais aussi une clé de consommateur d’application et un secret? Ainsi, même si quelqu’un vole un appareil mobile et essaie d’en extraire des données, il aurait également besoin d’une clé d’application et d’un secret pour pouvoir faire quoi que ce soit.

J’ai toujours pensé que l’intention derrière OAuth était telle que tous les Tom, Dick et Harry qui avaient un mashup n’avaient pas besoin de stocker vos identifiants Twitter en clair. Je pense que cela résout assez bien ce problème malgré ses limites. En outre, il n’a pas vraiment été conçu avec l’iPhone en tête.

Je suis d’accord avec Felixyz. Bien que mieux que Basic Auth, OAuth a encore un long chemin à parcourir pour devenir une bonne solution pour les applications mobiles. Je joue avec 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 l’access par défaut est l’access par défaut.

L’étape d’autorisation du navigateur de l’implémentation Google App Engine OAuth vous amène à une page contenant du texte tel que: “Le site demande l’access à votre compte Google pour les produits répertoriés ci-dessous”

YourApp (yourapp.appspot.com) – non affilié à Google

etc

Il prend du 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 access «anonyme» ou si votre secret de consommateur est compromis, alors n’importe qui peut écrire à un consommateur qui trompe l’utilisateur en lui donnant access à votre application gae.

La page d’autorisation de Google OAuth contient également de nombreux avertissements comportant trois niveaux de gravité, selon que vous utilisez des clés «anonymes», des codes confidentiels ou des clés publiques.

Un truc assez effrayant pour l’utilisateur moyen qui n’est pas techniquement averti. Je ne m’attends pas à avoir un pourcentage élevé d’achèvement d’inscription avec ce genre de choses dans la voie.

Cet article explique comment les secrets de consommation ne fonctionnent pas vraiment avec les applications installées. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

J’essaie également de trouver une solution pour l’authentification OAuth mobile et de stocker les secrets dans l’ensemble d’applications en général.

Et une idée folle me frappe: L’idée la plus simple est de stocker le secret dans le binary, mais obscurci d’une manière ou d’une autre, ou, en d’autres termes, vous stockez un secret crypté. Donc, cela signifie que vous devez stocker une clé pour décrypter votre secret, ce qui semble nous avoir complètement bouclé. Cependant, pourquoi ne pas utiliser une clé qui est déjà 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, vous choisissez une chaîne définie par le système d’exploitation, peu importe lequel. Ensuite, cryptez votre secret en utilisant cette chaîne comme clé et stockez-la dans votre application. Ensuite, lors de l’exécution, décryptez la variable à l’aide de la clé, qui est juste une constante du système d’exploitation. Tout pirate qui jette un œil dans votre fichier binary verra une chaîne cryptée, mais pas de clé.

Ça marchera?

Ici, j’ai répondu de manière sécurisée au stockage de vos informations oAuth dans une application mobile

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

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 sums un peu bourrés. Peut – être que cela va régler le problème.

Il y a une nouvelle extension au type d’autorisation de code d’autorisation appelé 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 client.

Il est principalement utilisé par les applications natives et mobiles, mais la technique peut également être appliquée à tout client public. Il nécessite une prise en charge supplémentaire par le serveur d’autorisation, de sorte qu’il n’est pris en charge que par certains fournisseurs.

de https://oauth.net/2/pkce/

Pour plus d’informations, vous pouvez lire le RFC 7636 complet ou cette courte introduction .

Comme d’autres l’ont mentionné, il ne devrait y avoir aucun problème réel de stockage du secret localement sur l’appareil.

En plus de cela, vous pouvez toujours compter sur le modèle de sécurité basé sur UNIX d’Android: seule votre application peut accéder à ce que vous écrivez dans le système de fichiers. Il suffit d’écrire les informations sur l’object SharedPreferences par défaut de votre application.

Pour obtenir le secret, il faudrait obtenir un access root au téléphone Android.