À propos de HMAC

Un exemple d'implémentation de HMAC de base (Hash-based Message Authentication Code) utilisant Flask en Python.

Qu'est-ce que HMAC ?!

Le code d'authentification de message basé sur le hachage (HMAC) fournit au serveur et au client chacun une clé privée connue uniquement de ce serveur et de ce client spécifiques. Le client crée un HMAC unique, ou hachage, par requête au serveur en hachant les données de la requête avec les clés privées et en l'envoyant dans le cadre de la requête. Ce qui rend HMAC plus sécurisé que le code d'authentification de message (MAC) est que la clé et le message sont hachés en deux étapes distinctes.

Exemple

(1) Requête du client au serveur

• Lorsqu'un client envoie une requête au serveur, il inclut les en-têtes suivants :

• X-Authorization-Content-HMAC : hachage HMAC (URI complète de la requête, horodatage Unix actuel (UTC) et clé secrète HMAC)

• X-Authorization-Timestamp : horodatage Unix actuel du client (UTC)

(requête)
GET /example/users?user=test&institutionID=999&signature=7e745d74b69b7f62e8e2 HTTP/1.1
Host: example.com
X-Authorization-Content-HMAC: 1c73495878ccea24af9dd281a4c883c40a3551ba799d30f4ad7d9afb6a60fbd4
X-Authorization-Timestamp: 1711662980

[ Processus de la requête client ]

• Le client prépare et envoie la requête au serveur.
• Le serveur valide la requête en vérifiant l'intégrité HMAC et la validité de l'horodatage.
• Si la validation réussit, le serveur traite la requête ; sinon, il envoie une réponse d'erreur.

(2) Réponse du serveur au client

• Lorsque le serveur répond à une requête valide, il inclut les en-têtes suivants :

• X-Response-Content-HMAC : hachage HMAC (corps complet de la réponse, horodatage Unix actuel (UTC) et clé secrète HMAC)

• X-Response-Content-TimeStamp : horodatage Unix actuel (UTC)

(réponse)
HTTP/2 200 OK
Date: Fri, 29 Mar 2024 06:50:49 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 52
X-Response-Content-HMAC: 529c33aac3e33bf2a95d534f8b3ac61dee2ed79232d729e571dc669417a1a2ae
X-Response-Content-TimeStamp: 1711663027
Connection: close

{"result": "ok", "users": "test", "sub": 2840345654}

[ Processus de réponse ]

• Le serveur prépare et envoie les données de réponse au client.
• (Supplémentaire) Si nécessaire, le client peut vérifier l'intégrité HMAC des données de réponse.
• Si la validation échoue, le client rejette les données de réponse.

Vérification HMAC de la réponse du serveur réussie
--------------
Horodatage de la réponse : 2024-03-29T09:25:31
Heure actuelle : 2024-03-29T09:25:31
Différence de temps : 0

Notes supplémentaires

• Il n'y a pas de règle stricte concernant l'utilisation de GET ou POST ; cependant, POST est généralement préféré pour des raisons de sécurité. L'utilisation de requêtes GET peut entraîner la journalisation de toutes les chaînes de requête dans les journaux d'accès Web.
• Utilisez toujours l'horodatage Unix UTC pour les informations temporelles afin de garantir la cohérence et d'éviter les problèmes liés aux fuseaux horaires.
• La portée du calcul HMAC peut varier. Bien qu'elle implique généralement le hachage du corps entier de la réponse, un hachage sélectif des données est également possible, surtout lorsque le corps de la réponse est volumineux.
• Le choix de l'algorithme HMAC (par exemple, Hmac-SHA256, Hmac-SHA512) et la longueur de la clé secrète doivent reposer sur les exigences de sécurité et les meilleures pratiques.

Prévention des attaques par rejeu

• Le serveur peut stocker les requêtes traitées en mémoire (par exemple, Redis) et ignorer les requêtes répétées dans un intervalle de temps spécifique pour prévenir les attaques par rejeu.
• De plus, le serveur peut renforcer la prévention des attaques par rejeu en comparant l'en-tête d'horodatage (X-Authorization-Timestamp) envoyé par le client dans l'en-tête de la requête avec l'heure actuelle du serveur. Si l'horodatage se situe en dehors d'une certaine fenêtre temporelle, le serveur peut ignorer la requête.

Et...

Si vous trouvez cela utile, veuillez cliquer sur "⭐" pour soutenir les améliorations futures.