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 версия.

Защо да го използвате?

• Подписване на API заявки, за да може получаващият сървър да провери, че заявката идва от притежател на споделения секрет и не е била манипулирана.
• Проверка на webhook съдържание (Stripe, GitHub, Shopify и подобни услуги подписват телата на webhook-ите с HMAC-SHA256).
• Генериране на удостоверителни токени или еднократни кодове, зависещи от споделен секрет.
• Сравняване на изхода от собствена HMAC реализация с известна коректна референтна стойност.
• 100% локално: секретният ви ключ и съобщението никога не напускат браузъра, така че е безопасно да тествате реални секрети.

Как да го използвате

1. Въведете секретния си ключ в полето „Секретен ключ“.
2. Въведете съобщението, което искате да удостоверите, в полето „Съобщение“.
3. Резултатите за HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 и HMAC-SHA512 се генерират мигновено (отметнете „Изход с главни букви“, ако целевата система очаква главни букви).
4. Кликнете „Копирай“ до желания HMAC.

Пример

Вход

Секретен ключ: key
Съобщение: The quick brown fox jumps over the lazy dog

Резултат

HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

Това е стандартен публикуван тестов вектор: с ключ „key“ и точно това съобщение, HMAC-SHA256 и HMAC-SHA1 винаги произвеждат тези стойности при всяка коректна реализация, така че можете независимо да проверите изхода на този инструмент.

HMAC срещу обикновен хеш: кога ви трябва ключ

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

→

Сравнение на четирите HMAC алгоритъма

И четирите използват една и съща HMAC конструкция от RFC 2104, различавайки се само по основната хеш функция и следователно по дължината на изхода.

Често срещани случаи на употреба

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

Често задавани въпроси