Sécurisation d'une API: authentification SSL et HTTP de base vs signature
Lors de la conception d'une API pour notre application Web, nous utiliserons leur sous-domaine comme "nom d'utilisateur" et générerons une clé API/un secret partagé. Tout d'abord, est-il acceptable d'utiliser le sous-domaine comme nom d'utilisateur? Je ne vois pas l'avantage de générer une autre clé.
Différentes API semblent faire l'une des deux choses suivantes:
- Utilisez l'authentification de base HTTP avec SSL
Dans chaque demande, le nom d'utilisateur est défini sur le sous-domaine et le mot de passe sur la clé API. Puisque nous utilisons SSL, cela devrait être à l'abri de l'usurpation d'identité.
API notables: Google Checkout , Freshbooks , GitHub , Zendesk
- Créez une signature de la demande avec le secret partagé
Normalement atteint en ordonnant les paires clé/valeur et en utilisant HMAC-SHA1 avec le secret partagé pour générer la signature. La signature est ensuite envoyée avec la demande et vérifiée à l'autre extrémité.
API notables: Google Checkout , Amazon AWS
PS: ce n'est pas une erreur, Google Checkout prend en charge les deux
Edit: Il suffit de lire que OAuth 2 supprime les signatures en faveur de l'envoi d'un nom d'utilisateur/mot de passe via SSL.
Des opinions de quiconque sur quoi choisir: SSL vs Signature?
L'authentification de base HTTP sur SSL est parfaitement sécurisée de mes recherches.
Après tout, l'utilisation de SSL (strictement TLS maintenant) signifie que la couche de transport est cryptée et nous pouvons supposer en toute sécurité que toutes les informations transmises sont sécurisées et n'ont pas été falsifiées.
Il suffit donc de transmettre le nom d'utilisateur et le mot de passe sans générer de signature.
La réponse d'Igor n'est pas entièrement vraie. Bien que TLS garantisse que la couche de transport est cryptée et sécurisée, elle n'est toujours pas aussi sécurisée que l'utilisation, par exemple, de TLS avec authentification mutuelle où le client s'authentifie en utilisant une "cryptographie forte" sous la forme d'une signature numérique. Il y a deux raisons principales pour lesquelles c'est encore mieux que l'authentification de base sur TLS:
Les mots de passe sont des mots de passe et je suppose que trois des 7 milliards de personnes sur notre planète utilisent un mot de passe de 30 caractères qui est complètement aléatoire. Le reste d'entre nous a choisi quelque chose avec beaucoup moins d'entropie. Par conséquent, il est beaucoup plus facile pour un attaquant de forcer un service qui utilise des mots de passe au lieu de signatures numériques.
On pourrait faire valoir que pour les signatures numériques côté client, il y a également un mot de passe, pour accéder à la clé privée en général. Mais c'est toujours une situation très différente de celle que nous avons avec Basic Auth: d'abord la clé privée réside en tant que ressource sur la machine du client, donc même si elle est récupérée, elle n'affectera qu'une personne au lieu de tout le monde et deuxièmement, pour la clé typique des formats de conteneurs tels que PKCS # 12, un cryptage par mot de passe est également utilisé pour accéder à la clé. Ces algorithmes ont été spécifiquement conçus pour ralentir les attaquants afin de réduire leur taux de tentatives de force brute par unité de temps, encore un avantage pour les signatures numériques.
Il ne fait aucun doute que TLS Basic Auth est beaucoup plus pratique à configurer et à utiliser, mais pour les environnements de haute sécurité, je préférerais toujours la "cryptographie forte" aux solutions utilisateur/mot de passe, cela en vaut la peine.
Le problème Heartbleed avec OpenSSL illustre les pièges potentiels liés à l'utilisation exclusive de SSL pour sécuriser une API. Selon l'utilisation de l'API et ses implications si le transport SSL était compromis, des mesures de sécurité supplémentaires peuvent devoir être prises comme indiqué dans la réponse d'Emboss.
Il est correct d'utiliser un sous-domaine comme nom d'utilisateur, tant qu'il existe une forme de secret.
L'avantage d'utiliser un secret partagé est que la "partie" qui fait la demande n'a pas besoin de connaître le secret, elle a seulement besoin de connaître la signature pour exécuter la demande. Cela est avantageux si vous souhaitez que vos utilisateurs autorisent les demandes via un navigateur, par exemple.
En utilisant S3, vous pouvez créer une signature, l'envoyer au navigateur et effectuer des téléchargements directs depuis un navigateur vers S3.
Vous pouvez également utiliser HTTP Digest, qui bénéficie des deux. Vous pouvez toujours tester facilement l'API dans un navigateur, car les navigateurs prennent en charge Digest et Basic, et un mot de passe en texte brut n'est jamais envoyé par câble.
Je voudrais souligner certaines choses mentionnées sur security.stackexchange.com puisque vous dites que "l'authentification de base HTTP sur SSL est parfaitement sécurisée de mes recherches.". Vous pourriez faire valoir que les points 3 et 4 ci-dessous sont rarement valides pour les API REST mais cela dépend vraiment de la façon dont elles sont implémentées.
"Il y a quelques problèmes avec HTTP Basic Auth:
- Le mot de passe est envoyé sur le câble en encodage base64 (qui peut être facilement converti en texte brut).
- Le mot de passe est envoyé à plusieurs reprises, pour chaque demande. (Fenêtre d'attaque plus grande)
- Le mot de passe est mis en cache par le navigateur Web, au minimum pour la durée de la fenêtre/du processus. (Peut être réutilisé en silence par toute autre demande au serveur, par exemple CSRF).
- Le mot de passe peut être stocké en permanence dans le navigateur, si l'utilisateur
demandes. (Identique au point précédent, en plus peut être volé par
un autre utilisateur sur une machine partagée).
Parmi ceux-ci, l'utilisation de SSL ne résout que le premier. Et même avec cela, SSL ne protège que jusqu'au serveur Web - tout routage interne, journalisation du serveur, etc., verra le mot de passe en clair.
Donc, comme pour tout, il est important de regarder l'ensemble du tableau. HTTPS protège-t-il le mot de passe en transit? - Oui.
Est-ce suffisant? Habituellement, non. (Je veux dire, toujours non - mais cela dépend vraiment de la nature de votre site et de sa sécurité.) "
Répondre à un vieux fil car personne n'a vraiment abordé le point principal
SSL/TLS est fondamentalement défectueux comme toutes les PKI car elles s'appuient sur une chaîne de confiance qui a été prouvée de plus en plus souvent vulnérable à MiM attaques :
Les autorités de certification ont été et peuvent être piratées. Un exemple parmi tant d'autres est le cas DigiNotar où une autorité de certification a été compromise pendant des mois avant que la violation ne soit reconnue, tous les certificats ont été révoqués. Entre-temps, le gouvernement iranien avait forgé des certificats SSL parfaitement valables pour Nice pour google.com, facebook.com, Twitter.com, etc.
Des outils de filtrage de proxy d'entreprise comme Zscaler qui déchiffrent et rechiffrent tout le trafic à la volée à des "fins de sécurité" non spécifiées. Voir cette question/réponse sur SO
Des bogues avec l'implémentation SSL la plus courante (openSSL) sont découverts tout le temps (mais les choses devraient s'améliorer avec le temps?)
Par conséquent, les grands acteurs n'aiment pas se fier uniquement à SSL:
Dans ces cas, un jeton HMAC ne vous confère pas la confidentialité mais ne permet pas à quiconque vous espionne de forger des demandes avec vos informations d'identification , ce qui serait autrement trivial si vous venez de les passer via l'authentification de base.
Une alternative au modèle PKI est le Web of trust qui ne s'appuie pas sur une seule autorité pour vérifier l'authenticité des certificats mais plutôt sur l'opinion fournie par la majorité des pairs connus et fiables OR - pairs connus mais pas nécessairement fiables
Ce modèle n'est pas encore parfait car il est soumis à la notoire 51% d'attaque exactement comme pour la Blockchain Bitcoin (c'est un exemple d'un modèle de confiance distribué)