Генератор HMAC

Вычислите HMAC-SHA-256, HMAC-SHA-1 или HMAC-SHA-512 с вашим ключом прямо в браузере. Вывод в HEX и Base64, сверка с эталоном и проверочные векторы.

Всё работает в вашем браузере — данные не отправляются на сервер.

Зачем считать HMAC

HMAC — это подпись сообщения секретным ключом, и вычислять её приходится каждый раз, когда сервисы обмениваются запросами и нужно доказать, что данные не подменили по пути. Подпись API-запросов, проверка вебхуков от платёжных систем, токены JWT с алгоритмом HS256 — везде внутри стоит именно HMAC, чаще всего с SHA-256. Генератор принимает сообщение и ключ, выбирает хеш-функцию и выдаёт готовую подпись в HEX и Base64, плюс позволяет сверить результат с эталонным значением. Всё считается через Web Crypto прямо в браузере, ключ не покидает вашу машину.

Что умеет генератор

Считает HMAC-SHA-1, HMAC-SHA-256 и HMAC-SHA-512 через crypto.subtle.sign
Принимает любое сообщение и ключ любой длины, включая пустой текст
Показывает подпись сразу в двух форматах: HEX и Base64
Сверяет результат с эталонной подписью и показывает, совпала она или нет
Подставляет известный пример с классической фразой про лису — ответ легко проверить

Как вычислить подпись

Вставьте сообщение: тело запроса, строку вебхука или любой текст
Введите секретный ключ — тот же, что использует вторая сторона
Выберите хеш-функцию: SHA-256 остаётся самым частым выбором
Нажмите кнопку и скопируйте HEX или Base64, при необходимости сверьте с эталоном

Как устроен HMAC

Простое приклеивание ключа к сообщению перед хешированием небезопасно, поэтому HMAC построен на двух проходах. Ключ сначала доводится до размера блока хеш-функции: для SHA-256 это 64 байта, для SHA-512 — 128; слишком длинный ключ сначала хешируют. Затем готовятся две производные последовательности: внутренняя — ключ, наложенный на константу ipad со значением 0x36, и внешняя — ключ с константой opad 0x5C. Подпись считается как внешний хеш от внутренней хеш-суммы сообщения: H(opad-ключ || H(ipad-ключ || сообщение)). Схема придумана в 1996 году Белларе, Канетти и Кравчик, описана в RFC 2104 и стандартизована в FIPS 198-1, и за десятилетия в ней не нашли практической атаки.

Проверочные векторы: подписи для классического примера

Алгоритм	Подпись в HEX	Длина
HMAC-SHA-1	de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9	40 hex-символов, 160 бит
HMAC-SHA-256	f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8	64 hex-символа, 256 бит
HMAC-SHA-512	b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a	128 hex-символов, 512 бит
HMAC-SHA-256 в Base64	97yD9DBThCSxMpjmqm+xQ+9NWaFJRhdZl0edvC0aPNg=	та же подпись в другом формате
RFC 4231, тест 2	5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843	ключ Jefe, сообщение what do ya want for nothing?
Другой ключ	e21d6984a9ea09770d8df6eee046f3c2f85463f4daad128d4409a39fce912ee0	то же сообщение, ключ another — подпись другая целиком
Другой текст	e98139c39d76eb80d8db982552b44b251b94f312987f91ee72d12ef673caa813	добавлена одна точка в конце, подпись изменилась полностью
Пустое сообщение	подпись считается и от пустой строки	сообщение может быть нулевой длины

Для строк 1–4 сообщение — «The quick brown fox jumps over the lazy dog», ключ — «key». Значения легко проверить в любом языке одной строкой.

Где HMAC встречается каждый день

Вебхуки — самый близкий к разработчику пример. Платёжная система отправляет на ваш адрес событие и прикладывает подпись от тела запроса; приёмник на сервере пересчитывает HMAC тем же секретом и сравнивает. Подпись сошлась — событие пришло действительно от платёжной системы и не было изменено по дороге. Не сошлась — запрос выбрасывается, потому что либо это подделка, либо секрет на вашей стороне разъехался с тем, что на стороне отправителя. Без этой проверки любой, кто узнал адрес вебхука, мог бы слать вам фиктивные оплаты.

Вторая крупная зона — подпись API-запросов. Клиент собирает строку из метода, пути, заголовков и времени запроса, подписывает её общим секретом и отправляет вместе с подписью; сервер повторяет то же самое и сравнивает. Время в строке защищает от повторной отправки старого запроса через часы. Токены JWT с HS256 и одноразовые коды двухфакторной аутентификации — те же HMAC, завёрнутые в другой формат. Устройство обычных хешей без ключа, с которыми HMAC удобно сравнивать, разобрано в мультихеш-генераторе.

Проверка вебхуков платёжных систем и сервисов уведомлений
Подпись API-запросов: метод, путь, заголовки и время в одной строке
Токены JWT с алгоритмом HS256
Одноразовые коды двухфакторной аутентификации
Обмен между своими сервисами, где открытые ключи избыточны

Типичные ошибки при работе с HMAC

Первая ошибка — разъехавшийся формат у двух сторон. Отправитель считает подпись от сырого тела запроса, приёмник успел переформатировать JSON и считает от красивой строки с пробелами — подписи не совпадут, хотя содержимое одинаково. Туда же относятся несовпадающие кодировки: кириллица в UTF-8 даёт другие байты, чем в Windows-1251. Правило одно: подписывается ровно та последовательность байтов, которая уходит по сети, и обе стороны договариваются об этом заранее.

Вторая ошибка — ключ в логах. Чтобы разобрать, почему подпись не сходится, разработчик печатает в лог ключ и сообщение, а логи потом утекают вместе с бэкапами и доступами подрядчиков. Подпись без секрета бесполезна, поэтому в лог попадает сообщение и подпись, но не ключ. Третья ошибка — хранить один ключ вечно: ключ меняют при ротации, а при компрометации сразу, потому что старые подписи перестают быть доказательством.

Подпись считается от точных байтов сообщения, без переформатирования
Разные кодировки кириллицы дают разные подписи
Ключ не логируется и не отправляется в тикеты
Алгоритм у отправителя и получателя должен совпадать
Сравнение подписей на сервере — с постоянным временем
Ключи ротируют, а не используют десятилетиями

Разбор примера: шаги вычисления по схеме

Возьмём классическую пару: сообщение про лису и ключ «key». Первый шаг — привести ключ к размеру блока: строка из трёх байтов дополняется нулями до 64 байтов для SHA-256. Второй шаг — получить внутренний и внешний варианты ключа: одна копия накладывается на константу 0x36, другая на 0x5C. Третий шаг — внутренний хеш: SHA-256 от склейки ipad-ключа и сообщения, получается 32 байта. Четвёртый — внешний: SHA-256 от склейки opad-ключа и тех 32 байтов. Итог — f7bc83f4..., и это ровно то, что показывает генератор.

Проверить результат можно тремя способами: кнопкой примера в самом генераторе, одной строкой в любом языке программирования или сравнением с векторами из стандарта RFC 4231. Если подпись не совпала, сначала проверьте алгоритм, затем точный текст сообщения — лишний пробел или перенос строки в конце меняют все 64 hex-символа. Сводка векторов ниже.

Что происходит на каждом шаге

Шаг	Действие	Результат
1	Ключ доводится до блока	для SHA-256 блок 64 байта, недостающее дополняется нулями
2	Два варианта ключа	наложение на ipad 0x36 и opad 0x5C
3	Внутренний хеш	SHA-256 от ipad-ключа плюс сообщение, 32 байта
4	Внешний хеш	SHA-256 от opad-ключа плюс внутренний хеш
5	Готовая подпись	32 байта или 64 hex-символа для SHA-256
6	Передача	подпись уходит рядом с сообщением в заголовке или теле
7	Проверка	получатель повторяет шаги 1–4 и сравнивает
8	Расхождение	хоть один байт отличается — подпись другая целиком

Хеш-функция определяет размер блока и подписи: SHA-1 даёт 20 байтов, SHA-256 — 32, SHA-512 — 64, а сам механизм при этом один и тот же.

Чем дополнить работу с HMAC

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

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

Хеши без ключа — для целостности, HMAC — для подлинности
RFC 2104 описывает схему, RFC 4231 даёт тестовые векторы
Ключ хранится в менеджере секретов, а не в коде
JWT HS256 и TOTP-коды — HMAC в другой упаковке
Для проверки без общего секрета нужны асимметричные подписи

Частые вопросы

Чем HMAC отличается от обычного хеша

Ключом. Обычный SHA-256 от текста может посчитать любой желающий, поэтому подменить сообщение вместе с хешем ничего не стоит: перечитал данные, посчитал заново, подставил. HMAC добавляет секрет, известный только отправителю и получателю, поэтому чужой подписью воспользоваться нельзя: не зная ключа, корректную подпись для нового сообщения не построить. По этой причине для проверки целостности скачиваемого файла хватает обычного хеша, а для проверки подлинности сообщения нужен именно HMAC.

Почему нельзя просто прибавить ключ к сообщению

Схема «хеш от ключа плюс сообщения» уязвима к атаке удлинения: получив подпись, злоумышленник может дописать данные в конец сообщения и досчитать корректную подпись, не зная ключа, потому что состояние внутреннего хеша продолжает старое вычисление. Есть и вариант «сообщение плюс ключ» со своими слабостями. HMAC решает проблему двумя вложенными хешами с разными константами: наружу торчит только внешний проход, до внутреннего состояния добраться не получится. Поэтому и существует отдельный стандарт, хотя на первый взгляд хеш с ключом можно было бы собрать самому.

Какой алгоритм выбрать: SHA-1, SHA-256 или SHA-512

SHA-256 — безопасный вариант по умолчанию: его требуют спецификации подписи запросов к крупным облачным API и большинство провайдеров вебхуков. SHA-1 для HMAC до сих пор не взломан в том смысле, как взломана сама SHA-1 для коллизий, но новые системы с ним не начинают: стандарт де-факто остался в старых интеграциях и в некоторых схемах двухфакторных кодов. SHA-512 даёт 512-битную подпись и быстрее на 64-битных процессорах, когда речь о больших объёмах. Ключевое: обе стороны обязаны использовать один и тот же алгоритм, иначе проверка всегда провалится.

Где HMAC используется на практике

Подпись API-запросов: крупные облачные провайдеры подписывают каждым запросом строку из метода, пути, параметров и времени. Вебхуки: платёжные системы и сервисы уведомлений присылают вместе с событием подпись от тела, и приёмник пересчитывает HMAC, прежде чем верить данным. Токены JWT с алгоритмом HS256 — это HMAC-SHA-256 над двумя частями токена, что видно в работе в генераторе JWT. Одноразовые коды двухфакторной аутентификации тоже строятся на HMAC. Общий список короче не становится: почти везде, где двум сторонам нужно доверять данным без открытого ключа.

Что за пример с лисой и можно ли ему доверять

Это классическая проверочная пара: сообщение «The quick brown fox jumps over the lazy dog» с ключом «key». HMAC-SHA-256 от неё даёт значение f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8, HMAC-SHA-1 — de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9, HMAC-SHA-512 — b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a. Тройку легко воспроизвести в любом языке одной строкой, поэтому она и стала стандартной проверкой: если ваш инструмент выдаёт эти значения, он считает HMAC правильно.

Какая длина ключа нужна

Короткий ключ сводит защиту на нет: перебор восьми символов занимает секунды, и тогда весь механизм подписи не нужен. Рабочая практика — случайная строка от 32 байтов, то есть около 256 бит энтропии; ключи длиннее блока хеш-функции стандарт тоже принимает, но сначала их хеширует. Важнее длины другое: ключ должен быть случайным и жить в секрете. Сгенерировать его можно генератором паролей, а требования к надёжной строке разобраны в статье о надёжном пароле.

Зачем сравнение с постоянным временем

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

Чем HMAC-SHA-256 отличается от других способов подписи

Симметричностью. В HMAC один общий секрет: подписать и проверить может тот, у кого есть ключ, поэтому схема подходит, когда обе стороны уже доверяют друг другу и нужен только канал без подмены. Асимметричные подписи вроде RSA и ECDSA используют пару ключей: приватным подписывают, публичным проверяют, и публичный можно показывать всему миру. Ориентир простой: подпись вебхуков и API-запросов между вашими сервисами — HMAC; документы и платежи, где подпись должна проверяться без секрета автора, — асимметричные схемы. Для хешей без ключа и их отличий есть разбор в статье про хеши MD5 и SHA-256.

Полезные статьи

HMAC-подпись API-запроса: зачем она и как её считать

Зачем подписывать API-запросы и вебхуки, как устроен HMAC простыми словами, почему подпись не шифрование, безопасное сравнение подписей, JWT HS256 и пошаговый расчёт HMAC-SHA-256 с проверенным примером.

HS256 и RS256: какую подпись JWT выбрать

Чем HS256 отличается от RS256, кому хватает одного секрета, когда нужна пара ключей RSA, размеры подписей и скорость, атака alg confusion и фиксация алгоритма, проверка токена обоими способами на реальном примере.