Implémentation de clés Api (sécurisées) dans une application

Question

J'ai écrit une application Web et j'aimerais permettre à d'autres développeurs d'en obtenir les informations.

Le serveur sur lequel je travaille n'est pas si génial et ne peut pas gérer autant de requêtes, donc l'idée est de générer et d'assigner des clés api à tous ceux qui veulent interroger nos informations. Avec les clés Api, je peux limiter les requêtes quotidiennes et peut-être recueillir des statistiques pour voir quelles informations sont vraiment utiles pour les autres développeurs.

La chose est, Im préoccupé par l'aspect de la sécurité de celui-ci. Puisque la clé Api va être envoyée à notre serveur (via GET/POST, etc), quelqu'un peut sniffer la demande avec wireshark et obtenir la clé de l'API des développeurs sans trop d'effort, non? Je pensais à générer une clé secrète et une clé API. Je pourrais ensuite demander aux autres développeurs de les concaténer et d'en envoyer un hash à notre API. Je validerais alors que le hash est valide et permet la requête ... Mais alors le même problème persisterait. Un hacker peut toujours renifler ce hachage et faire des demandes au nom de l'application de l'autre développeur.

Mes questions sont

• Comment puis-je éviter ce problème?
• Ou mieux encore, mon inquiétude est-elle même valable? Est-ce un vrai problème?
• Existe-t-il un moyen plus sûr de permettre l'accès à mes informations sans que cela ne soit trop compliqué pour les autres développeurs?

Qu'en pensez-vous?

Answer 1

Je pense que vous essayez de résoudre un tas de questions différentes ici. Si votre objectif est de limiter le nombre de requêtes à votre serveur, vous devez créer un mécanisme de limitation. Ce n'est pas trivial, mais je me baserais sur l'adresse IP plutôt que sur une clé de licence - un seul utilisateur sous licence pourrait submerger votre système avec beaucoup de demandes. Vous pouvez limiter par adresse IP sans implémenter un mécanisme de licence.

Si vous voulez créer un système de licence, vous devez comprendre la cryptographie, etc. - c'est un problème non trivial. Par exemple, comment empêcher un utilisateur légitime de partager sa clé de licence avec tous ses amis? Comment empêchez-vous un pirate de voler votre clé et de la partager avec tous ses amis?

Il y a un certain nombre de solutions à cela - elles imposent toutes un certain degré de douleur à vos utilisateurs. Par exemple, vous pouvez exécuter votre service sur HTTPS; cela arrête de fouiner, mais réduit les performances. Vous pouvez émettre des "jetons" pour votre service expirant après un certain nombre d'utilisations; Obtenir de nouveaux jetons nécessite un échange cryptographique (qui pourrait vérifier votre adresse IP). Vous pourriez avoir besoin d'un type de logique "challenge/response" (incluant une validation d'adresse IP). Toutes ces étapes rendent la vie plus difficile pour vos utilisateurs; ils ne vous remercieront probablement pas beaucoup pour le travail supplémentaire qu'ils doivent faire.

Answer 2

En ce qui concerne sniff, votre problème peut être résolu avec HTTPS sur votre serveur.

Answer 3

Il est certainement logique de mettre une certaine authentification sur l'API si vous voulez limiter l'accès + potentiel à certaines limites de taux d'utilisation. Si vous utilisez une clé API et que vous voulez éviter de renifler, HTTPS est définitivement la solution. Si ce n'est pas une option, vous pouvez également utiliser une authentification hash-style comme oAuth 1.0 (http://oauth.net/core/1.0/) ou l'authentification Amazon AWS. Ceux-ci fonctionnent en émettant vos utilisateurs API avec un ID et un secret.Ils utilisent le secret du côté client en l'insérant dans le corps du message, en calculant un hachage et en incluant le hachage (pas le secret) dans la requête. Sur le côté entrant, vous comparez le hachage avec la même opération effectuée sur le contenu du message avec leur secret spécifique inclus. Cela signifie que vous pouvez vérifier l'expéditeur sans avoir à envoyer le secret sur le réseau (notez que le contenu n'est toujours pas sécurisé - mais vous évitez de passer la clé sur le fil à chaque requête). L'inconvénient est qu'il est complexe pour les développeurs à mettre en œuvre. Même si vous utilisez le modèle oAuth 1.0 dont il existe des bibliothèques, c'est un peu léger.

Je travaille sur 3scale et certains de nos outils peuvent également être utiles - nos systèmes fournissent des clés API, le partage d'oAuth Secret et aussi des limites de débit d'API (http://www.3scale.net et les bibliothèques PHP sont ici: https://github.com/3scale/3scale_ws_api_for_php).