CodeKitHubApa Itu Alat Ini?
HMAC adalah singkatan dari Hash-based Message Authentication Code. HMAC menggabungkan kunci rahasia dengan pesan dan fungsi hash standar (seperti SHA-256) untuk menghasilkan digest dengan panjang tetap. Siapa pun yang punya kunci dan pesan yang sama akan menghasilkan HMAC yang persis sama — tetapi tanpa kunci tersebut, mustahil secara komputasi untuk menghasilkan HMAC yang valid untuk suatu pesan, sekalipun algoritma hash yang dipakai diketahui.
Itulah perbedaan mendasar dari hash biasa: hash biasa (MD5, SHA-256, dll.) hanya menerima pesan sebagai input, sehingga siapa pun bisa menghitungnya dan itu tidak membuktikan apa-apa tentang siapa pembuatnya. HMAC menerima pesan *dan* kunci rahasia, sehingga HMAC yang valid membuktikan bahwa pengirim memang memegang kunci rahasia tersebut — ini mekanisme autentikasi, bukan sekadar pemeriksaan integritas.
HMAC distandarkan secara resmi oleh NIST dalam FIPS 198-1 dan didefinisikan untuk protokol internet dalam IETF RFC 2104. Alat ini menghitung HMAC menggunakan Web Crypto API native browser Anda (`crypto.subtle.sign` dengan algoritma HMAC), yang mengimplementasikan RFC 2104 secara benar, bukan versi JavaScript buatan sendiri.
Mengapa Menggunakannya?
- Endpoint webhook Stripe Anda baru menolak sebuah request karena signature mismatch, dan Anda perlu menghitung ulang HMAC-SHA256 manual dari payload dan secret untuk mencari tahu di mana letak perbedaannya.
- Anda sedang menulis dokumentasi integrasi API internal dan butuh contoh HMAC yang benar untuk ditunjukkan ke tim eksternal, tanpa harus jalankan skrip backend hanya untuk satu contoh.
- Kode HMAC Node.js atau Python yang baru Anda tulis menghasilkan output yang beda dari yang diharapkan, dan Anda butuh nilai referensi independen dari implementasi lain untuk mencari tahu bug-nya di mana.
- Anda debugging integrasi GitHub webhook dan perlu memverifikasi header X-Hub-Signature-256 yang diterima cocok dengan HMAC yang dihitung dari payload mentah dan secret webhook.
- Anda perlu segera menghasilkan HMAC untuk secret produksi asli saat troubleshooting insiden, dan tidak mau mengirim secret itu ke server pihak ketiga mana pun.
- 100% lokal: kunci rahasia dan pesan Anda tidak pernah meninggalkan browser, jadi aman untuk menguji secret asli.
Cara Menggunakan
- Masukkan kunci rahasia Anda di kolom "Secret Key".
- Masukkan pesan yang ingin Anda autentikasi di kolom "Message".
- Hasil HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, dan HMAC-SHA512 langsung dihasilkan (centang "Uppercase output" jika sistem tujuan Anda mengharapkan huruf kapital).
- Klik "Copy" di sebelah HMAC yang Anda butuhkan.
Contoh
Input
Secret Key: key
Message: The quick brown fox jumps over the lazy dogOutput
HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9Ini adalah test vector standar yang sudah dipublikasikan: dengan key "key" dan pesan persis ini, HMAC-SHA256 dan HMAC-SHA1 selalu menghasilkan nilai ini pada implementasi mana pun yang benar, sehingga Anda bisa memverifikasi output alat ini secara independen.
HMAC vs hash biasa: kapan Anda butuh kunci
Pertanyaan penentunya adalah: apakah Anda perlu membuktikan siapa pembuat digest ini, atau hanya perlu memastikan kontennya tidak berubah? Jika checksum publik sudah cukup — memverifikasi file unduhan sesuai dengan yang dicantumkan penerbit, mendeduplikasi record — hash biasa sudah memadai dan siapa pun bisa memeriksanya tanpa kunci. Jika Anda perlu membuktikan bahwa digest hanya bisa dihasilkan oleh pihak yang memegang secret tertentu — mengautentikasi pemanggil API, mempercayai pengirim webhook — Anda memerlukan HMAC, karena hash biasa memberi penyerang tanpa secret kemampuan yang sama untuk memalsukan digest valid seperti pengirim asli.
→ Generator Hash Multi-Algoritma · Dekoder JWT · Generator MD5
Membandingkan keempat algoritma HMAC
Keempatnya menggunakan konstruksi HMAC yang sama dari RFC 2104, hanya berbeda pada fungsi hash dasarnya dan karenanya panjang outputnya.
| Algoritma | Ukuran output | Penggunaan umum |
|---|---|---|
| HMAC-SHA1 | 160-bit (40 karakter hex) | API lawas, tanda tangan OAuth 1.0a yang lebih tua |
| HMAC-SHA256 | 256-bit (64 karakter hex) | Penandatanganan request API, JWT HS256, verifikasi webhook |
| HMAC-SHA384 | 384-bit (96 karakter hex) | Tanda tangan dengan jaminan lebih tinggi yang memerlukan output lebih panjang |
| HMAC-SHA512 | 512-bit (128 karakter hex) | Digest dengan panjang maksimum untuk aplikasi berkeamanan tinggi |
Kasus penggunaan umum
- Menandatangani request API keluar dengan secret bersama sehingga server bisa memverifikasi identitas pemanggil.
- Memverifikasi payload webhook masuk (header Stripe-Signature, GitHub X-Hub-Signature-256, dan sejenisnya semuanya memakai HMAC-SHA256).
- Membuat dan memvalidasi bagian tanda tangan JWT yang ditandatangani dengan HS256/HS384/HS512.
- Menguji apakah implementasi HMAC di sisi server atau klien Anda cocok dengan output yang diharapkan sebelum di-deploy.
Kesalahan umum saat mengimplementasikan HMAC sendiri
Kebanyakan bug "HMAC saya tidak cocok" bukan berasal dari algoritma yang salah, melainkan dari detail kecil di sekitar bagaimana kunci dan pesan disiapkan sebelum dihitung.
- Pastikan kunci diperlakukan dengan encoding yang sama di kedua sisi — string UTF-8 biasa dan string hex/base64 yang di-decode dulu akan menghasilkan HMAC yang sama sekali berbeda meski terlihat sama secara visual.
- Untuk verifikasi webhook, selalu hitung HMAC dari payload mentah (raw body) sebelum di-parse jadi objek JSON — banyak framework backend otomatis mem-parse body request, dan kalau Anda menghitung ulang dari objek yang sudah di-stringify lagi, urutan key atau spasi bisa berbeda dari body asli yang dikirim pengirim.
- Selalu gunakan perbandingan constant-time (bukan `===` biasa) saat memverifikasi HMAC di kode produksi Anda sendiri, untuk menghindari celah timing attack — alat ini hanya untuk menghasilkan dan membandingkan secara visual saat debugging, bukan pengganti logika verifikasi produksi.
Pertanyaan yang Sering Diajukan
Apa itu HMAC?
HMAC (Hash-based Message Authentication Code) menggabungkan kunci rahasia dengan pesan menggunakan fungsi hash untuk menghasilkan digest yang membuktikan integritas pesan sekaligus kepemilikan kunci oleh pengirim. HMAC didefinisikan dalam NIST FIPS 198-1 dan IETF RFC 2104.
Apa bedanya HMAC dengan hash biasa?
Hash biasa (SHA-256, MD5, dll.) hanya menerima pesan sebagai input — siapa pun bisa menghitungnya, sehingga hanya membuktikan pesan tidak rusak, bukan siapa pengirimnya. HMAC menerima pesan ditambah kunci rahasia: jika Anda perlu membuktikan bahwa pesan berasal dari pihak yang memegang secret tertentu (tanda tangan API, pengirim webhook), Anda memerlukan HMAC. Jika Anda hanya perlu memastikan sebuah file atau pesan tidak berubah tanpa peduli membuktikan siapa pembuatnya, hash biasa sudah cukup.
Apakah kunci rahasia saya dikirim ke server?
Tidak. Alat ini menghitung HMAC sepenuhnya di browser Anda menggunakan Web Crypto API. Kunci dan pesan Anda tidak pernah dikirim ke mana pun — Anda bisa dengan aman menguji secret produksi yang sesungguhnya.
Algoritma mana yang sebaiknya saya pakai — SHA-1, SHA-256, SHA-384, atau SHA-512?
Gunakan HMAC-SHA256 kecuali sistem tertentu mengharuskan yang lain — ini standar de facto untuk penandatanganan API (dipakai oleh AWS, Stripe, webhook GitHub, dan sebagian besar API modern) dan menawarkan margin keamanan yang kuat. HMAC-SHA1 masih umum di sistem lama (seperti implementasi OAuth 1.0a yang lebih tua), tetapi hash dasar SHA-1 dianggap lebih lemah; HMAC-SHA384/512 dipakai ketika output yang lebih panjang atau margin keamanan ekstra memang diperlukan.
Apakah HMAC-SHA1 tidak aman, mengingat SHA-1 biasa sudah bisa dibobol?
Serangan kolisi tahun 2017 terhadap SHA-1 membobol SHA-1 sebagai fungsi hash biasa, tetapi HMAC-SHA1 tetap dianggap aman secara kriptografis karena keamanan HMAC tidak bergantung pada resistansi kolisi dengan cara yang sama. Meski begitu, lebih baik gunakan HMAC-SHA256 ke atas untuk sistem baru — tidak ada kerugian praktisnya dan ini menghindari perdebatan tersebut sama sekali.
Apa saja penggunaan nyata HMAC di dunia?
Menandatangani request REST API sehingga server bisa memverifikasi bahwa pemanggil memegang secret API bersama; memverifikasi payload webhook dari layanan seperti Stripe, GitHub, dan Shopify sehingga Anda tahu request itu benar-benar berasal dari mereka dan tidak dipalsukan; membuat one-time password berbasis waktu (TOTP/HOTP) untuk autentikasi dua faktor; dan menandatangani token JWT dengan algoritma HS256/HS384/HS512.
Kenapa HMAC yang saya hitung sendiri di kode berbeda dari hasil alat ini?
Penyebab paling umum adalah encoding pesan atau kunci yang tidak konsisten (misalnya kunci diperlakukan sebagai UTF-8 di satu sisi tapi hex di sisi lain), whitespace atau newline tersembunyi yang ikut masuk ke payload (umum terjadi kalau Anda copy-paste dari JSON yang sudah di-reformat), atau kunci yang salah environment (secret staging dipakai untuk memverifikasi payload production). Cek dulu representasi byte persis dari kunci dan pesan sebelum menyalahkan algoritmanya.
Apakah urutan kunci dan pesan penting — bisa dibalik?
Tidak bisa dibalik begitu saja. HMAC didefinisikan secara spesifik sebagai H(key XOR opad, H(key XOR ipad, message)) sesuai RFC 2104 — kunci dan pesan punya peran matematis yang berbeda dalam konstruksinya, bukan cuma dua input yang bisa ditukar posisi. Menukar mana yang jadi "kunci" dan mana yang jadi "pesan" akan menghasilkan HMAC yang sama sekali berbeda.
Apakah HMAC bisa dipakai untuk mengenkripsi data, bukan cuma memverifikasi?
Tidak — HMAC adalah fungsi satu arah yang menghasilkan digest tetap, bukan mekanisme enkripsi. Anda tidak bisa "mendekripsi" HMAC untuk mendapatkan pesan aslinya kembali; HMAC hanya membuktikan integritas dan keaslian pesan yang sudah Anda ketahui, bukan menyembunyikan isinya. Untuk enkripsi, Anda perlu algoritma terpisah seperti AES.
Apa yang terjadi kalau kunci rahasia saya lebih pendek dari ukuran blok fungsi hash?
Menurut RFC 2104, jika kunci lebih pendek dari ukuran blok internal fungsi hash (64 byte untuk SHA-1/SHA-256, 128 byte untuk SHA-384/SHA-512), kunci tersebut akan di-pad dengan byte nol di akhir hingga mencapai ukuran blok sebelum dipakai dalam perhitungan — ini ditangani otomatis oleh Web Crypto API, Anda tidak perlu melakukan padding manual.