Authentification sécurisée sur une application mobile

je cherche un moyen d'authentifier les utilisateurs de mon application mobile de manière sécurisée. L'application mobile est une application js pure, et utilise le cadre ionique (et donc cordova). L'application ne communiquera avec notre serveur que via L'API REST. Les exigences sont les suivantes:

  • le mécanisme doit s'appuyer sur un compte d'affaires autonome (I. le lien vers Google, Facebook ou toute autre API n'est pas une option.)
  • L'application va être dans les magasins
  • Comme un beaucoup de l'application mobile (Gmail, Facebook, ...) qui ne nécessite pas autant de sécurité que les applications bancaires, l'utilisateur doit être automatiquement authentifié après une première connexion ("remember me" pattern)

Ce que j'ai trouvé:

  • utilisation d'autres produits 2

OAuth 2 fournit un token de longue durée appelé "refresh token". J'aimerais l'utiliser avec une date d'expiration fixée à quelque chose comme un an.

Cependant, il semble qu'il n'y a pas d'argument mécanisme pour protéger le jeton. En effet, comme L'indique le commentaire de Jamsheed Kamarudeen sur cette réponsehttps://stackoverflow.com/a/7209263/863581, si le jeton de rafraîchissement, l'id client et l'id secret sont volés (en utilisant sniffing ou en les prenant directement à partir de l'appareil), l'attaquant sera en mesure d'avoir un accès illimité au compte de l'utilisateur... sans aucun moyen, AFAIK, de savoir ce qui se passe.

Renifler pourrait être difficile, parce que, évidemment, toutes les données seront envoyées par connexion sécurisée (SSL), mais il est encore possible, et cela doit être géré, de mon point de vue. En ce qui concerne le deuxième type d'attaque, "les prendre directement à partir de l'appareil", chaque solution que j'ai vu est sur le stockage des données (token ou cookie) sur le stockage local ou le cookie de navigateur (ce poste par exemple Using OAuth2 in HTML5 Web App). Même si l'exemple de ce post est de conseiller de stocker un hachage du jeton refresh, Je ne peux pas voir quel est le but de cela, parce que, comme mention par le commentaire de Mati Cicero, cela n'empêchera pas l'attaquant de pouvoir récupérer un jeton d'accès et avoir, dans mon cas, un accès illimité au compte de l'utilisateur.

de plus, de ce que je peux voir, localstorage et les cookies sont trop faciles à lire. Est-ce suffisant ou devrais-je utiliser le stockage sécurisé natif D'Android/iOS? Même le stockage local ne semble pas suffisant ( https://github.com/phonegap/phonegap/wiki/Platform-Security).

  • Utilisation du ressort sécurité

le côté serveur sera implémenté grâce à Spring. Le mecanisme fourni par Spring-security semble être meilleur que celui de OAuth 2 en ce qui concerne le modèle remember me (http://jaspan.com/improved_persistent_login_cookie_best_practice). Cependant, comme je l'ai compris, l'utilisateur final ne sera pas en mesure de se connecter deux fois sur l'application (disons, son mobile personnel et son professionnel). J'avoue que c'est pas un énorme problème, mais encore, il n'est pas parfait. Le plus important, à la fin, nous avons encore des problèmes de sécurité de stockage concernant les cookies/tokens.

c'est la première fois que je cherche un mecanisme de sécurité, donc peut-être que j'ai mal compris un mecanisme, s'il vous plaît faites le moi savoir. Cependant, je suis vraiment surpris de voir comment est-il difficile de trouver le bon processus. Je suis sûr que c'est un problème classique sur toutes les applications mobiles, mais je ne trouve pas de bonne façon de gérer ce problème.

ma question: comme vous pouvez le voir ci-dessus, je n'en ai pas trouvé mecanism sécurisé pour mettre en place ce processus de "connexion automatique" sur une application web mobile. Que dois-je installer? Avez-vous d'autres mécanismes que ceux que j'ai trouvé pour me présenter?

17
demandé sur Community 2015-07-13 12:09:51

3 réponses

se Souvenir de moi conséquences

votre désir d'avoir l'exigence "se souvenir de moi" signifie que (il y a aucun

pour OAUTH ou pas

OAUTH est agréable, mais si vous n'allez pas faire confiance à la commune de fournisseurs, alors pourquoi tous les frais généraux ? Laissez-les choisir un mot de passe sur votre site en une seule fois dans cette affaire et ne vous embêtez pas avec la façon dont back andforth devait le faire.

cela dit: Pourquoi ne pas faire confiance aux autres fournisseurs ? l'Utilisateur leur faisait confiance, sinon ils ne les choisiraient pas, et il est probable qu'ils utiliseront le même login et mot de passe partout de toute façon, donc ça n'a pas vraiment d'importance.

SSL

obtenir les informations d'identification en reniflant hors d'une connexion SSL correctement configurée: vous êtes bien au-delà de ce que même les utilisateurs les plus avancés comme les banques inquiéter. Mais configurez correctement SSL sur votre serveur!

un compromis sur" remember me"?

Que pouvez-vous faire pour améliorer la situation:

  • vous pouvez annuler la demande du client il est authentifié si votre serveur remarque les changements d'empreintes du navigateur, mais la session reste la même. Cela pourrait se produire en raison de mandataires mal configurés - mais peu d'entre eux sont autour. Et le pire des cas, l'utilisateur doit connecter encore.

  • vous pouvez utiliser Faire de l'adresse IP à des emplacements géo (pays par exemple) et si vous remarquez un changement de pays de la Dernière connexion sans qu'il s'agisse d'une connexion ré-authentifiée: ne pas honorer la mémoire et exiger une authentification correcte.

Protégez les cookies

  • Vous pouvez stocker des cookies dans un navigateur comme "sécurisé": cela signifie que le navigateur n'envoie le cookie au serveur si c'est sur une connexion https

  • vous pouvez aussi configurer un cookie pour qu'il soit httponly: Cela fait que le navigateur refuse l'accès au cookie à partir de javascript côté client (et tout ce qu'il va faire est de l'envoyer au serveur.

  • vous pouvez configurer httponly et secure en même temps ... (c'est ce que vous voulez).

4
répondu swa66 2015-07-16 23:20:58

quelle que soit la solution technique que vous choisirez finalement, la suivante reste vraie :

  • il ne s'agit pas d'une application mobile, toute l'architecture client / serveur est concernée
  • aucune façon de maintenir les logins sans risque de sécurité
  • le plus sûr moyen de chiffrer sur l'appareil
  • le seul meilleur moyen est la façon dont les applications de la banque utilisent: pas de persistance
  • toutefois, deux facteurs sigin est assez sécurisé trop
  • il n'est pas absolue réponse à cette question, il s'agit simplement de faire le meilleur choix entre ces considérations et les besoins de votre application!--4-->

EDIT

à Propos de encryt les informations d'identification

au sujet de l'encryt les informations d'identification, en effet, le code pourrait être lu, parce que le problème n'est pas l'algorithme de chiffrement, mais la clé privée à utiliser. Si vous voulez chiffrer les informations d'identification, vous devez mettre en œuvre une interface utilisateur qui permet à l'utilisateur de définir un code Shema ou pin ou tout autre secret à transformer en clé privée pour chiffrer puis déchiffrer les justificatifs d'identité de l'utilisateur.

mais si l'Utilisateur a perdu son NIP, vous devez générer de nouvelles informations d'identification côté serveur pour réinitialiser serveur-mot de passe puis réinitialiser client-secret côté client.

1
répondu Rémi Becheras 2015-07-16 07:20:17

Une façon de le faire est, vous pouvez stocker la clé privée et un jeton crypté, la question sera alors, où stocker la clé. Pour cela, si vous utilisez cordova, vous pouvez tout simplement faire un plugin pour cordoue et de stocker les clés. Au début de l'application, vous pouvez faire un appel à cordoue pour récupérer les clés. Puisque le plugin est en partie native, il sera compilé pour vous donner plus de sécurité.

0
répondu MJ Fathinia 2015-07-22 10:41:18