احسب HMAC أو تحقق من التوقيع الذي أرسله إليك webhook
يوقّع مولد HMAC هذا رسالة بمفتاح سري باستخدام HMAC-SHA256 أو HMAC-SHA1 أو HMAC-SHA384 أو HMAC-SHA512، ويعرض التوقيع بصيغة hex بأحرف صغيرة وكبيرة وBase64 وBase64url في آن واحد. يمكن كتابة المفتاح والرسالة كنص عادي أو hex أو Base64، لذا تعمل الأداة مع الأسرار الثنائية الخام وكلمات المرور على حد سواء. الصق التوقيع الذي استلمته — <code>sha256=…</code> من GitHub، أو ترويسة Stripe <code>t=…,v1=…</code>، أو Base64 عادي — وستخبرك الأداة إن كان مطابقًا. يتم الحساب عبر Web Crypto API في متصفحك؛ لا يغادر المفتاح ولا الرسالة الصفحة أبدًا.
كيفية إنشاء HMAC أو التحقق منه
- 1اختر دالة التجزئة: SHA-256 هي ما تستخدمه معظم واجهات API وwebhooks.
- 2اكتب المفتاح السري أو الصقه واختر طريقة كتابته: نص أو hex أو Base64. استخدم مفتاح عشوائي لإنشاء سر جديد بالطول المناسب.
- 3الصق الرسالة — في حالة webhook، جسم الطلب الخام تمامًا كما وصل، بايتًا ببايت.
- 4انسخ التوقيع بالترميز الذي تحتاجه. للتحقق من توقيع، الصقه في التوقيع المتوقع؛ تتعرف الأداة على بادئة مثل
sha256=وتتجاهلها.
ما هو HMAC؟
HMAC (hash-based message authentication code، RFC 2104) قيمة قصيرة تُحسب من رسالة ومفتاح سري. يستطيع أي شخص يعرف المفتاح حساب القيمة نفسها، وبذلك يتحقق من أمرين معًا: أن الرسالة لم تتغير في الطريق، وأن من أنشأها يملك المفتاح. بدون المفتاح لا يستطيع المهاجم تزوير HMAC صالح لرسالة جديدة ولا تعديل HMAC موجود بعد تغيير الرسالة.
ليس HMAC مجرد تجزئة للمفتاح والرسالة متلاصقين. فهو يجري التجزئة مرتين، مع مزج المفتاح في حشوة داخلية وأخرى خارجية: H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ message)). هذا البناء هو ما يجعله آمنًا مع SHA-256 وSHA-512، اللتين تكونان وحدهما عرضة لهجمات تمديد الطول (length extension) عند استخدامهما بالشكل H(key ‖ message).
التحقق من توقيعات webhook
يوقّع معظم مزودي webhooks كل طلب بـ HMAC لجسم الطلب ويضعون النتيجة في ترويسة. للتحقق، احسب HMAC لـ الجسم الخام باستخدام سر التوقيع الخاص بك وقارنه بقيمة الترويسة. أكثر خطأ شائع هو تجزئة كائن JSON أُعيدت سلسلته بدلًا من البايتات التي وصلت: ترتيب مختلف للمفاتيح أو مسافة ناقصة يغيّر التوقيع كليًا.
بعض المزودين يوقّعون أكثر من الجسم. يوقّع Stripe timestamp.body — قيمة t من الترويسة، ثم نقطة، ثم الحمولة — ويوقّع Slack v0:timestamp:body. ركّب هذا النص بالضبط كرسالة هنا، والصق الترويسة كاملة في خانة التحقق؛ وستُستخرج منها قيمة v1= أو v0=.
- GitHub
- <code>X-Hub-Signature-256: sha256=<hex></code>، HMAC-SHA256 للجسم مع سر webhook كنص.
- Stripe
- <code>Stripe-Signature: t=…,v1=<hex></code>، HMAC-SHA256 لـ <code>t.body</code>.
- Shopify
- <code>X-Shopify-Hmac-Sha256: <Base64></code>، HMAC-SHA256 للجسم.
- Slack
- <code>X-Slack-Signature: v0=<hex></code>، HMAC-SHA256 لـ <code>v0:timestamp:body</code>.
مفاتيح نصية وhex وBase64
المفتاح سلسلة من البايتات، وطريقة كتابته مهمة. النص abc123 ستة بايتات، أما hex abc123 فثلاثة بايتات مختلفة تمامًا. تمنح خدمات كثيرة الأسرار كسلاسل hex أو Base64 لكنها تتوقع أن تستخدم السلسلة نفسها كمفتاح نصي — كما يفعل GitHub وStripe — بينما تستخدم خدمات أخرى، مثل سلاسل التوقيع على طريقة AWS ووكلاء تطبيقات Shopify، البايتات بعد فك ترميزها. إذا لم يتطابق التوقيع، فأول ما تجربه هو تغيير ترميز المفتاح.
للمفتاح الجديد، استخدم بايتات عشوائية لا يقل طولها عن ناتج التجزئة: 32 بايتًا لـ HMAC-SHA256، و64 لـ HMAC-SHA512. المفاتيح الأطول لا تضيف شيئًا — فكل ما يتجاوز حجم كتلة التجزئة يُجزّأ أولًا.
المقارنة في زمن ثابت
عندما يتحقق خادمك من توقيع، قارنه بدالة تعمل في زمن ثابت مثل crypto.timingSafeEqual في Node.js أو hmac.compare_digest في Python أو hash_equals في PHP. المقارنة العادية للنصوص تتوقف عند أول حرف مختلف، والوقت الذي تستغرقه قد يكشف مقدار ما كان صحيحًا من توقيع مزوّر. تستخدم هذه الصفحة نمط الزمن الثابت نفسه، لذا فالكود مرجع إضافة إلى كونه أداة تحقق.
إذا كنت تحتاج فقط إلى مجموع تحقق عادي لملف أو نص بدون مفتاح، فاستخدم Hash Generator. ولتوقيع الرموز المميزة، ينشئ مولّد سر JWT مفاتيح HS256 بالحجم المناسب.
الأسئلة الشائعة
- ما الفرق بين التجزئة (hash) وHMAC؟
- تعتمد التجزئة مثل SHA-256 على البيانات فقط، لذا يستطيع أي أحد إعادة حسابها. أما HMAC فيعتمد أيضًا على مفتاح سري، فلا يستطيع إنشاءه أو التحقق منه إلا من يملك المفتاح. لذلك يُعد HMAC دليلًا على الأصالة لا على السلامة فحسب.
- لماذا لا يتطابق HMAC الخاص بي مع الذي أرسلته API؟
- غالبًا ما يكون المُدخل مختلفًا: الرسالة لا تطابق الجسم الخام بايتًا ببايت (JSON أُعيدت سلسلته، أو سطر جديد في النهاية، أو نهايات أسطر مختلفة)، أو يُقرأ المفتاح كنص بينما تقصد الخدمة بايتات hex أو Base64 أو العكس، أو يوقّع المزود طابعًا زمنيًا مع الجسم بدلًا من الجسم وحده.
- أي خوارزمية HMAC أستخدم؟
- HMAC-SHA256 هو الخيار القياسي وتستخدمه تقريبًا كل واجهات API. HMAC-SHA512 جيد بالقدر نفسه وأسرع على الخوادم 64 بت. ما زال HMAC-SHA1 آمنًا كـ HMAC رغم تصادمات SHA-1، لكن استخدمه فقط حين يتطلبه بروتوكول ما.
- هل تم كسر HMAC-SHA1؟
- لا. تصادمات SHA-1 لا تتيح تزوير HMAC-SHA1 بدون المفتاح، ولا يُعرف أي هجوم عملي عليه. لا يُنصح به للتصاميم الجديدة، لكن التحقق من توقيعات HMAC-SHA1 القديمة آمن.
- هل يمكنني حساب HMAC-MD5 هنا؟
- لا. واجهة Web Crypto API في المتصفح، التي تستخدمها هذه الصفحة، لا تدعم MD5. لم يبقَ HMAC-MD5 إلا في البروتوكولات القديمة؛ استخدم HMAC-SHA256 لأي شيء جديد.
- ما الطول المناسب لمفتاح HMAC؟
- لا يقل عن طول ناتج التجزئة: 32 بايتًا عشوائيًا لـ HMAC-SHA256، و48 لـ SHA-384، و64 لـ SHA-512. يولّد زر مفتاح عشوائي هذا الطول بالضبط باستخدام مولد الأرقام العشوائية الآمن في متصفحك.
- هل يمكنني استخدام مفتاح فارغ؟
- يسمح HMAC بذلك والنتيجة محددة جيدًا، لذا تعرضها الأداة، لكن المفتاح الفارغ أو القصير لا يوفر أي أمان. يمكن لأي شخص حساب التوقيع نفسه.
- هل يُرسل مفتاحي السري إلى أي مكان؟
- لا. يُحسب HMAC بواسطة Web Crypto API في متصفحك على هذه الصفحة. لا يُرفع أي شيء تكتبه ولا يُخزَّن.