Sécuriser une API: Authentification de base SSL et HTTP vs Signature

Question

Lors de la conception d'une API pour notre application web, nous allons utiliser la leur sous-domaine comme le 'nom d'utilisateur' et de générer une clé API/secret partagé. Tout d'abord, est-il ok pour utiliser le sous-domaine que le nom d'utilisateur? Je ne vois pas l'avantage de créer une autre clé.

Api différentes semblent faire une de deux choses:

1. Utiliser l'Authentification HTTP de Base avec SSL

Dans chaque demande le nom d'utilisateur est configuré pour le sous-domaine et le mot de passe de la clé API. Puisque nous utilisons le protocole SSL alors ce devrait être à l'abri de la mystification.

Notable Api: Google Checkout, Freshbooks, GitHub, Zendesk

1. Créer une Signature de la Demande avec le Secret Partagé

Normalement réalisée par la commande de l'paires clé/valeur et l'utilisation de HMAC-SHA1 avec le secret partagé pour générer la signature. La signature est alors envoyé avec la demande et vérifiées à l'autre extrémité.

Notable Api: Google Checkout, Amazon AWS

PS: c'est pas d'erreur, Google Checkout prend en charge à la fois

Edit: Viens de lire que OAuth 2 est en baisse de signatures en faveur de l'envoi d'un nom d'utilisateur/mot de passe via le protocole SSL.

Toutes les opinions de quelqu'un sur ce qu'il faut chercher: SSL vs Signature?

Answer 1

L'authentification HTTP de base sur SSL est parfaitement sécurisée par rapport à mes recherches.

Après tout, utiliser SSL (strictement TLS maintenant) signifie que la couche de transport est cryptée et que nous pouvons supposer en toute sécurité que toute information transmise est sécurisée et n’a pas été falsifiée.

Par conséquent, il suffit de passer le nom d'utilisateur et le mot de passe sans générer de signature.

Answer 2

Igor réponse n'est pas entièrement vrai. Bien que TLS permet de veiller à ce que la couche de transport est crypté et sécurisé, il n'est toujours pas sécurisé comme, par exemple, de TLS avec authentification mutuelle où le client s'authentifie à l'aide de "cryptographie forte" sous la forme d'une signature numérique. Il y a deux principales raisons à cela est toujours mieux que l'Authentification de Base sur TLS:

• Les mots de passe sont des mots de passe et je suppose que les trois hors de la désormais 7 milliards d'habitants sur notre planète utiliser un 30 caractères du mot de passe 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 dire que, pour le client, des signatures numériques côté il y a aussi un mot de passe, pour l'accès à la clé privée d'habitude. Mais c'est encore une toute autre situation que celle que nous avons avec l'Authentification Basique: tout d'abord la clé privée réside sur la machine du client de sorte que même si elle est récupérée, il affectera seulement une personne à la place de tout le monde et le deuxième, pour le type de conteneur de clé tels que les formats de fichier PKCS#12, il est également Chiffrement par Mot de passe utilisé pour accéder à la clé. Ces algorithmes ont été spécifiquement conçus pour ralentir les attaquants vers le bas pour réduire leur taux de brute-force de tentatives par unité de temps, encore une fois un avantage pour les signatures numériques.

Il ne fait aucun doute que le protocole TLS Authentification Basique est beaucoup plus pratique à installer et à utiliser, mais pour les environnements de haute sécurité je préfère toujours "la cryptographie forte" au cours d'utilisateur/mot de passe des solutions, il en vaut la peine.

Answer 3

Le problème Heartbleed avec OpenSSL illustre les pièges potentiels de l’utilisation exclusive de SSL pour la sécurisation d’une API. En fonction de l'utilisation de l'API et des implications si le transport SSL était compromis, des mesures de sécurité supplémentaires peuvent être nécessaires, comme indiqué dans la réponse d'Emboss.

Answer 4

C'est ok pour utiliser un sous-domaine comme nom d'utilisateur, tant qu'il y a une certaine forme de secret.

L'avantage de l'utilisation d'un secret partagé, c'est que la "partie" en faire la demande n'a pas besoin de connaître le secret, il a seulement besoin de savoir la signature d'effectuer la demande. Ceci est utile si vous voulez que vos utilisateurs pour autoriser les requêtes par l'intermédiaire d'un navigateur, par exemple.

À l'aide de S3, vous êtes en mesure de créer une signature, de l'envoyer au navigateur et à faire les téléchargements à partir d'un navigateur à S3.

Vous pouvez également utiliser HTTP Digest, ce qui a des avantages des deux. Vous pouvez facilement tester l'API dans un navigateur, parce que les navigateurs prennent en charge les Digérer et de Base, et une plaine de texte mot de passe n'est jamais transmis sur le fil.