Authentification des requêtes depuis une application mobile (iPhone) vers l’API Web ASP.Net (commentaires demandés sur ma conception)

Je conçois un site Web qui aura un compagnon mobile (initialement iPhone uniquement). Le site Web sera une application ASP.Net MVC 3. Je disposerai également d’un site Web API ASP.Net (MVC 4) pour exposer les services à l’application iPhone. L’application iPhone aura son propre formulaire pour capturer le nom d’utilisateur et le mot de passe de l’utilisateur et l’envoyer à l’API Web dans les en-têtes JSON.

Je veux considérer la sécurité dès le départ plutôt qu’une reflection après coup. Je ne suis pas un expert en sécurité par tous les moyens. J’ai fait beaucoup de recherches pour voir comment les autres gèrent l’authentification d’un client d’application mobile à partir d’un service Web. Je pense avoir mis au point une solution décente qui ne nécessite pas de passer à des tiers.

J’apprécierais énormément toutes les opinions, tous les conseils, critiques et WTF généraux que chacun de vous peut offrir. 🙂

Mes plus grandes préoccupations sont:

  1. S’assurer que les appels effectués à l’API Web sont autorisés
  2. Minimiser le risque d’attaques de rejeu (d’où l’horodatage des appels ci-dessous)

L’application iPhone sera développée en tant que telle:
Deux chaînes sont codées en dur dans l’application iPhone (mêmes valeurs pour chaque utilisateur):

  1. ID d’application
    Cette chaîne est utilisée pour identifier le type de client qui accède à l’API Web (iPhone, Android, Windows Phone, etc.).
  2. Le sel de hachage de l’application
    Ceci est une chaîne utilisée pour saler les hachages pour les requêtes indépendantes de l’utilisateur.

Deux chaînes sont stockées dans la firebase database locale de l’application iPhone (valeurs propres à chaque utilisateur):

  1. Jeton d’access utilisateur API
    Il s’agit d’une chaîne (jeton) fournie au client par l’API Web après une authentification réussie et permettant au client d’accéder à l’API Web sans envoyer le nom d’utilisateur et le mot de passe dans chaque demande.
  2. Le sel de hachage de l’utilisateur
    Cette chaîne est utilisée pour saler les hachages pour les demandes effectuées sur des comptes d’utilisateur établis.

L’iPhone fera des appels à l’API Web de la manière suivante:

Méthode API: Créer un compte
Le client envoie:

  • Nouvelles données de compte (nom d’utilisateur, mot de passe, prénom, nom, etc.)
  • ID d’application
  • Horodatage UTC
  • Hash of UTC Timestamp + Identifiant d’application salé avec le sel de hachage de l’application

Retours API:

  • Nouvel Hashing Salt de l’utilisateur

    L’idée ici est que, lors de la création d’un compte, je peux utiliser le sel codé en dur de l’application car ce n’est pas un risque énorme pour la sécurité si ce sel est extrait (par décompilation ou par d’autres moyens).

    Mais pour les méthodes qui accèdent aux données de l’utilisateur et les modifient, j’utiliserai un sel qui appartient uniquement à cet utilisateur. Il ne peut donc pas être utilisé par un attaquant pour usurper l’identité d’autres utilisateurs.

Méthode API: Obtenir un compte
(Utilisé pour obtenir le hachage de l’utilisateur pour les comptes créés sur le site Web mais qui n’ont pas encore été synchronisés sur l’iPhone. Cela se produit lorsqu’un utilisateur essaie de se connecter sur l’iPhone et que iPhone détecte qu’il n’a aucun enregistrement pour ce nom d’utilisateur .)

Le client envoie:

  • Nom d’utilisateur
  • Mot de passe (haché avec le sel de hachage de l’application)
  • ID d’application
  • Horodatage UTC
  • Hash of UTC Timestamp + Identifiant d’application salé avec le sel de hachage de l’application

Retours API:

  • Sel de hachage de l’utilisateur existant

Méthode API: Connexion (authentification)
Le client envoie:

  • Nom d’utilisateur
  • Mot de passe (haché avec le sel de hachage de l’utilisateur)
  • ID d’application
  • Horodatage UTC
  • Hash of UTC Timestamp + Identifiant d’application salé avec du sel de hachage de l’utilisateur

Retours API:

  • Jeton d’access utilisateur API

Méthode API: Toute commande (c.-à-d. Créer un message, mettre à jour un profil, recevoir des messages, etc.)
Le client envoie:

  • Données de commande
  • Jeton d’access utilisateur API
  • ID d’application
  • Horodatage UTC
  • Hash de l’horodatage UTC + ID de l’application + jeton d’access utilisateur API salé avec le sel de hachage de l’utilisateur

Mes suggestions

  1. Authentification et autorisation. Construisez-le sur 2 serveurs différents (dans certains projets, j’ai également utilisé 3). Les serveurs proxy inverses sont vraiment bons avec cela. Authentifiez-vous sur un serveur et autorisez-le sur l’autre.

Il s’agit de l’étape la plus importante de la sécurité mobile qui, à mon avis, nécessite l’utilisation d’API Web.

  1. Encapsule tout.

  2. Utilisez SSL pour toutes les informations sécurisées. Dans mon cas, je l’utilise pour tout.

  3. Pour votre horodatage, sélectionnez une heure appropriée pour laquelle vous pouvez obtenir une autorisation. Ne faites pas cela très court car votre application deviendra lente ou trop longue car les renifleurs de réseau pourront accéder aux paquets.

Si vous souhaitez une architecture à 3 serveurs Pour vos demandes, vous devez également disposer d’une clé d’application que vous utilisez pour générer une clé d’access (à partir du serveur 1). Cette clé d’access authentifiera vos demandes qui, après une authentification réussie (à partir du serveur 2), vous pourrez utiliser cette clé pour autoriser vos requêtes depuis un autre serveur (serveur 3)

Les demandes que vous avez mentionnées sont des normes standard. Ne vois pas vraiment de problème avec ça.

Je l’ai fait en utilisant l’effectif de base asp.net mvc 4.0 / web api. vous pouvez le trouver utile.

Oui, utilisez SSL à coup sûr

https://github.com/aamir-poswal/Mobile-Apps-Authentication-Authorization-ASP.NET-WEB-MVC-4.0

Dans VS 2013, vous pouvez utiliser le modèle “Asp MVC SPA Application” pour générer une implémentation qui génère un support de jeton Oauth2 lors de la connexion et l’autorise pour les appels du contrôleur WebApi à l’aide des atsortingbuts [Authorize]. Il utilise Membership et Entity Framework pour stocker les utilisateurs et les hachages localement dans un serveur SQL. Supprimez simplement les parties d’asp mvc dont vous n’avez pas besoin et conservez le composant Auth pour WebApi. Plus de détails ici: http://msdnrss.thecoderblogs.com/2013/09/understanding-security-features-in-the-spa-template-for-vs2013-rc/