Kategoria: Programistyczne

Generator HMAC

Podpisz wiadomość kluczem: HMAC-SHA-256, SHA-1, SHA-512 i MD5.

Działa w przeglądarcePrzetwarzanie lokalne. Dane wejściowe nie opuszczają Twojego urządzenia.

Klucz tajny

Zostaje na Twoim urządzeniu - nigdzie nie jest wysyłany.

Klucz odczytany w złym kodowaniu też da podpis - tyle że nigdy właściwy.

Podpis

Opcjonalnie. Wklej nagłówek z podpisem, który dostałeś; przedrostek sha256= nie przeszkadza.

Szczegóły

O tym narzędziu

Liczy HMAC, czyli skrót z kluczem, i sprawdza go z podpisem, który dostałeś. Przyjmuje klucz jako tekst, szesnastkowo albo w Base64, bo każdy dostawca podaje go inaczej, a odczytanie go w złym kodowaniu to najczęstszy pojedynczy powód, dla którego podpis się nie zgadza.

Zwykły skrót odpowiada na pytanie „co to za treść?” i policzyć go może każdy. HMAC odpowiada na pytanie „czy zrobił to ktoś, kto ma klucz?”, bo bez klucza właściwej wartości nie da się wyliczyć z samej wiadomości. Ta jedna różnica zamienia skrót w podpis i dlatego standardy przewidują właśnie HMAC, a nie zwykły skrót z sekretu sklejonego z wiadomością.

Codzienne zastosowanie to webhooki. Stripe, GitHub, Shopify, Slack i większość pozostałych podpisuje każde wywołanie zwrotne algorytmem HMAC-SHA-256 z surowego ciała żądania, a Twój endpoint przelicza podpis, żeby udowodnić, że żądanie przyszło od nich, a nie od kogoś, kto poznał adres. Kiedy ta weryfikacja zawodzi, przeliczenie podpisu ręcznie jest sposobem na ustalenie dlaczego - i po to jest to narzędzie. Na HMAC opierają się też tokeny JWT podpisane HS256, podpisywanie żądań w AWS i kody jednorazowe.

O zgodność podpisu decydują dwa szczegóły. Wiadomość musi być dokładnie tymi surowymi bajtami, które wysłano: sparsuj JSON i wypisz go z powrotem, a zmienią się białe znaki, a razem z nimi podpis. A klucz musi zostać zrozumiany tak, jak chciał dostawca - sekret podany w Base64 to bajty, a nie litery samego zapisu Base64.

Wypróbuj też

Warto wiedzieć

Najczęstsze pytania

Czym HMAC różni się od zwykłego skrótu?
Skrót odpowiada na pytanie „co to za treść?” i policzyć go może każdy. HMAC odpowiada na pytanie „czy zrobił to ktoś, kto ma klucz?”, bo bez klucza właściwej wartości nie da się wyliczyć. To dlatego nadaje się na podpis.
Podpis webhooka mi się nie zgadza. Co jest nie tak?
Dwie przyczyny pokrywają niemal wszystkie przypadki. Po pierwsze klucz: dostawcy podają go jako tekst, szesnastkowo albo w Base64, a odczytanie go inaczej daje poprawnie wyglądający podpis, który nigdy nie pasuje. Po drugie wiadomość: musi to być dokładnie surowe ciało żądania, bajt w bajt. Sparsowanie JSON-a i wypisanie go z powrotem zmienia białe znaki, a razem z nimi podpis.
Skoro MD5 jest złamany, to czy HMAC-MD5 też?
Nie, i to rozróżnienie jest prawdziwe, a nie formalne. MD5 złamały kolizje, czyli możliwość zbudowania dwóch wejść o tym samym skrócie, a konstrukcja HMAC nie opiera się na odporności na kolizje. Na HMAC-MD5 nie ma praktycznego ataku i długo działające API nadal używają go bezpiecznie. Do nowego projektu i tak nie ma po co: HMAC-SHA-256 kosztuje tyle samo i nie ciągnie za sobą żadnej dyskusji.
Jak porównywać podpisy we własnym kodzie?
Porównaniem o stałym czasie - hmac.compare_digest w Pythonie, crypto.timingSafeEqual w Node, hash_equals w PHP. Zwykłe porównanie napisów kończy się na pierwszym różniącym się znaku, więc czas jego wykonania zdradza, jaka część podpisu była poprawna, a atakujący, który potrafi to zmierzyć, odtworzy resztę znak po znaku. Ta strona jest pomocą przy debugowaniu i takiej gwarancji nie potrzebuje; Twój endpoint tak.
Czy mogę tu wkleić produkcyjny sekret?
Obliczenia wykonują się w całości w przeglądarce, a klucz nigdy nie jest przesyłany - automatyczny test przerywa budowanie, jeśli jakiekolwiek żądanie by go zawierało. Mimo to każdy sekret wklejony do dowolnej strony WWW warto potem zmienić, ten również.