Sobre HMAC

Um Exemplo de Implementação Básica de HMAC (Hash-based Message Authentication Code) Usando Flask em Python.

O que é HMAC?!

O código de autenticação de mensagem baseado em hash (HMAC) fornece ao servidor e ao cliente uma chave privada que é conhecida apenas por aquele servidor específico e aquele cliente específico. O cliente cria um HMAC único, ou hash, por requisição ao servidor, hasheando os dados da requisição com as chaves privadas e enviando-o como parte de uma requisição. O que torna o HMAC mais seguro do que o Message Authentication Code (MAC) é que a chave e a mensagem são hasheadas em etapas separadas.

Exemplo

(1) Requisição do Cliente para o Servidor

• Quando um cliente envia uma requisição ao servidor, ela inclui os seguintes cabeçalhos:

• X-Authorization-Content-HMAC: hash HMAC (URI completa da Requisição, Timestamp Unix Atual (UTC) e Chave Secreta HMAC)

• X-Authorization-Timestamp: Timestamp Unix Atual do Cliente (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 de Requisição do Cliente ]

• O cliente prepara e envia a requisição ao servidor.
• O servidor valida a requisição verificando a integridade do HMAC e a validade do timestamp.
• Se a validação for bem-sucedida, o servidor processa a requisição; caso contrário, envia uma resposta de erro.

(2) Resposta do Servidor para o Cliente

• Quando o servidor responde a uma requisição válida, ela inclui os seguintes cabeçalhos:

• X-Response-Content-HMAC: hash HMAC (Corpo completo da resposta, Timestamp Unix Atual (UTC) e Chave Secreta HMAC)

• X-Response-Content-TimeStamp: Timestamp Unix Atual (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 de Resposta ]

• O servidor prepara e envia os dados da resposta ao cliente.
• (Adicional) Se necessário, o cliente pode verificar a integridade HMAC dos dados da resposta.
• Se a validação falhar, o cliente rejeita os dados da resposta.

Server response HMAC verification successful
--------------
Response timestamp: 2024-03-29T09:25:31
Current time: 2024-03-29T09:25:31
Time difference: 0

Notas Adicionais

• Não há uma regra rigorosa sobre usar GET ou POST; no entanto, o POST é geralmente preferido por razões de segurança. Usar requisições GET pode fazer com que todas as strings de consulta sejam registradas nos logs de acesso web.
• Use sempre Timestamp Unix UTC para informações de timestamp para garantir consistência e evitar problemas relacionados a fuso horário.
• O escopo do cálculo HMAC pode variar. Embora normalmente envolva hashear todo o corpo da resposta, também é possível hashear dados seletivamente, especialmente quando o corpo da resposta é extenso.
• A escolha do algoritmo HMAC (por exemplo, Hmac-SHA256, Hmac-SHA512) e o comprimento da chave secreta devem ser baseados em requisitos de segurança e melhores práticas.

Prevenção de Ataques de Replay

• O servidor pode armazenar requisições processadas em memória (por exemplo, Redis) e descartar requisições repetidas dentro de um intervalo de tempo específico para prevenir ataques de replay.
• Além disso, o servidor pode aprimorar a prevenção de ataques de replay comparando o timestamp do cabeçalho (X-Authorization-Timestamp) enviado pelo cliente na requisição com o horário atual do servidor. Se o timestamp estiver fora de um determinado intervalo, o servidor pode descartar a requisição.

E...

Se você achou útil, por favor dê uma "estrela"🌟 para apoiar melhorias futuras.