مولّد HMAC

تُعد خوارزمية HMAC الأساس الذي يقوم عليه معظم الويب هوكات الموقَّعة، وعناوين AWS Signature v4، ورموز JWT HS256. فقط أدخل رسالة ومفتاح سري، واختر عائلة تجزئة (hash family)، وسيقوم هذا المولّد بإنتاج قيمة HMAC بالضبط كما ينص عليه معيار RFC 2104؛ وهو أمر مفيد للتحقق مما سيُرسله النظام الخلفي الخاص بك، أو لإعادة إنشاء توقيع استلمته من واجهة برمجة التطبيقات (API).

كيفية حساب قيمة HMAC

  1. 1

    لصق الرسالة

    البايتات الدقيقة التي يجب توقيعها: حمل منفذ ويب (webhook payload)، طلب قياسي (canonical request)، أو أي سلسلة نصية (string).

  2. 2

    أدخل المفتاح السري

    يمكن أن يكون النص أو القيمة القاعدية (hex). يقوم المولّد بتوليفها أو حساب مُجمّعاتها لتُحدد حجم الكتلة وفقًا لمواصفات RFC.

  3. 3

    اختر خوارزمية التجزئة

    SHA-256 هو القيمة الافتراضية؛ لضمان التوافق مع الأنظمة القديمة، يمكن اختيار SHA-1 أو SHA-384 أو SHA-512 أو MD5.

  4. 4

    قم بنسخ التوقيع

    يكون الناتج بصيغة سداسية عشرية (hex) بأحرف صغيرة، جاهزًا للصقه في إعداد ويب هوك أو عنوان تفويض (Authorization header).

HMAC داخل الهيكل الداخلي

تُغلِّف خوارزمية HMAC دالة تجزئة عادية ضمن بنية معتمدة على المفتاح، بحيث لا يمكن تزوير التوقيع دون معرفة المفتاح.

وصفة RFC 2104

HMAC(k, m) = H((k' ⊕ opad) ∥ H((k' ⊕ ipad) ∥ m))

حيث يمثل k' المفتاح المُعبَّأ ليتماشى مع حجم كتلة التجزئة، وopad = 0x5c repeated وipad = 0x36 repeated ثابتان للحشو.

خيارات الخوارزمية

الخوارزمية حجم الكتلة طول الناتج موصى به لـ
HMAC-SHA-256 64 بايت 32 بايت القيمة الافتراضية الحديثة، توقيع ويب هوك
HMAC-SHA-384 128 بايت 48 بايت توقيع عبر واجهة برمجة التطبيقات (API) عالي الأمان
HMAC-SHA-512 128 بايت 64 بايت رموز موثوقة طويلة الأمد
HMAC-SHA-1 64 بايت 20 بايت تقنية قديمة (AWS S3 v2، OAuth 1.0)
HMAC-MD5 64 بايت 16 بايت مخصص للنسخ القديمة فقط؛ يُنصح بتجنّب استخدامه في المشاريع الجديدة

أين يظهر HMAC؟

  • ويب هوكات GitHub وStripe وShopify: رؤوس البيانات X-Hub-Signature-256، Stripe-Signature، وغيرها.
  • AWS Signature v4: سلسلة من خوارزمية HMAC-SHA256 تُطبَّق على الطلب القياسي.
  • JWT HS256: توقيع الرمز هو HMAC-SHA-256(header.payload, secret).
  • رموز إعادة تعيين كلمة المرور: قيمة HMAC مُكوَّنة من user_id + expiry + سر الموقع.

الأخطاء الشائعة

  • إرسال مفتاح مشفر بصيغة السداسي عشرة على شكل نص، بدلاً من فك تشفيره إلى بايتات أولاً.
  • توقيع بايتات الحمولة الخاطئة: بعض ويب هوكات تُوقِّع جسم الطلب الخام مع الفراغات، بينما تُوقِّع أخرى على الشكل القياسي.
  • استخدام المكتبة == في لغات جافا سكريبت أو بايثون لمقارنة التوقيعات؛ يجب دائمًا استخدام مقارنة آمنة من حيث التزامن الزمني للوقاية من الهجمات الزمنية.

الأسئلة الشائعة

تقريبًا دائمًا بسبب اختلاف بايتات الرسالة؛ فتوقيع جسم البيانات المُحلَّل باستخدام تنسيق JSON يؤدي إلى تغييرات في المسافات الفارغة، لذا يجب توقيع جسم الطلب الخام. كما يجب التأكد من أن المفتاح يتم فك ترميزه بنفس الطريقة (سواء بالرموز السداسية أو بالبايتات الخام) على كلا الجانبين.

نعم. إذا كان المفتاح أقصر من حجم كتلة التجزئة، فيتم تعبئته بقيم صفر؛ أما إذا كان أطول، فيتم تجزئته أولًا. يوصي RFC 2104 بأن يكون طول المفتاح لا يقل عن طول الناتج (32 بايتًا بالنسبة إلى SHA-256).

ما زال HMAC مقاومًا لهجمات التصادم المعروفة على خوارزمية MD5، لأن هذه الهجمات لا تؤثر على عملية بناء قيمة HMAC. ومع ذلك، يُوصى باستخدام HMAC-SHA-256 في أي كود جديد؛ إذ يتوقع المطورون والمحققون استخدامه بشكل واسع.

نعم. يتم إرسال الرسالة والمفتاح السري إلى خادمنا عبر اتصال HTTPS مشفّر لحساب قيمة HMAC، ويُستخدمان للحساب فقط، دون تخزين أو تسجيل.

أدوات ذات صلة

الأداة متاحة بلغات أخرى