HmacAuthentication
1.0.0
Код аутентификации сообщения на основе хэша (HMAC) — это механизм расчета кода аутентификации сообщения, включающий хэш-функцию в сочетании с секретным ключом. Это можно использовать для проверки целостности и подлинности сообщения.
Эта реализация во многом основана на основном методе аутентификации, используемом Amazon Web Services (AWS Signature V4), поскольку он очень хорошо понятен и существует ряд библиотек, которые его реализуют. Чтобы использовать эту форму аутентификации, вы используете идентификатор ключа и секретный ключ, оба из которых обычно генерируются в интерфейсе администратора.
HmacAuthentication предоставляет AuthenticationHandler , который поддерживает аутентификацию HMAC в проекте ASP.NET Core.
Использование:
appsettings.json . Для аутентификации HMAC требуются AppId и ApiKey для каждого клиента, который должен получить доступ. 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 в методе ConfigureServices : services
. AddAuthentication ( o =>
{
o . DefaultScheme = HmacAuthenticationDefaults . AuthenticationScheme ;
} )
. AddHmacAuthentication ( HmacAuthenticationDefaults . AuthenticationScheme , " HMAC Authentication " , o =>
{
o . MaxRequestAgeInSeconds = HmacAuthenticationDefaults . MaxRequestAgeInSeconds ;
o . HmacAuthenticatedApps = hmacAuthenticatedApps ;
} ) ;MemoryCache (из Microsoft.Extensions.Caching.Memory) в Startup.cs в методе ConfigureServices . MemoryCache используется HMAC AuthenticationHandler для определения атак воспроизведения. services . AddMemoryCache ( ) ;Startup.cs в методе Configure : app . UseAuthentication ( ) ; [ Authorize ( AuthenticationSchemes = HmacAuthenticationDefaults . AuthenticationScheme ) ]
[ Route ( " api/[controller] " ) ]
public class HomeController : Controller
{
// ...
} HmacAuthenticaion также предоставляет DelegatingHandler для добавления заголовка авторизации HMAC к HTTP-запросам.
Создайте экземпляр HttpClient с помощью ApiKeyDelegatingHandler . Убедитесь, что вы не создаете новые экземпляры HttpClient для каждого запроса (подробности см. Также в этом сообщении блога):
new HttpClient ( new ApiKeyDelegatingHandler ( appId , apiKey ) ) ; Или, если ваш клиент WebAPI является другим веб-API ASP.NET (>= ASP.NET Core 2.1), зарегистрируйте свой HttpClient в Startup.cs , например, следующим образом:
services . AddTransient ( sp => new ApiKeyDelegatingHandler ( appId , apiKey ) ) ;
services
. AddHttpClient ( " HmacHttpClient " )
. AddHttpMessageHandler < ApiKeyDelegatingHandler > ( ) ;Для создания ключа API можно использовать следующее простое консольное приложение. Эта реализация также предоставляется в .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 ) ;
}
}
} Наибольшие источники угроз безопасности обычно обнаруживаются не в протоколе аутентификации, а в политиках и процедурах, связанных с его использованием. Разработчикам настоятельно рекомендуется оценить, насколько этот модуль соответствует их требованиям безопасности. В этом разделе приведен неполный список вопросов безопасности, которые необходимо просмотреть и понять перед развертыванием этого протокола аутентификации на сервере. Многие средства защиты, предусмотренные в спецификациях, зависят от того, используются ли они и как.
HmacAuthentication не предоставляет никакого механизма для получения или передачи требуемого набора общих учетных данных. Любой механизм, используемый для получения учетных данных HmacAuthentication, должен гарантировать, что эти передачи защищены с использованием механизмов транспортного уровня, таких как TLS.
Хотя HmacAuthentication предоставляет механизм проверки целостности HTTP-запросов, он не дает никаких гарантий конфиденциальности запросов. Если не будут приняты другие меры предосторожности, перехватчики будут иметь полный доступ к содержимому запроса. Серверам следует тщательно учитывать типы данных, которые могут быть отправлены в рамках таких запросов, и использовать механизмы безопасности транспортного уровня для защиты конфиденциальных ресурсов.
HmacAuthentication обеспечивает ограниченную проверку подлинности сервера. При получении ответа от сервера.
Враждебная сторона может воспользоваться этим, перехватывая запросы клиента и возвращая вводящие в заблуждение или иным образом неправильные ответы. Поставщики услуг должны учитывать такие атаки при разработке услуг с использованием этого протокола и должны требовать безопасности транспортного уровня для любых запросов, в которых подлинность сервера ресурсов или ответов сервера является проблемой.
Ключ HmacAuthentication действует так же, как пароли в традиционных системах аутентификации. Чтобы вычислить MAC-адрес запроса, сервер должен иметь доступ к ключу в текстовой форме. В этом отличие, например, от современных операционных систем, которые хранят только односторонний хеш учетных данных пользователя.
Если злоумышленник получит доступ к этим ключам (или, что еще хуже, к базе данных всех таких ключей на сервере), он или она сможет выполнить любое действие от имени любого владельца ресурса. Соответственно, крайне важно, чтобы серверы защищали эти ключи от несанкционированного доступа.
Если не используется протокол безопасности транспортного уровня, перехватчики будут иметь полный доступ к аутентифицированным запросам и запрашивать значения MAC и, таким образом, смогут проводить автономные атаки методом перебора для восстановления используемого ключа. Серверам следует осторожно назначать ключи, которые являются достаточно длинными и достаточно случайными, чтобы противостоять таким атакам, по крайней мере, в течение того периода времени, в течение которого учетные данные HmacAuthentication действительны.
Например, если учетные данные действительны в течение двух недель, серверы должны гарантировать невозможность проведения атаки методом перебора, позволяющей восстановить ключ менее чем за две недели. Конечно, серверам рекомендуется проявлять осторожность и использовать максимально длинный ключ.
Не менее важно, чтобы генератор псевдослучайных чисел (ГПСЧ), используемый для генерации этих ключей, был достаточно высокого качества. Многие реализации PRNG генерируют числовые последовательности, которые могут показаться случайными, но которые, тем не менее, демонстрируют закономерности или другие недостатки, которые упрощают криптоанализ или атаки методом перебора. Разработчикам следует быть осторожными и использовать криптографически безопасные PRNG, чтобы избежать этих проблем.
MAC-адрес запроса охватывает только заголовок HTTP Host , заголовок Content-Type и, возможно, заданный набор заголовков. Он не охватывает другие заголовки, о которых он не знает, которые часто могут влиять на то, как тело запроса интерпретируется сервером. Если на поведение сервера влияет наличие или значение таких заголовков, злоумышленник может манипулировать заголовками запросов, не будучи обнаруженным. Разработчикам следует использовать функцию headers для передачи заголовков, добавляемых в подпись, через заголовок Authorization , который защищен запросом MAC. Базовая строка подписи затем будет отвечать за добавление этих заголовков в подпись, чтобы они стали частью MAC.
Аутентификация ответа, если она выполняется, охватывает только тело ответа (полезную нагрузку) и некоторую информацию запроса, предоставленную клиентом в его запросе, например метку времени и одноразовый номер. Он не охватывает код состояния HTTP или любое другое поле заголовка ответа (например, местоположение), которое может повлиять на поведение клиента.
Если злоумышленник сможет манипулировать этой информацией и заставить клиента использовать неправильное время, он сможет заставить клиента генерировать аутентифицированные запросы с использованием времени в будущем. Такие запросы завершатся неудачей при отправке клиентом и вряд ли оставят след на сервере (учитывая общую реализацию nonce, если она вообще применяется). Тогда злоумышленник сможет воспроизвести запрос в нужное время без обнаружения.
Решением этой проблемы могла бы стать синхронизация часов между клиентом и сервером. Для этого сервер сообщает клиенту свое текущее время при получении недопустимой метки времени. Это происходит в виде заголовка даты в ответе. См. RFC2616 как мотивацию для этого.
Клиенту следует использовать информацию о времени, предоставленную сервером, только если:
При получении запроса с неверной меткой времени сервер предоставляет клиенту свое текущее время. Клиент никогда не должен использовать время, полученное от сервера, для корректировки своих собственных часов, а должен использовать его только для расчета смещения для связи с этим конкретным сервером.
HmacAuthentication проверяет MAC входящего запроса на соответствие входящему заголовку HTTP-хоста. Вредоносный клиент может создать новые имена хостов, указывающие на IP-адрес сервера, и использовать их для организации атаки, отправив действительный запрос, предназначенный для другого имени хоста, отличного от того, которое используется сервером. Разработчики серверов должны вручную убедиться, что полученный заголовок хоста соответствует их ожиданиям. Например, если вы ожидаете вызовы API на test.myapi.com, убедитесь, что это тот домен, на который был отправлен запрос в реализации сервера.
