Tạo và kiểm tra chữ ký HMAC SHA256 ngay trong trình duyệt
HMAC Generator tính mã xác thực HMAC-SHA256, HMAC-SHA1, HMAC-SHA384 và HMAC-SHA512 bằng Web Crypto có sẵn trong trình duyệt, nhận khóa dạng văn bản, hex hoặc base64, trả kết quả dạng hex, base64 hoặc base64url. Công cụ còn có sẵn cách kiểm tra chữ ký webhook của GitHub, Stripe, Shopify và Slack, giúp lập trình viên tìm ra vì sao máy chủ báo sai chữ ký mà không phải viết thêm dòng code thử nào.
Tính năng nổi bật
- Tính HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, HMAC-SHA512 bằng Web Crypto API, kết quả cập nhật ngay khi gõ
- Khóa bí mật nhập dạng văn bản UTF-8, chuỗi hex (chấp nhận 0x, dấu cách, dấu hai chấm) hoặc base64, base64url
- Thông điệp là văn bản hoặc tệp bất kỳ tới 512 MB, giữ nguyên từng byte kể cả dấu xuống dòng cuối
- Xuất kết quả dạng hex chữ thường, hex chữ hoa, base64 hoặc base64url
- Chế độ kiểm tra: dán chữ ký có sẵn, tự nhận hex hay base64, bỏ tiền tố sha256=, so sánh không dừng sớm ở byte khác đầu tiên
- Mẫu webhook GitHub (X-Hub-Signature-256), Stripe (Stripe-Signature t=...,v1=...), Shopify (X-Shopify-Hmac-Sha256) và Slack (X-Slack-Signature v0=...) đúng theo tài liệu chính thức
- Kiểm tra độ lệch timestamp của Stripe và Slack để phát hiện yêu cầu phát lại (replay), ngưỡng mặc định 300 giây có thể chỉnh
- Cảnh báo khi khóa hoặc thông điệp có chữ tiếng Việt dạng tổ hợp NFD, nguyên nhân phổ biến khiến chữ ký lệch giữa hai hệ thống
Vì sao nên có một công cụ HMAC riêng khi làm webhook và API
Lỗi chữ ký webhook là một trong những lỗi mất thời gian nhất khi tích hợp thanh toán hay tự động hóa: máy chủ chỉ trả về một dòng signature mismatch, còn nguyên nhân có thể là sai secret, đọc body sau khi framework đã parse lại JSON, thiếu dấu xuống dòng cuối, ghép sai chuỗi timestamp của Stripe hoặc Slack, hay so sánh hex với base64. Công cụ này cho bạn tính lại chữ ký đúng theo cách từng dịch vụ mô tả, đặt cạnh chữ ký nhận được và biết ngay phần nào lệch. Mọi phép tính chạy bằng Web Crypto trong trình duyệt, không có dữ liệu nào gửi về máy chủ của chúng tôi, nên bạn có thể thử với secret của môi trường test mà không lo lộ.
Lợi ích khi sử dụng
- Tìm ra nguyên nhân lỗi signature mismatch trong vài phút thay vì thêm log và deploy lại nhiều lần
- Không cần cài thêm thư viện hay viết script tạm chỉ để tính một chữ ký
- Khóa và dữ liệu không rời khỏi trình duyệt, phù hợp khi làm việc với secret của môi trường test
- Hiểu đúng khác biệt giữa bốn cách ký webhook phổ biến để viết mã kiểm tra chuẩn ngay từ đầu
- Kiểm tra được cả tệp lớn, hữu ích khi cần xác thực tính toàn vẹn của tệp tải về có kèm HMAC
Cách tạo và kiểm tra HMAC SHA256 online
- 1Ở thẻ Tính HMAC, chọn thuật toán, mặc định là HMAC-SHA256 vì đây là lựa chọn phổ biến nhất cho webhook và ký API.
- 2Nhập khóa bí mật và chọn đúng định dạng của khóa: văn bản nếu secret là chuỗi ký tự bình thường, hex hoặc base64 nếu hệ thống cấp khóa dạng mã hóa đó.
- 3Nhập thông điệp cần ký hoặc chọn tệp; chữ ký hiện ngay ở khung kết quả, đổi sang hex, base64 hoặc base64url tùy nơi bạn cần dán.
- 4Để kiểm tra một chữ ký có sẵn, dán nó vào ô Kiểm tra chữ ký; công cụ tự nhận định dạng và báo khớp hay không khớp.
- 5Với webhook, chuyển sang thẻ Chữ ký webhook, chọn GitHub, Stripe, Shopify hoặc Slack, dán secret, body thô và giá trị header nhận được rồi bấm Kiểm tra chữ ký.
- 6Nếu cần gửi thử webhook tới máy chủ của mình, nhập secret và body rồi bấm Tạo header để lấy đúng giá trị header mà dịch vụ thật sẽ gửi.
HMAC là gì và khác gì với một hàm băm thông thường
HMAC (Hash-based Message Authentication Code) là cách dùng một hàm băm như SHA-256 kết hợp với khóa bí mật để tạo mã xác thực cho thông điệp, được chuẩn hóa trong RFC 2104. Hàm băm thông thường như SHA-256 thì ai cũng tính được: có nội dung là có mã băm, nên nó chỉ phát hiện dữ liệu bị hỏng chứ không chứng minh được ai gửi. HMAC trộn khóa bí mật vào hai lượt băm lồng nhau, nên chỉ bên nào giữ khóa mới tạo được đúng mã. Khi GitHub gửi webhook kèm chữ ký HMAC-SHA256, máy chủ của bạn tính lại với cùng secret; nếu khớp, bạn biết chắc yêu cầu đến từ GitHub và body không bị sửa trên đường truyền. Lưu ý HMAC khác hẳn chữ ký số RSA hay ECDSA: HMAC dùng một khóa chung cho cả hai bên, còn chữ ký số dùng cặp khóa riêng và công khai.
Cách GitHub, Stripe, Shopify và Slack ký webhook
Bốn dịch vụ đều dùng HMAC-SHA256 nhưng khác nhau ở chuỗi được ký và cách trình bày kết quả. GitHub ký nguyên body thô và gửi header X-Hub-Signature-256 dạng sha256= theo sau là 64 ký tự hex. Shopify cũng ký nguyên body thô nhưng gửi dạng base64 trong X-Shopify-Hmac-Sha256. Stripe ghép timestamp, một dấu chấm và body thô thành chuỗi cần ký, dùng nguyên endpoint secret (kể cả tiền tố whsec_) làm khóa, rồi gửi header Stripe-Signature dạng t=timestamp,v1=chữ ký hex; khi bạn đang xoay secret, header có thể chứa hai chữ ký v1. Slack ghép chuỗi v0:timestamp:body, gửi chữ ký trong X-Slack-Signature dạng v0=hex và timestamp trong X-Slack-Request-Timestamp. Công cụ đã được kiểm tra với ví dụ mẫu trong tài liệu của GitHub (secret It's a Secret to Everybody, body Hello, World! cho ra sha256=757107ea0eb2509fc211221cce984b8a37570b6d7586c22c46f4379c8b043e17) và của Slack, cho kết quả trùng khớp.
Năm nguyên nhân khiến chữ ký webhook không khớp
Thứ nhất, ký trên body đã bị framework parse rồi stringify lại: JSON sau khi qua JSON.parse và JSON.stringify có thể mất khoảng trắng, đổi thứ tự khóa hoặc đổi cách viết số, nên phải lấy body thô dạng Buffer hoặc chuỗi gốc trước khi parse. Thứ hai, dùng nhầm secret, ví dụ secret của môi trường live cho sự kiện test của Stripe, hoặc secret của webhook khác. Thứ ba, so sánh sai định dạng: chữ ký Shopify là base64 trong khi bạn tính ra hex. Thứ tư, quên tiền tố như sha256= hoặc v0=, hoặc ghép sai chuỗi timestamp. Thứ năm, dữ liệu có chữ tiếng Việt bị đổi dạng Unicode giữa đường đi, từ dạng dựng sẵn NFC sang dạng tổ hợp NFD hay ngược lại: mắt nhìn giống hệt nhau nhưng byte khác nhau nên chữ ký khác hoàn toàn. Công cụ cảnh báo trường hợp thứ năm và cố ý không tự chuẩn hóa để bạn thấy đúng dữ liệu gốc.
Vì sao phải so sánh chữ ký bằng hàm thời gian hằng
Nếu mã kiểm tra dùng phép so sánh chuỗi thông thường, chương trình dừng ngay ở ký tự khác đầu tiên, nên thời gian phản hồi lộ ra số ký tự đầu đã đúng. Kẻ tấn công gửi rất nhiều yêu cầu, đo thời gian và đoán dần từng byte của chữ ký hợp lệ, gọi là tấn công theo thời gian (timing attack). Cách phòng là dùng hàm so sánh chạy qua toàn bộ byte bất kể khác ở đâu: crypto.timingSafeEqual trong Node.js, hmac.compare_digest trong Python, hash_equals trong PHP, hmac.Equal trong Go, CryptographicOperations.FixedTimeEquals trong .NET. Chế độ kiểm tra của công cụ này cũng so sánh theo cách đó để minh họa, dù trên trình duyệt của chính bạn thì rủi ro timing gần như không có.
Chọn độ dài khóa và thuật toán HMAC phù hợp
Với HMAC-SHA256, khóa nên dài ít nhất 32 byte ngẫu nhiên, tức 256 bit, tạo bằng bộ sinh số ngẫu nhiên an toàn chứ không phải một câu dễ nhớ. Khóa dài hơn kích thước khối của hàm băm (64 byte với SHA-1 và SHA-256, 128 byte với SHA-384 và SHA-512) sẽ bị băm trước khi dùng theo đúng chuẩn, công cụ có ghi chú khi điều này xảy ra. HMAC-SHA1 vẫn an toàn về mặt lý thuyết vì HMAC không bị ảnh hưởng bởi lỗ hổng va chạm của SHA-1, nhưng chỉ nên dùng khi phải tương thích hệ thống cũ như header X-Hub-Signature đời đầu của GitHub. Công cụ không hỗ trợ HMAC-MD5 vì Web Crypto không có MD5 và thuật toán này không nên dùng cho hệ thống mới.
Giới hạn của công cụ và lưu ý bảo mật
Mọi phép tính chạy trong trình duyệt của bạn, trang không gửi khóa hay thông điệp đi đâu. Dù vậy, bất kỳ thứ gì bạn dán vào trình duyệt vẫn có thể bị phần mở rộng trình duyệt, phần mềm quản lý clipboard hay người xung quanh nhìn thấy, nên đừng dán secret của môi trường production trên máy dùng chung hoặc máy không phải của mình. Công cụ cần trình duyệt hỗ trợ Web Crypto, tức Chrome, Edge, Firefox, Safari bản mới và trang chạy qua HTTPS. Web Crypto không chấp nhận khóa rỗng dài 0 byte. Tệp thông điệp được nạp toàn bộ vào bộ nhớ nên giới hạn ở 512 MB. Việc kiểm tra timestamp dựa vào đồng hồ máy bạn, nếu đồng hồ lệch thì kết quả về độ trễ cũng lệch theo.
Câu hỏi thường gặp (FAQ)
HMAC SHA256 generator này có gửi khóa bí mật lên máy chủ không?
Không. Công cụ dùng Web Crypto API có sẵn trong trình duyệt để tính HMAC, khóa và thông điệp chỉ nằm trong bộ nhớ của tab đang mở. Tuy vậy vẫn không nên dán secret production trên máy dùng chung.
Vì sao chữ ký tôi tính ra khác với chữ ký trong header webhook?
Nguyên nhân thường gặp nhất là tính trên body đã bị parse và stringify lại thay vì body thô, dùng sai secret, so sánh hex với base64, hoặc ghép sai chuỗi timestamp với Stripe và Slack. Hãy dùng thẻ Chữ ký webhook và dán đúng body thô nhận được.
Khóa bí mật nên nhập dạng văn bản, hex hay base64?
Chọn đúng dạng mà hệ thống cấp khóa đang dùng. Secret của GitHub, Stripe, Slack là chuỗi ký tự nên chọn Văn bản. Nếu tài liệu API ghi khóa là chuỗi hex hoặc base64 cần giải mã trước khi dùng, hãy chọn định dạng tương ứng, nếu không byte của khóa sẽ khác.
Stripe dùng secret whsec_ như thế nào khi ký webhook?
Stripe dùng nguyên chuỗi endpoint secret, kể cả tiền tố whsec_, làm khóa HMAC-SHA256 dạng văn bản. Chuỗi được ký là timestamp, một dấu chấm, rồi body thô. Kết quả hex nằm ở phần v1= của header Stripe-Signature.
Chữ ký Shopify khác GitHub ở điểm nào?
Cả hai ký nguyên body thô bằng HMAC-SHA256, nhưng GitHub gửi dạng hex có tiền tố sha256= trong X-Hub-Signature-256, còn Shopify gửi dạng base64 không tiền tố trong X-Shopify-Hmac-Sha256.
Vì sao Stripe và Slack kiểm tra timestamp?
Để chống tấn công phát lại: kẻ xấu bắt được một yêu cầu hợp lệ và gửi lại sau đó. Vì timestamp nằm trong chuỗi được ký nên không sửa được, máy chủ chỉ cần từ chối yêu cầu quá cũ. Stripe mặc định chấp nhận lệch 300 giây, Slack khuyên 5 phút.
Có hỗ trợ HMAC-MD5 không?
Không. Web Crypto API của trình duyệt không có MD5, và công cụ cố ý không tự viết lại thuật toán này vì MD5 không còn phù hợp cho hệ thống mới. Nếu phải làm việc với hệ thống cũ dùng HMAC-MD5, hãy tính bằng thư viện ở phía máy chủ.
Kết quả hex và base64 khác nhau có phải là hai chữ ký khác nhau không?
Không, đó là cùng một chuỗi byte được viết theo hai cách. HMAC-SHA256 luôn ra 32 byte, viết dạng hex thành 64 ký tự, dạng base64 thành 44 ký tự có dấu = ở cuối. Base64url thay dấu + và / bằng - và _ và bỏ dấu =.
Có tính HMAC cho tệp được không?
Được. Chọn Tệp ở phần thông điệp, công cụ đọc toàn bộ byte của tệp và tính HMAC. Giới hạn 512 MB vì Web Crypto cần nạp cả tệp vào bộ nhớ.
Chữ tiếng Việt có dấu có làm sai chữ ký không?
Có thể, nếu hai hệ thống lưu chữ có dấu theo hai dạng Unicode khác nhau (NFC dựng sẵn và NFD tổ hợp). Chúng trông giống hệt nhau nhưng khác byte. Công cụ phát hiện và cảnh báo khi khóa hoặc thông điệp đang ở dạng NFD, kèm nút chuyển về NFC.
HMAC có phải là mã hóa không, có giải ngược ra thông điệp được không?
Không. HMAC là mã xác thực một chiều, không chứa thông điệp và không giải ngược được. Nó chỉ dùng để kiểm tra thông điệp có đúng do người giữ khóa tạo ra và không bị sửa. Muốn giấu nội dung thì cần mã hóa như AES.
Nên dùng công cụ này hay Hash Calculator?
Nếu cần mã băm thông thường không có khóa, ví dụ SHA-256 của một tệp để so với checksum công bố, hãy dùng Hash Calculator. Nếu có khóa bí mật tham gia, như chữ ký webhook hay ký yêu cầu API, hãy dùng HMAC Generator.
JWT HS256 có liên quan gì đến HMAC?
HS256 trong JWT chính là HMAC-SHA256 tính trên chuỗi header.payload đã mã base64url, kết quả được viết dạng base64url làm phần chữ ký. Muốn tạo JWT đầy đủ, hãy dùng JWT Generator của Tấn Phát Digital.
Từ khóa liên quan
- hmac sha256 generator
- hmac generator online
- tạo hmac sha256
- kiểm tra chữ ký hmac
- hmac sha256 online
- hmac sha512 online
- hmac sha1 online
- verify webhook signature
- github webhook signature
- x-hub-signature-256
- stripe webhook signature
- stripe-signature header
- shopify hmac verify
- slack signing secret
- tính hmac trực tuyến
- web crypto hmac
- hmac base64
- hmac hex
- chữ ký webhook
- timing safe compare
