Midtrans dan Xendit, dua payment gateway paling banyak dipakai startup dan e-commerce Indonesia, menandatangani setiap notifikasi webhook dengan HMAC-SHA256: merchant menerima kunci rahasia saat mengatur integrasi, dan setiap notifikasi yang masuk membawa signature yang harus dihitung ulang secara lokal lalu dibandingkan dengan yang diterima. Jika signature tidak cocok, notifikasi itu sebenarnya bukan dari gateway pembayaran — dan tidak boleh diperlakukan sebagai konfirmasi pembayaran yang sah.
Mengapa butuh kunci rahasia, bukan sekadar hash
Hash biasa seperti SHA-256 hanya membuktikan data tidak rusak saat transit — bukan siapa yang mengirimnya. Jika server hanya melakukan hash pada body webhook dan membandingkannya dengan hash yang disertakan dalam request, penyerang bisa membuat payload palsu sendiri dan menyertakan hash yang cocok. HMAC mengatasi ini dengan mencampurkan kunci rahasia yang hanya diketahui pengirim dan penerima — tanpa kunci itu, menghasilkan signature yang valid mustahil dilakukan, bahkan jika penyerang tahu persis fungsi hash apa yang dipakai.
Mengapa ini bukan sekadar "hash kunci plus pesan"
Menggabungkan kunci dan pesan secara naif sebelum hashing (misalnya hash(kunci + pesan)) rentan terhadap serangan perluasan panjang pada beberapa fungsi hash — penyerang kadang bisa menambahkan data dan menghitung hash valid baru tanpa mengetahui kunci secara lengkap. HMAC menggunakan konstruksi khusus dengan hashing ganda dan padding internal/eksternal yang menutup total jenis serangan ini.
Di mana lagi HMAC muncul
Selain menandatangani webhook, HMAC mengautentikasi permintaan API, dan menjadi inti dari algoritma TOTP — algoritma yang sama yang menghasilkan kode enam digit di aplikasi authenticator.
Untuk apa ini dibutuhkan
- Memverifikasi keaslian webhook dari payment gateway atau layanan pihak ketiga lainnya.
- Menandatangani permintaan API tanpa pernah mengirim kunci rahasia itu sendiri melalui jaringan.
- Memahami mekanisme internal kode TOTP dan token sesi.
Perbandingan waktu konstan
Membandingkan signature yang diterima dengan yang diharapkan menggunakan operator === biasa berbahaya: operator semacam itu biasanya berhenti pada byte pertama yang berbeda, dan waktu eksekusi perbandingan membocorkan kepada penyerang berapa banyak byte awal yang berhasil ditebak dengan benar. Handler webhook yang dibuat dengan benar selalu menggunakan fungsi perbandingan waktu konstan — seperti hash_equals di PHP atau crypto.timingSafeEqual di Node.js — yang selalu memeriksa semua byte terlepas dari di mana perbedaan pertama terjadi.