Meilleur moyen de sécuriser Private REST API sans authentification d'utilisateur pour application mobile
Je fais des API Restful pour mon application mobile.
La communication entre l’APP et le serveur Web doit être établie en mode REST. Ces apis devraient être privés, et seule mon application devrait pouvoir les appeler pour obtenir de bons résultats.
La partie difficile est, il n'y a aucun identifiant d'utilisateur et mot de passe requis dans mon application, donc je ne sais pas comment pourrais-je restreindre l'API reste avec l'application mobile sans authentification d'utilisateur de base.
Une solution à laquelle j’ai pensé consistait à intégrer une sorte de chaîne de code dur afin que, lorsque l’application mobile utilisera l’URL reposante, elle le transmette au format de cryptage sur SSL. Mais je sais que cela semble être une très mauvaise solution ..
de bien vouloir suggérer quelle devrait être la meilleure solution dans une telle situation.
Examinez le mécanisme du code d'authentification de message basé sur le hachage (HMAC).
Lien Wikipedia: http://fr.wikipedia.org/wiki/Hash-based_message_authentication_code
Votre client (application mobile) aura besoin d'une clé API public identifiant le client de service Web REST et d'une clé private/cryptographique. La clé API publique peut être envoyée avec la requête HTTP. C'est public et tout le monde peut le voir. Cependant, la clé privée ne doit jamais être envoyée avec la demande et ne doit être connue que par le serveur et le client. Cette clé est utilisée pour générer le message haché qui sera envoyé au serveur. Le HMAC peut être généré à l'aide d'un algorithme SHA1/MD5, un message devant être généré par un algorithme connu du serveur et du client et, enfin, la clé privée.
Vous avez raison, la clé intégrée dans l'application peut être facilement récupérée par des renifleurs de paquets ou par diverses autres techniques. Vous pouvez résoudre ce problème en utilisant les instructions suivantes.
- le client (votre application) appellera l'API requise
- le serveur le rejettera, mais en réponse, il enverra une chaîne contenant un hachage aléatoire (= challenge).
- le client utilise cette chaîne en combinaison avec une autre chaîne (= password) (déjà intégrée à l'application) pour générer un nouveau hachage (= digest)
- le client appellera à nouveau la même API, mais cette fois-ci en utilisant le condensé nouvellement créé comme paramètre d’authentification.
- le serveur validera ce résumé et procédera
Pour votre information: la procédure ci-dessus est une norme largement acceptée et est appelée Authentification Digest . Si vous avez besoin de plus d'aide, demandez simplement à Google "l'authentification Digest Android http".
Vous pouvez certes rendre le travail plus difficile pour les ingénieurs en rétro-ingénierie, mais vous ne pouvez pas le rendre pare-balles, comme le dit Nasir , en introduisant des problèmes mathématiques difficiles et en transformant votre chaîne codée en dur en conséquence.
Que dis-tu de ça. Supposons un nombre A codé en dur dans l'application. Le serveur envoie deux nombres B & P (P est un nombre premier élevé). Maintenant, vous pouvez calculer le nombre réel qui sera validé par le serveur en utilisant (A^B) % P. Votre application crypte maintenant la réponse de (A^B)%P avec Server's Public Key. Le serveur le déchiffrera avec sa clé privée, le validera et émettra un jeton (jwt peut-être) avec une date d'expiration. Ensuite, votre application et votre serveur peuvent communiquer à l'aide de ce jeton. Vous pouvez effectuer les calculs une fois lorsque l'application démarre et stocker le jeton pour une utilisation ultérieure.
Je suggère de créer un jeton complexe dans l'application, constitué de l'horodatage + appId + de toute autre valeur que vous pouvez répliquer sur le serveur, et de vous authentifier dans l'en-tête de chaque demande à l'aide de celles-ci.
Par exemple, vous pouvez créer un "utilisateur" virtuel dans votre base de données, y stocker le deviceToken et l'utiliser pour votre algorithme.
Personnellement, je garde une requête d'API publique, c'est-à-dire le getter d'horodatage, qui renvoie l'horodatage du serveur à utiliser dans les 300 secondes.
avant chaque requête, obtenez donc l'horodatage et envoyez votre jeton créé, répliquez-le sur le serveur et authentifiez ainsi la demande.
Un pirate informatique médiocre peut désosser l’application et répliquer vos jetons