Comment les applications populaires authentifient-elles les demandes des utilisateurs de leur application mobile sur leur serveur?


118

Disons que j'ai une application Android qui se connecte à une API .Net pour recevoir / définir des données. La confusion que j'ai concerne la manière de s'inscrire / connecter l'utilisateur pour la première fois et de l'authentifier chaque fois qu'il fait une demande à l'API.

  • Si j'utilise simplement l'authentification basée sur le nom d'utilisateur / mot de passe, ils ne seront pas assez sûrs?
  • Et je ne peux pas enregistrer ce nom d'utilisateur / mot de passe dans l'appareil pour des raisons de sécurité bien sûr?
  • Dois-je émettre un GUID pour chaque utilisateur lors de l'inscription, l'enregistrer sur son appareil et le récupérer à chaque fois lors d'une demande d'API?

Quels autres modèles sont disponibles et lesquels sont les plus efficaces et sécurisés, j'ai juste besoin d'un flux de processus pour cela. Quelqu'un peut-il me dire quelle méthode les applications Android célèbres comme Facebook, FourSquare ou Twitter utilisent pour authentifier chaque demande provenant de leur application mobile sur leur serveur?

Désolé à l'avance si ce n'est pas une information publique.

Réponses:


48

J'imagine qu'ils utilisent un système de sécurité basé sur des «jetons», de sorte que le mot de passe n'est en fait jamais stocké nulle part, juste utilisé la première fois pour s'authentifier. Ainsi, l'application publie initialement le nom d'utilisateur / mot de passe (sur ssl) et le serveur renvoie un jeton que l'application stocke. Pour les tentatives de synchronisation suivantes, le jeton est envoyé en premier, le serveur vérifie sa validité, puis autorise la publication d'autres données.

Le jeton doit avoir une expiration pour que le serveur puisse demander à nouveau une tentative d'authentification.

Si vous vous connectez à l'adaptateur de synchronisation depuis le framework Android, cela vous donnera la possibilité de synchroniser et d'authentifier tout sous le capot.

http://developer.android.com/training/sync-adapters/creating-sync-adapter.html

Si vous vérifiez les comptes sous Paramètres sur votre appareil, vous verrez ce que je veux dire.


20

Fondamentalement, ces fameux utilisent le protocole OAuth (1) / framework (2). Même s'il doit s'agir d'une norme, chacun d'entre eux avait des implémentations différentes de ce protocole / cadre. Il faut donc être très prudent en matière d'intégration.

Exemple: Dropbox utilise toujours OAuth 1 et a récemment proposé la prise en charge d'OAuth 2.

De retour à la réponse, comme l'a déclaré Peterpan, c'est un moyen d'authentification basé sur des jetons qui est une chose ponctuelle et hors de l'équation. Ces jetons ont expiré ou ce pouvoir est donné au développeur dans certains cas.

La chose intéressante derrière cela est que la portée d'accès aux ressources peut être définie plutôt que de permettre à l'application cliente de conserver les noms d'utilisateur, mots de passe, ce qui est dangereux.

Ceci est l'illustration de base de la façon dont cela fonctionne.

entrez la description de l'image ici

Je mettrai à jour la réponse après avoir obtenu plus de détails à ce sujet, car je travaille dans ce domaine ces jours-ci :)


13

Si j'utilise simplement l'authentification basée sur le nom d'utilisateur / mot de passe, ils ne seront pas assez sûrs?

Non, car vous identifiez uniquement l' OMS qui accède au serveur API, mais pas le QUOI y accède.

La différence entre QUI et QUOI accède au serveur API

Pour mieux comprendre les différences entre l' OMS et le WHAT accèdent à un serveur API, utilisons cette image:

L'homme au milieu de l'attaque

Le canal de communication prévu représente l'application mobile utilisée comme prévu, par un utilisateur légitime sans aucune intention malveillante, utilisant une version non testée de l'application mobile et communiquant directement avec le serveur API sans être attaqué par l'homme du milieu.

Le canal réel peut représenter plusieurs scénarios différents, comme un utilisateur légitime avec des intentions malveillantes qui peut utiliser une version reconditionnée de l'application mobile, un pirate informatique utilisant la version authentique de l'application mobile, tandis qu'un homme au milieu l'attaque, pour comprendre comment la communication entre l'application mobile et le serveur d'API se fait afin de pouvoir automatiser les attaques contre votre API. De nombreux autres scénarios sont possibles, mais nous ne les énumérerons pas ici.

J'espère que vous savez peut-être déjà pourquoi l' OMS et le QUOI ne sont pas les mêmes, mais sinon, cela deviendra clair dans un instant.

L' OMS est l'utilisateur de l'application mobile que nous pouvons authentifier, autoriser et identifier de plusieurs manières, comme en utilisant les flux OpenID Connect ou OAUTH2.

OAUTH

Généralement, OAuth fournit aux clients un «accès délégué sécurisé» aux ressources du serveur pour le compte d'un propriétaire de ressource. Il spécifie un processus permettant aux propriétaires de ressources d'autoriser l'accès de tiers à leurs ressources de serveur sans partager leurs informations d'identification. Conçu spécifiquement pour fonctionner avec le protocole HTTP (Hypertext Transfer Protocol), OAuth permet essentiellement d'émettre des jetons d'accès à des clients tiers par un serveur d'autorisation, avec l'approbation du propriétaire de la ressource. Le tiers utilise ensuite le jeton d'accès pour accéder aux ressources protégées hébergées par le serveur de ressources.

OpenID Connect

OpenID Connect 1.0 est une simple couche d'identité au-dessus du protocole OAuth 2.0. Il permet aux clients de vérifier l'identité de l'utilisateur final sur la base de l'authentification effectuée par un serveur d'autorisation, ainsi que d'obtenir des informations de profil de base sur l'utilisateur final d'une manière interopérable et similaire à REST.

Bien que l'authentification de l'utilisateur puisse informer le serveur API que l' OMS utilise l'API, elle ne peut garantir que les demandes proviennent de CE QUE vous attendez, la version d'origine de l'application mobile.

Maintenant , nous devons trouver un moyen d'identifier QU'EST - CE appelle le serveur API, et ici les choses deviennent plus difficiles que la plupart des développeurs peuvent penser. Le WHAT est la chose qui fait la demande au serveur API. Est-ce vraiment une véritable instance de l'application mobile, ou est-ce qu'un bot, un script automatisé ou un attaquant fouille manuellement avec le serveur API, en utilisant un outil comme Postman?

Pour votre surprise, vous pouvez finir par découvrir qu'il peut s'agir de l'un des utilisateurs légitimes utilisant une version reconditionnée de l'application mobile ou un script automatisé qui tente de gamifier et de profiter du service fourni par l'application.

Eh bien, pour identifier le QUOI , les développeurs ont tendance à recourir à une clé API qu'ils codent généralement en dur dans le code de leur application mobile. Certains développeurs font un effort supplémentaire et calculent la clé au moment de l'exécution dans l'application mobile, elle devient donc un secret d'exécution par opposition à l'ancienne approche lorsqu'un secret statique est intégré dans le code.

La description ci-dessus a été extraite d'un article que j'ai écrit, intitulé POURQUOI VOTRE APPLICATION MOBILE A-T-ELLE BESOIN D'UNE CLÉ API? , et que vous pouvez lire en entier ici , c'est le premier article d'une série d'articles sur les clés API.

Stockage des données sensibles dans l'appareil client

Et je ne peux pas enregistrer ce nom d'utilisateur / mot de passe dans l'appareil pour des raisons de sécurité bien sûr? Dois-je émettre un GUID pour chaque utilisateur lors de l'inscription, l'enregistrer sur son appareil et le récupérer à chaque fois lors d'une demande d'API?

Tout ce que vous enregistrez dans l'appareil, même crypté, peut être rétro-conçu pendant l'exécution avec des outils tels que Frida ou Xposed.

Frida

Injectez vos propres scripts dans des processus de boîte noire. Accrochez n'importe quelle fonction, espionnez les API cryptographiques ou tracez le code d'application privée, aucun code source n'est nécessaire. Modifiez, appuyez sur Enregistrer et voyez instantanément les résultats. Le tout sans étapes de compilation ni redémarrage du programme.

xPosé

Xposed est un cadre pour les modules qui peuvent changer le comportement du système et des applications sans toucher aux APK. C'est génial car cela signifie que les modules peuvent fonctionner pour différentes versions et même des ROM sans aucun changement (tant que le code d'origine

Dans un appareil que l'attaquant contrôle, il peut également utiliser un proxy pour effectuer une attaque de l'homme au milieu afin d'extraire tout secret que vous pouvez utiliser pour identifier le QUOI ou l' OMS comme je le montre dans l'article Voler cette clé API avec un homme dans l'attaque :

Bien que nous puissions utiliser des techniques avancées, telles que JNI / NDK, pour masquer la clé API dans le code de l'application mobile, cela n'empêchera pas quelqu'un d'effectuer une attaque MitM afin de voler la clé API. En fait, une attaque MitM est facile au point qu'elle peut même être réalisée par des non-développeurs.

Alors maintenant que ... Suis-je condamné au point de ne pas pouvoir protéger mon serveur API contre les abus ??? Pas de calme donc ... l'espoir existe toujours !!!

Solutions possibles

Quelqu'un peut-il me dire quelle méthode les applications Android célèbres comme Facebook, FourSquare ou Twitter utilisent pour authentifier chaque demande provenant de leur application mobile sur leur serveur?

Désolé mais je n'ai pas assez de connaissances sur ces applications pour pouvoir vous élucider, mais je peux vous indiquer d'autres approches.

Quels autres modèles sont disponibles et lesquels sont les plus efficaces et sécurisés, j'ai juste besoin d'un flux de processus pour cela.

Ainsi, tout ce qui fonctionne du côté client et a besoin d'un secret pour accéder à une API peut être abusé de différentes manières et vous pouvez en savoir plus sur cette série d'articles sur les techniques de sécurité des API mobiles. Cet article vous apprendra comment les clés API, les jetons d'accès utilisateur, l'épinglage HMAC et TLS peuvent être utilisés pour protéger l'API et comment ils peuvent être contournés.

Pour résoudre le problème de QUOI accède à votre application mobile, vous devez utiliser une ou toutes les solutions mentionnées dans la série d'articles sur les techniques de sécurité des API mobiles que j'ai mentionnées ci-dessus et accepté qu'elles ne peuvent que rendre plus difficile l'accès non autorisé à votre serveur API. bypass mais pas impossible.

Une meilleure solution peut être utilisée en utilisant une solution d'attestation d'application mobile qui permettra au serveur d'API de savoir qu'il ne reçoit que les demandes d'une véritable application mobile.

Attestation d'application mobile

L'utilisation d'une solution d'attestation d'application mobile permettra au serveur API de savoir QUOI envoie les demandes, permettant ainsi de ne répondre qu'aux demandes d'une véritable application mobile tout en rejetant toutes les autres demandes provenant de sources non sécurisées.

Le rôle d'une solution d'attestation d'application mobile est de garantir au moment de l'exécution que votre application mobile n'a pas été falsifiée, qu'elle ne s'exécute pas dans un appareil enraciné, qu'elle n'est pas instrumentée par un framework comme xPosed ou Frida, qu'elle n'est pas attaquée par MitM, et ce est réalisé en exécutant un SDK en arrière-plan. Le service qui s'exécute dans le cloud mettra l'application au défi et, en fonction des réponses, il attestera l'intégrité de l'application mobile et de l'appareil sur lequel s'exécute, le SDK ne sera donc jamais responsable des décisions.

En cas d'attestation réussie de l'intégrité de l'application mobile, un jeton JWT de courte durée est émis et signé avec un secret que seuls le serveur d'API et le service d'attestation d'application mobile dans le cloud connaissent. En cas d'échec de l'attestation d'application mobile, le jeton JWT est signé avec un secret que le serveur API ne connaît pas.

Maintenant, l'application doit envoyer avec chaque appel API le jeton JWT dans les en-têtes de la demande. Cela permettra au serveur API de ne traiter les demandes que lorsqu'il peut vérifier la signature et l'heure d'expiration dans le jeton JWT et de les refuser en cas d'échec de la vérification.

Une fois que le secret utilisé par le service d'attestation d'application mobile n'est pas connu par l'application mobile, il n'est pas possible de le désosser au moment de l'exécution, même lorsque l'application est falsifiée, s'exécute dans un appareil enraciné ou communique via une connexion qui est le cible d'un homme au milieu de l'attaque.

Le service d'attestation d'application mobile existe déjà en tant que solution SAAS chez Approov (je travaille ici) qui fournit des SDK pour plusieurs plates-formes, notamment iOS, Android, React Native et autres. L'intégration nécessitera également une petite vérification du code du serveur API pour vérifier le jeton JWT émis par le service cloud. Cette vérification est nécessaire pour que le serveur d'API puisse décider des demandes à traiter et de celles à refuser.

Conclusion

Au final, la solution à utiliser pour protéger votre serveur API doit être choisie en fonction de la valeur de ce que vous essayez de protéger et des exigences légales pour ce type de données, comme la réglementation GDPR en Europe.

VOULEZ-VOUS ALLER EXTRA MILE?

Projet de sécurité mobile OWASP - Top 10 des risques

Le projet OWASP Mobile Security est une ressource centralisée destinée à donner aux développeurs et aux équipes de sécurité les ressources dont ils ont besoin pour créer et maintenir des applications mobiles sécurisées. À travers le projet, notre objectif est de classer les risques de sécurité mobile et de fournir des contrôles de développement pour réduire leur impact ou leur probabilité d'exploitation.



3

Je suis novice mais je vais essayer de donner une solution logique à la question donnée.

Il y aura deux options, [1] Pour chaque URI, l'authentification http sera effectuée où les informations d'identification entrées par l'utilisateur seront vérifiées et l'utilisateur devra accéder aux ressources.

[2] Une autre approche pourrait être, un utilisateur doit s'authentifier et sur chaque authentification un jeton unique sera généré. À l'aide du jeton généré, l'utilisateur doit accéder aux ressources.

Bien que je ne sache pas quelle approche pourrait être la mieux adaptée à une application mobile.


3

L'exemple d'authentification est un bon point de départ. Android stocke les informations d'identification dans le gestionnaire de compte, vous pouvez afficher les comptes dans les paramètres d'Android. Cela stockera automatiquement les jetons, demandera à l'utilisateur des informations d'identification si expiré ou manquant, actualisera les jetons, etc. Je trouve que la partie http de cet exemple manque ou est ancienne. L'extension AccountAuthenticatorActivity d'Android est une aide précieuse pour analyser les données sérialisées dans la mise en page et les renvoyer sur Internet.


-7

Le nom d'utilisateur et les mots de passe peuvent être sûrs lorsqu'ils sont placés dans SharedPreferences. L'utilisation de https pour se connecter à un serveur devrait également être suffisante.


Vous pouvez utiliser SharedPreferences mais vos données ne sont pas chiffrées par défaut. Si cela vous inquiète, consultez par exemple cette discussion sur SO: stackoverflow.com/questions/785973/…
Michael Helwig

3
SharedPreferences n'est pas un endroit sûr pour stocker les informations d'identification. Tout appareil enraciné (ce qui n'est pas difficile à faire) exposera ces informations d'identification. Utilisez plutôt l'API de compte intégrée.
Brill Pappin

Les SharedPreferences peuvent également être téléchargées à partir d'appareils non rootés, ce qui, si je ne me trompe pas, est possible via le mécanisme de sauvegarde du système Android. Il existe différents outils pour extraire des fichiers lisibles d'un fichier de sauvegarde Android.
Darthmail

@BrillPappin Question sur votre commentaire. Les informations d'identification stockées sont l'adresse e-mail et le mot de passe de l'utilisateur, plus un jeton à envoyer qui représente l'authentification actuelle avec cet e-mail. Si l'utilisateur choisit d'exposer ses propres informations d'identification à lui-même, via l'enracinement, comment est-ce un risque?
OutilleurSteve

Le risque est double. 1) toutes les données sensibles facilement accessibles que vous devez supposer seront accessibles. Vous ne vous en souciez peut-être pas vraiment, mais quelqu'un d'autre pourrait le faire. 2) le stockage d'une phrase de passe n'est pas sécurisé.
Brill Pappin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.