CodeKitHubŠta je ovaj alat?
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 верзије.
Zašto ga koristiti?
- Потпишите API захтеве како би сервер прималац могао да верификује да захтев потиче од власника дељене тајне и да није измењен.
- Верификујте садржаје webhook-ова (Stripe, GitHub, Shopify и слични сервиси потписују своје webhook садржаје користећи HMAC-SHA256).
- Генеришите токене за аутентификацију или једнократне кодове који зависе од дељене тајне.
- Упоредите излаз сопствене HMAC имплементације са познатом исправном референтном вредношћу.
- 100% локално: ваш тајни кључ и порука никада не напуштају прегледач, тако да је безбедно тестирати праве тајне.
Kako se koristi
- Унесите свој тајни кључ у поље „Secret Key”.
- Унесите поруку коју желите да аутентификујете у поље „Message”.
- Резултати HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 и HMAC-SHA512 генеришу се тренутно (означите „Uppercase output” ако ваш циљни систем очекује велика слова).
- Кликните на „Copy” поред HMAC-а који вам је потребан.
Primer
Unos
Secret Key: key
Message: The quick brown fox jumps over the lazy dogRezultat
HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9Ово је стандардни објављени тест вектор: са кључем „key” и овом тачном поруком, HMAC-SHA256 и HMAC-SHA1 увек производе ове вредности у свакој исправној имплементацији, тако да можете независно верификовати излаз овог алата.
HMAC насупрот обичном хешу: када вам је потребан кључ
Пресудно питање је: да ли треба да докажете ко је створио овај сажетак, или само да садржај није измењен? Ако је јавна контролна сума довољна — верификовање да преузети фајл одговара ономе што је издавач навео, дедупликација записа — обичан хеш функционише и свако га може проверити, без кључа. Ако морате да докажете да је сажетак могао произвести само неко ко поседује одређену тајну — аутентификација API позиваоца, поверење пошиљаоцу webhook-а — потребан вам је HMAC, јер обичан хеш даје нападачу без тајне исту способност да фалсификује валидан сажетак као и прави пошиљалац.
→
Поређење четири HMAC алгоритма
Сва четири користе исту HMAC конструкцију из RFC 2104, разликујући се само по основној хеш функцији, а самим тим и по дужини излаза.
| Алгоритам | Величина излаза | Типична употреба |
|---|---|---|
| HMAC-SHA1 | 160-битно (40 хекс карактера) | Старији API-ји, старији OAuth 1.0a потписи |
| HMAC-SHA256 | 256-битно (64 хекс карактера) | Потписивање API захтева, JWT HS256, верификација webhook-а |
| HMAC-SHA384 | 384-битно (96 хекс карактера) | Потписи вишег нивоа поузданости где је потребан дужи излаз |
| HMAC-SHA512 | 512-битно (128 хекс карактера) | Сажеци максималне дужине за апликације високе безбедности |
Уобичајени случајеви употребе
- Потписивање одлазних API захтева дељеном тајном како би сервер могао да верификује идентитет позиваоца.
- Верификација долазних webhook садржаја (заглавља Stripe-Signature, GitHub X-Hub-Signature-256 и слична сва користе HMAC-SHA256).
- Генерисање и валидација дела потписа JWT-а потписаног са HS256/HS384/HS512.
- Тестирање да ли ваша серверска или клијентска HMAC имплементација одговара очекиваном излазу пре него што је поставите у продукцију.
Često postavljana pitanja
Шта је HMAC?
HMAC (Hash-based Message Authentication Code) комбинује тајни кључ са поруком користећи хеш функцију да би произвео сажетак који доказује и интегритет поруке и то да пошиљалац поседује кључ. Дефинисан је у NIST FIPS 198-1 и IETF RFC 2104.
Која је разлика између HMAC-а и обичног хеша?
Обичан хеш (SHA-256, MD5 итд.) прима само поруку као улаз — свако га може израчунати, тако да само доказује да порука није оштећена, а не ко ју је послао. HMAC прима поруку плус тајни кључ: ако морате да докажете да порука потиче од некога ко поседује одређену тајну (API потпис, пошиљалац webhook-а), потребан вам је HMAC. Ако само треба да проверите да се фајл или порука нису променили и није вам стало до доказивања ауторства, обичан хеш је довољан.
Да ли се мој тајни кључ шаље на сервер?
Не. Овај алат израчунава HMAC у потпуности у вашем прегледачу користећи Web Crypto API. Ваш кључ и порука никада се никуда не преносе — можете безбедно тестирати праве производне тајне.
Који алгоритам да користим — SHA-1, SHA-256, SHA-384 или SHA-512?
Користите HMAC-SHA256 осим ако одређени систем не захтева другачије — то је de facto стандард за потписивање API-ја (користе га AWS, Stripe, GitHub webhook-ови и већина модерних API-ја) и пружа снажну сигурносну маргину. HMAC-SHA1 је и даље чест у старијим системима (као што су старије OAuth 1.0a имплементације), али се основни хеш SHA-1 сматра слабијим; HMAC-SHA384/512 се користе тамо где је конкретно потребан дужи излаз или додатна сигурносна маргина.
Да ли је HMAC-SHA1 небезбедан, с обзиром да је обичан SHA-1 разбијен?
Напади колизије из 2017. разбили су SHA-1 као обичну хеш функцију, али HMAC-SHA1 се и даље сматра криптографски исправним јер безбедност HMAC-а не зависи од отпорности на колизије на исти начин. Ипак, за нове системе дајте предност HMAC-SHA256 или вишем — нема практичних недостатака и то потпуно избегава то питање.
Које су уобичајене праве примене HMAC-а?
Потписивање REST API захтева како би сервер могао да верификује да позивалац поседује дељену API тајну; верификација webhook садржаја од сервиса као што су Stripe, GitHub и Shopify како бисте знали да захтев заиста потиче од њих и да није фалсификован; генерисање временски заснованих једнократних лозинки (TOTP/HOTP) за двофакторску аутентификацију; и потписивање JWT токена алгоритмима HS256/HS384/HS512.