Генератор HMAC

Что это за инструмент?

HMAC расшифровывается как Hash-based Message Authentication Code — код аутентификации сообщений на основе хеша. Он объединяет секретный ключ с сообщением и стандартной хеш-функцией (например, SHA-256), чтобы получить дайджест фиксированной длины. Любой, у кого есть тот же ключ и сообщение, вычислит точно такой же HMAC — но без ключа получить корректный HMAC для сообщения вычислительно неосуществимо, даже если известен используемый алгоритм хеширования.

В этом ключевое отличие от обычного хеша: обычный хеш (MD5, SHA-256 и т. д.) принимает на вход только сообщение, поэтому вычислить его может кто угодно, и он ничего не доказывает о том, кто его создал. HMAC принимает сообщение *и* секретный ключ, поэтому корректный HMAC доказывает, что отправитель владел секретом — это механизм аутентификации, а не просто проверка целостности.

HMAC формально стандартизирован NIST в документе FIPS 198-1 и определён для интернет-протоколов в IETF RFC 2104. Этот инструмент вычисляет HMAC с помощью нативного Web Crypto API вашего браузера (`crypto.subtle.sign` с алгоритмом HMAC), который корректно реализует RFC 2104, а не самописную версию на JavaScript.

Зачем его использовать?

• Пришёл вебхук от Stripe с заголовком X-Stripe-Signature, и прежде чем подозревать серверные логи, хочется вручную воспроизвести вычисление — вводите секретный ключ и payload сюда и сверяете, совпадает ли полученный HMAC-SHA256 со значением заголовка.
• Пишете локально проверку вебхуков для GitHub Apps и не уверены, правильно ли работает логика X-Hub-Signature-256 — заранее считаете ожидаемое значение по известным ключу и payload и сверяете с выводом своего кода при отладке.
• Нужно убедиться, что другая команда правильно реализовала подпись запросов к вашему внутреннему API — передаёте им тот же секретный ключ и сообщение и сразу проверяете, получается ли у обеих сторон одинаковый HMAC.
• Хотите проверить часть подписи HS256 в JWT, не полагаясь вслепую на библиотеку — вставляете в поле сообщения строку из склеенных header и payload и вычисляете HMAC-SHA256 с ключом подписи для сравнения.
• Нужно протестировать с реальным production-ключом, не отправляя ничего сторонним сервисам — все вычисления происходят в браузере, поэтому можно безопасно использовать настоящие секреты.
• Хочется на практике, а не только по документации, увидеть разницу в длине вывода между SHA-1 и SHA-256 — инструмент показывает все четыре алгоритма рядом для одних и тех же ключа и сообщения.

Как использовать

1. Введите секретный ключ в поле «Secret Key».
2. Введите сообщение, которое нужно аутентифицировать, в поле «Message».
3. Результаты HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 и HMAC-SHA512 генерируются мгновенно (отметьте «Uppercase output», если целевая система ожидает заглавные буквы).
4. Нажмите «Copy» рядом с нужным значением HMAC.

Пример

Ввод

Secret Key: key
Message: The quick brown fox jumps over the lazy dog

Результат

HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

Это стандартный опубликованный тестовый вектор: с ключом «key» и этим сообщением HMAC-SHA256 и HMAC-SHA1 всегда дают именно такие значения в любой корректной реализации, так что вы можете независимо проверить вывод этого инструмента.

HMAC против обычного хеша: когда нужен ключ

Решающий вопрос: нужно ли доказать, кто создал этот дайджест, или достаточно убедиться, что содержимое не изменилось? Если хватает публичной контрольной суммы — проверка, что скачанный файл совпадает с тем, что указал издатель, дедупликация записей, — подойдёт обычный хеш, и проверить его сможет кто угодно без ключа. Если же нужно доказать, что дайджест мог создать только владелец конкретного секрета — аутентификация вызывающей стороны API, доверие отправителю вебхука, — нужен HMAC, потому что обычный хеш даёт злоумышленнику без секрета ту же возможность подделать корректный дайджест, что и настоящему отправителю.

→ Генератор хеша для нескольких алгоритмов · Декодер JWT · Генератор MD5

Сравнение четырёх алгоритмов HMAC

Все четыре используют одну и ту же конструкцию HMAC из RFC 2104, отличаясь только базовой хеш-функцией и, соответственно, длиной вывода.

Типичные сценарии использования

• Подпись исходящих API-запросов общим секретом, чтобы сервер мог подтвердить личность вызывающей стороны.
• Проверка входящей полезной нагрузки вебхуков (заголовки Stripe-Signature, GitHub X-Hub-Signature-256 и похожие используют HMAC-SHA256).
• Генерация и проверка сигнатурной части JWT, подписанного HS256/HS384/HS512.
• Проверка того, что серверная или клиентская реализация HMAC даёт ожидаемый результат, перед развёртыванием.

На что обратить внимание при проверке подписи вебхука

Многие сервисы подписывают не просто тело запроса как есть, а строку, полученную объединением тела с другими элементами, например с меткой времени. Stripe, например, соединяет метку времени и payload в определённом формате перед подписью, поэтому при воспроизведении проверки в этом инструменте важно свериться с документацией сервиса, чтобы понять, какая именно строка подписывается на самом деле.

Кроме того, если тело запроса — это JSON, разбор и повторная сериализация часто меняют переносы строк и порядок ключей, из-за чего результат перестаёт совпадать с исходной последовательностью байт. При проверке всегда вставляйте в поле сообщения именно «сырое» тело запроса в том виде, в каком оно было получено, — использование уже отформатированной строки даст несовпадение даже при правильной реализации.

Часто задаваемые вопросы