Informazioni su HMAC

Un esempio di implementazione di base di HMAC (Hash-based Message Authentication Code) utilizzando Flask in Python.

Cos'è HMAC?!

Il codice di autenticazione dei messaggi basato su hash (HMAC) fornisce al server e al client ciascuno una chiave privata nota solo a quel server e a quel client specifici. Il client crea un HMAC, o hash, unico per ogni richiesta al server, eseguendo l'hashing dei dati della richiesta con le chiavi private e inviandolo come parte di una richiesta. Ciò che rende HMAC più sicuro del Message Authentication Code (MAC) è che la chiave e il messaggio vengono sottoposti a hashing in passaggi separati.

Esempio

(1) Richiesta del Client al Server

• Quando un client invia una richiesta al server, include le seguenti intestazioni:

• X-Authorization-Content-HMAC: hash HMAC (URI completo della richiesta, timestamp Unix corrente (UTC) e chiave segreta HMAC)

• X-Authorization-Timestamp: timestamp Unix corrente del client (UTC)

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

[ Processo di richiesta del client ]

• Il client prepara e invia la richiesta al server.
• Il server convalida la richiesta verificando l'integrità HMAC e la validità del timestamp.
• Se la convalida ha successo, il server elabora la richiesta; altrimenti, invia una risposta di errore.

(2) Risposta del Server al Client

• Quando il server risponde a una richiesta valida, include le seguenti intestazioni:

• X-Response-Content-HMAC: hash HMAC (corpo completo della risposta, timestamp Unix corrente (UTC) e chiave segreta HMAC)

• X-Response-Content-TimeStamp: timestamp Unix corrente (UTC)

(response)
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}

[ Processo di risposta ]

• Il server prepara e invia i dati di risposta al client.
• (Aggiuntivo) Se necessario, il client può verificare l'integrità HMAC dei dati di risposta.
• Se la verifica fallisce, il client rifiuta i dati di risposta.

Verifica HMAC della risposta del server riuscita
--------------
Timestamp della risposta: 2024-03-29T09:25:31
Ora corrente: 2024-03-29T09:25:31
Differenza di orario: 0

Note aggiuntive

• Non esiste una regola rigorosa sull'uso di GET o POST; tuttavia, POST è generalmente preferito per motivi di sicurezza. L'uso di richieste GET può portare alla registrazione di tutte le stringhe di query nei log di accesso web.
• Utilizzare sempre il timestamp Unix UTC per le informazioni temporali per garantire coerenza ed evitare problemi relativi al fuso orario.
• L'ambito del calcolo HMAC può variare. Sebbene tipicamente coinvolga l'hashing dell'intero corpo della risposta, è possibile anche effettuare un hashing selettivo dei dati, specialmente quando il corpo della risposta è esteso.
• La scelta dell'algoritmo HMAC (es. Hmac-SHA256, Hmac-SHA512) e la lunghezza della chiave segreta dovrebbero basarsi sui requisiti di sicurezza e sulle best practice.

Prevenzione degli attacchi replay

• Il server può memorizzare le richieste elaborate in memoria (es. Redis) e scartare le richieste ripetute entro un intervallo di tempo specifico per prevenire attacchi replay.
• Inoltre, il server può migliorare la prevenzione degli attacchi replay confrontando l'intestazione del timestamp (X-Authorization-Timestamp) inviata dal client nell'intestazione della richiesta con l'ora corrente del server. Se il timestamp cade al di fuori di un certo intervallo, il server può scartare la richiesta.

E...

Se lo trovi utile, lascia una "stella"🌟 per supportare ulteriori miglioramenti.