Authentification des demandes d'une application mobile (iPhone) vers une API Web ASP.Net (des commentaires ont été demandés sur ma conception)

Question

Je suis de la conception d'un site web qui sera un compagnon mobile (initally iPhone uniquement). Le site web sera un ASP.Net MVC 3 application. Je vais aussi avoir un ASP.Net l'API Web site (MVC 4) pour exposer les services de l'application iPhone. L'application iPhone a son propre formulaire de capture nom d'utilisateur et le mot de passe de l'utilisateur et l'envoyer sur le web API JSON-têtes.

Je veux considérer la sécurité dès le début plutôt qu'après avoir pensé. Je ne suis pas un expert en sécurité par tous les moyens. J'ai fait beaucoup de recherches pour voir comment les autres sont de la gestion de l'authentification d'une application mobile de client à partir d'un service web. Je pense que je suis venu avec une solution décente qui n'implique pas de se connecter à des tiers oAuths.

Je vous serais très reconnaissant de tout et de tous les avis, conseils, critiques et général WTFs que vous pouvez offrir. :)

Mon plus gros soucis sont:

1. Veiller à ce que les appels effectués à l'API web sont autorisés
2. En minimisant le risque d'attaques récurrentes (d'où les horodateurs dans les appels ci-dessous)

L'application iPhone sera développée en tant que telle:
Deux chaînes de caractères sont codés en dur dans l'application iPhone (même valeurs pour chaque utilisateur):

1. ID de l'Application
   C'est une chaîne de caractères qui est utilisé pour identifier le type de client qui accède au web API (iPhone, Android, Windows phone, etc).
   
2. L'Application de Hachage de Sel
   C'est une chaîne de caractères qui est utilisé pour le sel hachages pour l'utilisateur agnostique demandes.

Deux chaînes de caractères sont stockées dans l'iPhone de l'application locale de la base de données (valeurs uniques pour chaque utilisateur):

1. API Jeton d'Accès Utilisateur
   C'est une chaîne de caractères (token) fournis au client par l'API web sur la réussite de l'authentification et permet au client d'accéder à l'API de web sans l'envoi du nom d'utilisateur et le mot de passe à chaque demande.
   
2. L'utilisateur du Hachage de Sel
   C'est une chaîne de caractères qui est utilisé pour le sel de hachages pour les demandes faites à l'encontre des comptes d'utilisateur.

L'iPhone va faire des appels à l'API web de la manière suivante:

Méthode de l'API: Créer un Compte
Client Envoie:

• De nouvelles Données de Compte (nom d'utilisateur, Mot de passe, prénom, Nom, etc..)
• ID de l'Application
• Horodatage UTC
• Hachage de Horodatage UTC + ID de l'Application salé avec l'Application de Hachage de Sel

API Retourne:

• Nouvel Utilisateur de Hachage de Sel
  
  L'idée ici est que, lors de la création d'un compte, je peux utiliser l'application est codée en dur de sel, car il n'est pas un énorme risque de sécurité si le sel que jamais obtenu (grâce à la décompilation ou autre).
  
  Mais pour les méthodes d'accès et modifier les données de l'utilisateur, je vais utiliser un sel qui est détenue uniquement par l'utilisateur de sorte qu'il ne peut pas être utilisé par un attaquant d'usurper l'identité d'autres.

Méthode de l'API: Obtenir Compte
(Utilisé pour l'obtention de l'utilisateur de hachage de sel pour les comptes qui ont été 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 d'ouvrir une session sur l'iPhone et l'iPhone détecte qu'il n'a pas de dossier pour que le nom d'utilisateur.)

Client Envoie:

• Nom d'utilisateur
• Mot de passe (hachés avec l'Application de Hachage de Sel)
• ID de l'Application
• Horodatage UTC
• Hachage de Horodatage UTC + ID de l'Application salé avec l'Application de Hachage de Sel

API Retourne:

• Utilisateur existant de Hachage de Sel

Méthode de l'API: connectez-vous (Authentifier)
Client Envoie:

• Nom d'utilisateur
• Mot de passe (hachés avec de l'Utilisateur de Hachage de Sel)
• ID de l'Application
• Horodatage UTC
• Hachage de Horodatage UTC + ID de l'Application salé avec de l'Utilisateur de Hachage de Sel

API Retourne:

• API Jeton d'Accès Utilisateur

Méthode de l'API: Toute Commande (c'est à dire Créer de Poste, mise à Jour de Profil, Obtenez des Messages, etc...)
Client Envoie:

• Les Données De La Commande
• API Jeton d'Accès Utilisateur
• ID de l'Application
• Horodatage UTC
• Hachage de Horodatage UTC + ID de l'Application + API Jeton d'Accès Utilisateur salé avec de l'Utilisateur de Hachage de Sel

Answer 1

En VS 2013, vous pouvez utiliser le bouton "Asp MVC SPA Application" modèle pour générer un travail de mise en œuvre qui est la génération d'un Oauth2 jeton du porteur de connexion, et l'autoriser pour WebApi contrôleur des appels à l'aide de [Autoriser] attributs. Il utilise l'Adhésion et Entity Framework pour stocker les utilisateurs et les hachages localement dans un Serveur SQL server. Il suffit de supprimer l'asp mvc pièces que vous n'avez pas besoin et de garder la Auth partie pour WebApi. Plus de détails ici: http://msdnrss.thecoderblogs.com/2013/09/understanding-security-features-in-the-spa-template-for-vs2013-rc/

Answer 2

Je l'ai fait en utilisant un abonnement de base asp.net mvc 4.0 / web api. vous pouvez trouver cela utile.

Oui, utilisez SSL pour vous

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

Answer 3

Mes suggestions

1. L'authentification et l'Autorisation. Construire sur 2 serveurs différents(Dans certains projets, j'ai utilisé 3 ainsi). Les serveurs proxy inverses sont vraiment bonnes avec ce. S'authentifier sur un serveur et de l'autoriser sur l'autre.

C'est l'étape la plus importante, je pense que ce qui est nécessaire à la sécurité mobile qui utilisent les Api Web.

1. Encapsuler tout.

2. Utiliser SSL pour toutes les informations de sécurité. Dans mon cas je l'utilise pour tout.

3. Pour votre timestamp sélectionnez un temps convenable pour lesquelles vous pouvez disposer de l'autorisation. Ne pas faire de cette très courte que votre application va devenir lent ou trop longtemps que renifleurs de réseau peuvent accéder aux paquets.

Si vous voulez un serveur 3 architecture De vos demandes d'avoir une clé d'application que vous utilisez pour générer une clé d'accès (à partir de 1 Serveur). Cette clé d'accès sera authentifier vos demandes, ce qui une fois l'authentification réussie(à partir du serveur 2) vous pouvez utiliser cette clé pour autoriser vos demandes à partir d'un autre serveur(3)

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