Comment fonctionnent les clés API et les clés secrètes? Serait-il sécurisé si je dois passer mon API et mes clés secrètes à une autre application?
Je commence tout juste à réfléchir au fonctionnement des clés API et des clés secrètes. Il y a à peine 2 jours, je me suis inscrit à Amazon S3 et ai installé le plugin S3Fox . Ils m'ont demandé à la fois ma clé d'accès et ma clé d'accès secrète, ce qui nécessite que je me connecte pour pouvoir y accéder.
Je me demande donc, s'ils me demandent ma clé secrète, ils doivent la stocker quelque part, n'est-ce pas? N'est-ce pas fondamentalement la même chose que de me demander mes numéros de carte de crédit ou mon mot de passe et de les stocker dans leur propre base de données?
Comment les clés secrètes et les clés API doivent-elles fonctionner? À quel point doivent-ils être secrets? Ces applications utilisant les clés secrètes les stockent-elles d'une manière ou d'une autre?
Élaborer essentiellement sur ce qui est décrit ici .
Voici comment cela fonctionne: supposons que nous ayons une fonction qui prend un nombre de zéro à neuf, ajoute trois et, si le résultat est supérieur à dix, soustrait dix. Donc f(2) = 5, f(8) = 1, etc.). Maintenant, nous pouvons créer une autre fonction, appelez-la f ', ça va à l'envers, en ajoutant sept au lieu de trois: f '(5) = 2, f' (1) = 8, etc.
C'est un exemple de fonction bidirectionnelle et de son inverse. Théoriquement, toute fonction mathématique qui associe une chose à une autre peut être inversée. En pratique, cependant, vous pouvez créer une fonction qui brouille tellement son entrée qu’il est extrêmement difficile d’inverser.
Prendre une entrée et appliquer une fonction unidirectionnelle est appelée "hachage" de l'entrée. Ce que Amazon stocke sur son système est un "hachage" de votre clé secrète. SHA1 est un exemple de ce type de fonction "à sens unique", elle est également renforcée contre les attaques.
Le fonction HMAC s'appuie sur les fonctions de hachage établies pour utiliser une clé connue afin d'authentifier une chaîne de texte. Cela fonctionne comme ceci:
- Vous prenez le texte de votre demande et votre clé secrète et appliquez la fonction HMAC.
- Vous ajoutez cet en-tête d'authentification à votre demande et l'envoyez à Amazon.
- Amazon recherche leur copie de la clé secrète et le texte que vous venez d'envoyer et applique la fonction HMAC.
- Si le résultat correspond, ils savent que vous avez la même clé secrète.
La différence entre cela et l'infrastructure à clé publique est que cette méthode est RESTful , permettant un nombre minimal d'échanges entre votre système et les serveurs Amazon.
N’est-ce pas fondamentalement la même chose que de me demander mes numéros de carte de crédit ou mon mot de passe et de les stocker dans leur propre base de données?
Oui, bien que les dommages causés par S3 semblent limités à l’épuisement de votre compte.
À quel point doivent-ils être secrets? Ces applications utilisant les clés secrètes les stockent-elles d'une manière ou d'une autre?
À un moment donné, vous devrez charger la clé secrète, et avec la plupart des systèmes basés sur Unix, si un attaquant peut obtenir un accès root, il peut obtenir la clé. Si vous chiffrez la clé, vous devez disposer d'un code pour la déchiffrer et, à un moment donné, le code de déchiffrement doit être en texte brut pour pouvoir être exécuté. C'est le même problème que DRM a, sauf que vous possédez l'ordinateur.
Dans de nombreux cas, je mets simplement des clés secrètes dans un fichier avec des autorisations limitées et je prends les précautions habituelles pour empêcher l’installation de mon système. Il existe quelques astuces pour le faire fonctionner correctement avec un système multi-utilisateur, comme par exemple éviter les fichiers temporaires.
Cryptographie à clé publique est utilisé pour se défendre contre des attaques très spécifiques, dont certaines sont courantes. En bref, il s’agit d’un calcul complexe qui permet de vérifier qu’un individu possède à la fois la paire clé publique et clé privée tout en ne connaissant que la clé publique. C'est très différent d'une carte de crédit ou d'un mot de passe statique. Par exemple, si vous vous authentifiez avec un serveur OpenSSH, le serveur n'a pas besoin de la clé privée .
Idéalement, si la base de données d'API d'Amazon devait être compromise, l'attaquant disposerait d'une liste de clés publiques et ne pourrait pas accéder à l'API de l'utilisateur à l'aide de ces informations. Cependant, les systèmes idéaux ne sont pas toujours mis en pratique et je ne sais pas si Amazon protège contre ce vecteur d'attaque, mais ils devraient l'être.
Dans les clés publiques, l'authentification est statistiquement à l'abri de la force brute. Les mots de passe sont souvent des mots du dictionnaire qui peuvent être cassés rapidement. Cependant, une clé privée est un nombre énorme difficile à deviner. Si l'attaquant disposait de la clé publique, il pourrait alors effectuer de nombreuses suppositions "hors ligne" sur un super-ordinateur, mais même dans ce cas, il faudrait beaucoup de temps et d'argent pour casser la clé.
AWS a conçu son propre algorithme d'authentification personnalisé. La v4 a été publiée en 2014. Les détails sont décrits ci-dessous: Authentification de demandes (AWS Signature version 4) . Un point important est que la demande n'est pas signée avec le secret lui-même, mais avec une clé de signature générée à l'aide du secret. Il utilise également HMAC-SHA256 pour la signature.
L'utilisation de clés asymétriques serait plus sûre car AWS ne stockerait qu'une clé publique au lieu du secret, qui est stocké à la fois par l'utilisateur et par AWS.