Что такое аутентификация HMAC и почему она полезна?

В последнее время я довольно много исследовал и изучал серверные API-интерфейсы. Аутентификация для API этих типов действительно зависит от типа сервиса и подразделяется на несколько общих категорий:

• Потребительские или личные приложения, они обычно используют простое имя пользователя и пароль, в некоторых случаях используется OAuth, однако это больше для идентификации сеанса авторизации отдельных лиц в доверенной третьей стороне.
• Инфраструктурные приложения, как правило, используют набор учетных данных, которые отличаются от учетных данных владельцев / администраторов, и предоставляют своего рода API автоматизации для бизнеса или устройств для улучшения функции или управления чем-либо.

Для инфраструктурных API я рассмотрел несколько вариантов, они объяснены более подробно ниже.

Базовая аутентификация

Это простейшая реализация, и для некоторых реализаций она может работать хорошо, однако для этого требуется шифрование на транспортном уровне, поскольку имя пользователя и пароль предоставляются при каждом запросе. Для получения дополнительной информации об этом см. Статью Wikipedia .

Дайджест-аутентификация

На самом деле это немного ближе к HMAC, чем к базовому: он использует md5 для хэширования атрибутов аутентификации таким образом, что значительно затрудняет перехват и компрометацию атрибутов имени пользователя и пароля. Примечание. Я рекомендую прочитать на странице Википедии тему, короче говоря, она более чем безопасна, чем базовая аутентификация, однако она полностью зависит от того, сколько защитных мер реализовано в клиентском программном обеспечении, и сложность пароля является фактором.

Обратите внимание, что в отличие от обычной аутентификации, для этого не требуется SSL-соединение, поэтому обязательно прочитайте статью в Википедии, так как есть некоторые проблемы с атаками типа «человек в середине».

Аутентификация HMAC

В отличие от предыдущих методов аутентификации, насколько я могу сказать, стандартный способ сделать это отсутствует, в котором говорится, что это основной метод аутентификации, используемый Amazon Web Services, он очень хорошо понятен, и существует ряд библиотек. которые реализуют это. Чтобы использовать эту форму аутентификации, вы используете идентификатор ключа и секретный ключ, причем оба они обычно генерируются в интерфейсе администратора (более подробно ниже).

Очень важно отметить, что одно из БОЛЬШИХ различий с этим типом аутентификации заключается в том, что он подписывает весь запрос, если включен контент-md5, это в основном гарантирует подлинность действия. Если кто-то посередине возится с вызовом API по злонамеренным причинам или из-за ошибки в промежуточном прокси-сервере, которая отбрасывает некоторые важные заголовки, подпись не будет совпадать.

При использовании аутентификации HMAC дайджест вычисляется с использованием составного URI, метки времени запроса и некоторых других заголовков (в зависимости от реализации) с использованием предоставленного секретного ключа. Идентификатор ключа вместе с дайджестом, который кодируется с использованием Base64 , объединяются и добавляются в заголовок авторизации.

Следующий пример взят из документации Amazon S3 .

В результате получается HTTP-запрос с заголовками, которые выглядят следующим образом.

Обратите внимание, что AWS после двоеточия иногда называют меткой сервиса, большинство сервисов, которые я видел, следуют соглашению, меняя его на сокращение своего имени или просто HMAC.

Если мы внимательно изучим реализацию Amazon, то станут очевидными некоторые преимущества по сравнению с обычными именами пользователей и паролями:

1. Как уже упоминалось, аутентификация HMAC гарантирует подлинность запроса, подписывая заголовки, это особенно верно, если content-md5 подписан и проверен сервером И клиентом.
2. Администратор может генерировать любое количество пар ключей и использовать их независимо от своих учетных данных Amazon.
3. Как отмечалось ранее, это вычисленные значения, которые можно оптимизировать до необходимого размера, Amazon использует 40 секретов символов для SHA-1 , в зависимости от используемого алгоритма хеширования.
4. Эту форму аутентификации можно использовать без необходимости использования SSL, поскольку секрет никогда не передается, а только MAC.
5. Поскольку пары ключей не зависят от учетных данных администратора, они могут быть удалены или отключены, если системы скомпрометированы для того, чтобы отключить их использование.

Что касается недостатков, то они действительно есть:

1. Не много согласованности в реализациях, кроме тех, которые взаимодействуют с Amazon.
2. Реализации на стороне сервера немногочисленны, а также очень противоречивы.
3. Если вы решите создать свой собственный, имейте в виду, что криптографические API, такие как OpenSSL, могут быть трудны для тех, кто не использовал их раньше, разница в один символ приведет к совершенно другому значению.
4. В тех случаях, когда все заголовки в запросе подписаны, вы должны быть ОЧЕНЬ осторожны на стороне сервера или клиента, чтобы избежать введения или изменения заголовков вашими библиотеками (более подробно ниже).

Поскольку я сейчас занимаюсь разработкой и действительно переписываю некоторые из моих существующих реализаций, я подумал, что соберу список советов для авторов библиотек.

1. При написании API убедитесь, что вы проверяете свой запрос на проводе, чтобы убедиться, что ничего не было изменено или «подправлено» используемой вами HTTP-библиотекой, и я добавил атрибут кодировки символов в Content-Type.
2. Проверьте правильность порядка ваших заголовков при отправке запроса, библиотеки могут использовать хэш-карту (упорядоченную естественным образом), это может нарушить вашу подпись в зависимости от реализации. В случае Amazon они требуют, чтобы вы отсортировали свои «дополнительные» заголовки по алфавиту и строчные имена заголовков перед вычислением подписи.
3. Будьте осторожны с сумасшедшими библиотеками Ruby, которые видят имена ваших заголовков (да, это плохая форма), прежде чем представлять их вашему коду в виде списка имен заголовков.
4. При отладке выведите каноническую строку, используемую для генерации подписи, предпочтительно с использованием чего-то вроде ruby ​​inspect, которая показывает ВСЕ символы. Это поможет как отладке при разработке, так и сравнить с тем, что на самом деле облегчает серверная часть.
5. Посмотрите, как различные клиентские или серверные API вводят или действительно удаляют заголовки.

С точки зрения безопасности пара основных рекомендаций.

1. Используйте контент MD5 на обоих концах разговора.
2. Подписать все заголовки, которые могут повлиять на результат операции как минимум.
3. Запишите заголовки каждого вызова API, который может иметь побочные эффекты, на большинстве веб-серверов это можно включить и добавить в веб-журналы (опять же, в идеале это должно быть закодировано, как это делает ruby ​​Inspect).

Итак, в заключение я, безусловно, рекомендую использовать аутентификацию HMAC, но будьте готовы многое узнать о том, как работает HTTP, и немного о криптографии, на мой взгляд, это не повредит в любом случае, если вы строите API на стороне сервера.

Ссылка: Что такое аутентификация HMAC и почему она полезна? от нашего партнера JCG Марка Вулфа в блоге Марка Вулфа .