Sécuriser une API: authentification de base SSL et HTTP 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érons une clé API / un secret partagé. Tout d’abord, est-il possible 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:

  1. Utiliser l’authentification de base HTTP avec SSL

Dans chaque requête, le nom d’utilisateur est défini sur le sous-domaine et le mot de passe sur la clé API. Étant donné que nous utilisons SSL, cela devrait être protégé contre l’usurpation d’identité.

API notables: Google Checkout , Freshbooks , GitHub , Zendesk

  1. Créer une signature de la demande avec le secret partagé

Normalement obtenu 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 laisse des signatures en faveur de l’envoi d’un nom d’utilisateur / mot de passe via SSL.

Des opinions de quiconque sur ce qu’il faut choisir: SSL vs Signature?

    L’authentification de base HTTP via SSL est parfaitement sécurisée par mes recherches.

    Après tout, l’utilisation de SSL (ssortingctement TLS maintenant) signifie que la couche de transport est cryptée et que nous pouvons supposer que toute information transmise par-dessus est sécurisée et n’a pas été falsifiée.

    Il suffit donc de passer le nom d’utilisateur et le mot de passe sans générer de signature.

    La réponse d’Igor n’est pas tout à fait vraie. Bien que TLS s’assure que la couche de transport est cryptée et sécurisée, elle n’est toujours pas aussi sécurisée que l’utilisation du protocole 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 ceci est encore meilleur que l’authentification de base sur TLS:

    • Les mots de passe sont des mots de passe et je suppose que trois des sept milliards de personnes sur notre planète utilisent un mot de passe de 30 caractères complètement aléatoire. Le rest 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 plutôt que des signatures numériques.

    • On pourrait faire valoir que pour les signatures numériques côté client, un mot de passe est également utilisé pour accéder à la clé privée. Mais la situation rest très différente de celle de l’authentification de base: tout d’abord, la clé privée réside en tant que ressource sur la machine du client. Même si elle est récupérée, elle n’affectera qu’une seule personne au lieu de tout le monde. Les formats de conteneur tels que PKCS # 12 contiennent également un cryptage basé sur un mot de passe 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, un avantage supplémentaire pour les signatures numériques.

    Il ne fait aucun doute que TLS Basic Auth est beaucoup plus pratique à configurer et à utiliser, mais pour des environnements hautement sécurisés, je préférerais toujours une «cryptographie forte» plutôt que des solutions utilisateur / mot de passe.

    Vous pouvez utiliser un sous-domaine comme nom d’utilisateur, à condition qu’il y ait 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, il lui suffit de connaître la signature pour exécuter la requête. Cela est bénéfique 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 présente les deux avantages. Vous pouvez toujours tester 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é via le réseau.

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

    Répondre à un vieux sujet car personne n’a vraiment touché le point principal

    SSL / TLS est fondamentalement imparfait, à l’ instar de toutes les infrastructures à clé publique, car elles reposent sur une chaîne de confiance qui s’est révélée de plus en plus vulnérable aux attaques MiM :

    • Les autorités de certificateion ont été et peuvent être piratées. Un exemple parmi d’autres est le cas DigiNotar où une autorité de certificateion a été compromise pendant des mois avant que la violation ait été accusée de révocation de tous les certificates. En attendant, le gouvernement iranien a créé de bons certificates SSL parfaitement valables pour google.com, facebook.com, twitter.com, etc.

    • Des outils de filtrage proxy d’entreprise tels que Zscaler qui décryptent et recryptent tout le trafic à la volée pour des «objectives de sécurité» non spécifiés. Voir cette question / réponse sur SO

    • Les 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 gros joueurs n’aiment pas utiliser uniquement SSL:

    Dans ces cas, un jeton HMAC ne vous donne pas de confidentialité, mais ne permet pas à quiconque espionne de vous de créer des requêtes avec vos informations d’identification , ce qui serait banal si vous les transmettiez via authentification de base.

    Une alternative au modèle PKI est le Web de confiance qui ne repose pas sur une seule autorité pour vérifier l’authenticité des certificates, mais plutôt sur l’opinion fournie par la majorité des pairs connus et fiables OU des pairs connus mais pas nécessairement de confiance.

    Ce modèle n’est pas encore parfait, car il est sujet à l’ attaque notoire de 51%, tout comme pour la Bitcoin Blockchain (qui est un exemple de modèle de confiance dissortingbué).

    Je voudrais souligner certaines choses mentionnées sur security.stackexchange.com car vous dites que “l’authentification HTTP de base sur SSL est parfaitement sécurisée par mes recherches”. Vous pourriez soutenir que les points 3 et 4 ci-dessous sont rarement valides pour les API REST, mais cela dépend vraiment de la manière dont ils sont mis en œuvre.

    “Il existe quelques problèmes avec HTTP Basic Auth:

    • Le mot de passe est envoyé sur le câble en codage base64 (qui peut être facilement converti en texte en clair).
    • Le mot de passe est envoyé à plusieurs resockets pour chaque requête. (Fenêtre d’attaque plus grande)
    • Le mot de passe est mis en cache par le navigateur Web, au minimum pour la longueur de la fenêtre / du processus. (Peut être réutilisé en silence par toute autre demande adressée au serveur, par exemple CSRF).
    • Le mot de passe peut être stocké de manière permanente dans le navigateur, si l’utilisateur
      demandes. (Identique au point précédent, peut en outre ê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, le protocole SSL ne protège que jusqu’à ce que le serveur Web, que ce soit le routage interne, la journalisation du serveur, etc., verra le mot de passe en clair.

    Donc, comme pour tout, il est important de regarder l’ensemble de l’image. HTTPS protège-t-il le mot de passe en transit? – Oui.

    Est-ce suffisant? Habituellement non. (Je tiens à dire, toujours non – mais cela dépend vraiment de ce que votre site est et à quel point il doit être sécurisé.) ”