HmacAuthentication
1.0.0
O código de autenticação de mensagem baseado em hash (HMAC) é um mecanismo para calcular um código de autenticação de mensagem envolvendo uma função hash em combinação com uma chave secreta. Isso pode ser usado para verificar a integridade e autenticidade de uma mensagem.
Esta implementação é altamente inspirada no principal método de autenticação usado pela Amazon Web Services (AWS Signature V4), pois é muito bem compreendido e existem várias bibliotecas que o implementam. Para usar esta forma de autenticação, você utiliza um identificador de chave e uma chave secreta, ambos normalmente gerados em uma interface administrativa.
HmacAuthentication fornece um AuthenticationHandler que oferece suporte à autenticação HMAC em um projeto ASP.NET Core.
Uso:
appsettings.json . Para autenticação HMAC, um AppId e um ApiKey são necessários para cada cliente que deve obter acesso. var hmacAuthenticatedApps = this . Configuration
. GetSection ( " Authentication " )
. GetSection ( " HmacAuthenticatedApps " )
. Get < HmacAuthenticationClientConfiguration [ ] > ( )
. ToDictionary ( e => e . AppId , e => e . ApiKey ) ; {
"Authentication" : {
"HmacAuthenticatedApps" : [
{
"AppId" : " <some-app-id> " ,
"ApiKey" : " <some-api-key> "
}
]
}
}Startup.cs no método ConfigureServices : services
. AddAuthentication ( o =>
{
o . DefaultScheme = HmacAuthenticationDefaults . AuthenticationScheme ;
} )
. AddHmacAuthentication ( HmacAuthenticationDefaults . AuthenticationScheme , " HMAC Authentication " , o =>
{
o . MaxRequestAgeInSeconds = HmacAuthenticationDefaults . MaxRequestAgeInSeconds ;
o . HmacAuthenticatedApps = hmacAuthenticatedApps ;
} ) ;MemoryCache (de Microsoft.Extensions.Caching.Memory) em Startup.cs no método ConfigureServices . O MemoryCache é usado pelo HMAC AuthenticationHandler para determinar ataques de repetição. services . AddMemoryCache ( ) ;Startup.cs no método Configure : app . UseAuthentication ( ) ; [ Authorize ( AuthenticationSchemes = HmacAuthenticationDefaults . AuthenticationScheme ) ]
[ Route ( " api/[controller] " ) ]
public class HomeController : Controller
{
// ...
} HmacAuthenticaion também fornece um DelegatingHandler para adicionar um cabeçalho de autorização HMAC a solicitações HTTP.
Instancie sua instância HttpClient com ApiKeyDelegatingHandler . Certifique-se de não criar novas instâncias HttpClient para cada solicitação (consulte também esta postagem do blog para obter detalhes):
new HttpClient ( new ApiKeyDelegatingHandler ( appId , apiKey ) ) ; Ou caso seu cliente WebAPI seja outro ASP.NET WebAPI (>= ASP.NET Core 2.1), registre seu HttpClient no Startup.cs , por exemplo, da seguinte forma:
services . AddTransient ( sp => new ApiKeyDelegatingHandler ( appId , apiKey ) ) ;
services
. AddHttpClient ( " HmacHttpClient " )
. AddHttpMessageHandler < ApiKeyDelegatingHandler > ( ) ;Para gerar uma chave de API, o seguinte aplicativo de console simples pode ser usado. Esta implementação também é fornecida no .NET Fiddle.
using System . Security . Cryptography ;
public class Program
{
public static void Main ( )
{
Console . WriteLine ( $" AppID: { Guid . NewGuid ( ) } or <some-speaking-name> " ) ;
Console . WriteLine ( $" ApiKey: { GenerateApiKey ( ) } " ) ;
}
private static string GenerateApiKey ( )
{
using ( var cryptoProvider = new RNGCryptoServiceProvider ( ) )
{
byte [ ] secretKeyByteArray = new byte [ 32 ] ; //256 bit
cryptoProvider . GetBytes ( secretKeyByteArray ) ;
return Convert . ToBase64String ( secretKeyByteArray ) ;
}
}
} As maiores fontes de riscos de segurança geralmente não são encontradas no Protocolo de Autenticação, mas nas políticas e procedimentos que envolvem seu uso. Os implementadores são fortemente encorajados a avaliar como este módulo aborda os seus requisitos de segurança. Esta seção inclui uma lista incompleta de considerações de segurança que devem ser revisadas e compreendidas antes de implantar este protocolo Auth no servidor. Muitas das proteções fornecidas nas especificações dependem de se e como são usadas.
HmacAuthentication não fornece nenhum mecanismo para obter ou transmitir o conjunto de credenciais compartilhadas necessárias. Qualquer mecanismo usado para obter credenciais HmacAuthentication deve garantir que essas transmissões sejam protegidas por meio de mecanismos da camada de transporte, como TLS.
Embora o HmacAuthentication forneça um mecanismo para verificar a integridade das solicitações HTTP, ele não oferece garantia de confidencialidade da solicitação. A menos que outras precauções sejam tomadas, os bisbilhoteiros terão acesso total ao conteúdo da solicitação. Os servidores devem considerar cuidadosamente os tipos de dados que provavelmente serão enviados como parte de tais solicitações e empregar mecanismos de segurança da camada de transporte para proteger recursos confidenciais.
HmacAuthentication fornece verificação limitada da autenticidade do servidor. Ao receber uma resposta do servidor.
Uma parte hostil poderia tirar vantagem disso interceptando as solicitações do cliente e retornando respostas enganosas ou incorretas. Os provedores de serviços devem considerar tais ataques ao desenvolver serviços usando este protocolo e devem exigir segurança da camada de transporte para quaisquer solicitações em que a autenticidade do servidor de recursos ou das respostas do servidor seja um problema.
A chave HmacAuthentication funciona da mesma forma que as senhas em sistemas de autenticação tradicionais. Para calcular o MAC da solicitação, o servidor deve ter acesso à chave em formato de texto simples. Isto contrasta, por exemplo, com os sistemas operacionais modernos, que armazenam apenas um hash unidirecional de credenciais de usuário.
Se um invasor obtivesse acesso a essas chaves - ou pior, ao banco de dados do servidor com todas essas chaves - ele seria capaz de executar qualquer ação em nome de qualquer proprietário de recurso. Conseqüentemente, é fundamental que os servidores protejam essas chaves contra acesso não autorizado.
A menos que um protocolo de segurança da camada de transporte seja usado, os bisbilhoteiros terão acesso total às solicitações autenticadas e solicitarão valores MAC e, portanto, serão capazes de montar ataques de força bruta off-line para recuperar a chave usada. Os servidores devem ter o cuidado de atribuir chaves que sejam longas e aleatórias o suficiente para resistir a tais ataques pelo menos durante o período em que as credenciais do HmacAuthentication são válidas.
Por exemplo, se as credenciais forem válidas por duas semanas, os servidores devem garantir que não seja possível montar um ataque de força bruta que recupere a chave em menos de duas semanas. É claro que os servidores são incentivados a agir com cautela e usar a chave mais longa e razoável.
É igualmente importante que o gerador de números pseudo-aleatórios (PRNG) utilizado para gerar estas chaves seja de qualidade suficientemente elevada. Muitas implementações PRNG geram sequências numéricas que podem parecer aleatórias, mas que, no entanto, exibem padrões ou outras fraquezas que facilitam a criptoanálise ou ataques de força bruta. Os implementadores devem ter cuidado ao usar PRNGs criptograficamente seguros para evitar esses problemas.
A solicitação MAC cobre apenas o cabeçalho HTTP Host , o cabeçalho Content-Type e, opcionalmente, um determinado conjunto de cabeçalhos. Ele não cobre nenhum outro cabeçalho que ele não conheça e que muitas vezes pode afetar a forma como o corpo da solicitação é interpretado pelo servidor. Se o comportamento do servidor for influenciado pela presença ou valor de tais cabeçalhos, um invasor poderá manipular os cabeçalhos da solicitação sem ser detectado. Os implementadores devem usar o recurso headers para passar cabeçalhos a serem adicionados à assinatura por meio do cabeçalho Authorization , que é protegido pelo MAC de solicitação. A String Base de Assinatura será então responsável por adicionar esses cabeçalhos fornecidos à Assinatura para que se tornem parte do MAC.
A autenticação da resposta, quando realizada, cobre apenas o corpo da resposta (payload) e algumas das informações da solicitação fornecidas pelo cliente em sua solicitação, como timestamp e nonce. Não cobre o código de status HTTP ou qualquer outro campo de cabeçalho de resposta (por exemplo, Localização) que possa afetar o comportamento do cliente.
Se um invasor conseguir manipular essas informações e fazer com que o cliente use um horário incorreto, poderá fazer com que o cliente gere solicitações autenticadas usando o horário no futuro. Essas solicitações falharão quando enviadas pelo cliente e provavelmente não deixarão rastros no servidor (dada a implementação comum do nonce, se for aplicada). O invasor poderá então reproduzir a solicitação no momento correto, sem detecção.
Uma solução para este problema seria uma sincronização de relógio entre o cliente e o servidor. Para fazer isso, o servidor informa ao cliente seu horário atual quando um carimbo de data/hora inválido é recebido. Isso acontece na forma de um cabeçalho Date na resposta. Veja RFC2616 como motivação para isso.
O cliente só deve utilizar as informações de horário fornecidas pelo servidor se:
Ao receber uma solicitação com carimbo de data/hora incorreto, o servidor fornece ao cliente a hora atual. O cliente nunca deve usar a hora recebida do servidor para ajustar seu próprio relógio, devendo apenas usá-la para calcular um deslocamento para comunicação com aquele servidor específico.
HmacAuthentication valida o MAC da solicitação de entrada em relação ao cabeçalho do Host HTTP de entrada. Um cliente malicioso pode criar novos nomes de host apontando para o endereço IP do servidor e usá-los para criar um ataque, enviando uma solicitação válida destinada a outro nome de host diferente daquele usado pelo servidor. Os implementadores de servidor devem verificar manualmente se o cabeçalho do host recebido corresponde às suas expectativas. Por exemplo, se você espera chamadas de API em test.myapi.com, verifique se esse é o domínio para o qual a solicitação foi enviada na implementação do servidor.
