Comment les clés API doivent-elles être générées?
Je veux m'assurer que les demandes ne peuvent pas être falsifiées et envoyées à mon serveur. Pour ce faire, je dois générer une clé API par utilisateur sur mon système. Le but de la clé sera de signer les demandes côté client et de les valider sur le serveur.
La question est de savoir de quoi sont généralement composées les clés API? S'agit-il simplement d'un nombre aléatoire cryptographiquement sécurisé (similaire à un mot de passe sel)? Ou y a-t-il une logique derrière eux, par exemple doivent-ils être constitués de données spécifiques à l'utilisateur.
Dans mon système, chaque utilisateur possède déjà un ID unique (GUID) qui n'est pas exposé publiquement. Pourrais-je l'utiliser comme "clé" ou une clé API doit-elle être différente d'un ID utilisateur?
Cela dépend de combien vous voulez séparer les rôles.
Système de base: votre "signature" est un MAC . La "clé API" est une valeur secrète partagée par le serveur et l'utilisateur. Les algorithmes MAC normaux comme HMAC peuvent utiliser des séquences arbitraires de bits comme clé, donc une clé est facilement générée en utilisant /dev/urandom (Linux, * BSD , MacOS X), en appelant CryptGenRandom() (Win32) ou en utilisant Java.security.SecureRandom (Java).
Système amélioré: votre signature est une vraie signature numérique . Cela a du sens si vous souhaitez séparer le générateur de clés (qui peut produire des clés qui seront acceptées par le serveur) du serveur lui-même (qui valide les signatures entrantes). Les clés pour les algorithmes de signature sont des objets mathématiques avec beaucoup de structure interne, et chaque algorithme implique un algorithme de génération de clé spécifique. Utilisez une bibliothèque qui implémente déjà les bits nécessaires (par exemple OpenSSL ).
Quoi qu'il en soit, il y a plus que la génération de clés et les signatures. Par exemple, vous voudrez probablement éviter rejouer les attaques: un tiers mal intentionné espionne le réseau et enregistre une demande valide signée par un utilisateur régulier. Plus tard, l'attaquant envoie à nouveau la requête, complète avec sa signature, afin de reproduire l'effet. Pour éviter les attaques de rejeu, vous devez ajouter une sorte de protocoles externes, et ces choses sont difficiles à faire (ce n'est pas difficile de définir un protocole; c'est très difficile à définir un secure protocole). Par conséquent, la chose intelligente à faire est de réutiliser un protocole existant et bien vérifié, ce qui, en pratique, signifie SSL/TLS .
Avec SSL, le "système de base" se réduit à envoyer la clé API dans un en-tête au début de la conversation (c'est exactement ce qui se passe avec l'authentification par mot de passe sur les sites Web HTTPS). Le "système amélioré" est alors "SSL avec un certificat client".