CodeKitHub
أدوات الترميز

مولّد HMAC

آخر تحديث:

تحسب هذه الأداة قيمة HMAC (رمز مصادقة الرسائل المعتمد على التجزئة) من مفتاح سري ورسالة، باستخدام SHA-1 أو SHA-256 أو SHA-384 أو SHA-512 كدالة تجزئة أساسية. على عكس التجزئة العادية، يتطلب HMAC مفتاحًا سريًا مشتركًا، لذا فهو يثبت أن الرسالة صادرة عن جهة تملك ذلك المفتاح ولم تتغير أثناء النقل — ولهذا السبب تستخدم واجهات برمجة التطبيقات HMAC لتوقيع الطلبات، وتستخدمه الويب هوكس للتحقق من مرسل الحمولة. كل شيء يعمل محليًا عبر واجهة Web Crypto API المدمجة في متصفحك؛ لا يُرسل مفتاحك السري أو رسالتك إلى أي خادم أبدًا.

HMAC-SHA1
HMAC-SHA256
HMAC-SHA384
HMAC-SHA512

ما هي هذه الأداة؟

HMAC هو اختصار لـ Hash-based Message Authentication Code. يجمع بين مفتاح سري ورسالة ودالة تجزئة قياسية (مثل SHA-256) لإنتاج ملخّص ثابت الطول. أي شخص يملك نفس المفتاح والرسالة سيحسب نفس قيمة HMAC تمامًا — لكن بدون المفتاح، يستحيل عمليًا إنتاج قيمة HMAC صالحة لرسالة ما، حتى لو كنت تعرف خوارزمية التجزئة المستخدمة.

هذا هو الفرق الجوهري عن التجزئة العادية: التجزئة العادية (MD5، SHA-256، إلخ) تأخذ الرسالة فقط كمدخل، لذا يمكن لأي شخص حسابها ولا تثبت شيئًا عن هوية من أنشأها. أما HMAC فيأخذ الرسالة *ومعها* مفتاحًا سريًا، لذا فإن HMAC صالح يثبت أن المُرسل كان يملك السر — إنه آلية مصادقة، وليس مجرد فحص سلامة.

تم توحيد HMAC رسميًا من قِبل NIST في FIPS 198-1 وتم تعريفه لبروتوكولات الإنترنت في IETF RFC 2104. تحسب هذه الأداة قيم HMAC باستخدام واجهة Web Crypto API الأصلية في متصفحك (`crypto.subtle.sign` مع خوارزمية HMAC)، والتي تطبّق RFC 2104 بشكل صحيح بدلًا من نسخة جافاسكريبت مكتوبة يدويًا.

لماذا تستخدمها؟

  • توقيع طلبات API بحيث يتمكن الخادم المستقبِل من التحقق من أن الطلب صادر عن حامل السر المشترك ولم يتم العبث به.
  • التحقق من حمولات الويب هوك (Stripe وGitHub وShopify وخدمات مشابهة توقّع كلها أجسام الويب هوك باستخدام HMAC-SHA256).
  • توليد رموز مصادقة أو رموز لمرة واحدة تعتمد على سر مشترك.
  • مقارنة مخرجات تطبيقك الخاص لـ HMAC بقيمة مرجعية معروفة الصحة.
  • محلي بنسبة 100%: مفتاحك السري ورسالتك لا يغادران المتصفح أبدًا، لذا فمن الآمن اختبار أسرار حقيقية.

كيفية الاستخدام

  1. أدخل مفتاحك السري في حقل "المفتاح السري".
  2. أدخل الرسالة التي تريد مصادقتها في حقل "الرسالة".
  3. تُنشأ نتائج HMAC-SHA1 وHMAC-SHA256 وHMAC-SHA384 وHMAC-SHA512 فورًا (فعّل "إخراج بأحرف كبيرة" إذا كان النظام المستهدف يتوقع أحرفًا كبيرة).
  4. انقر "نسخ" بجانب قيمة HMAC التي تحتاجها.

مثال

الإدخال

المفتاح السري: key
الرسالة: The quick brown fox jumps over the lazy dog

الناتج

HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

هذا متجه اختبار قياسي منشور: باستخدام المفتاح "key" وهذه الرسالة بالضبط، ينتج HMAC-SHA256 وHMAC-SHA1 دائمًا هذه القيم في أي تطبيق صحيح، لذا يمكنك التحقق من مخرجات هذه الأداة بشكل مستقل.

HMAC مقابل التجزئة العادية: متى تحتاج إلى مفتاح

السؤال الحاسم هو: هل تحتاج إلى إثبات من أنشأ هذا الملخّص، أم فقط أن المحتوى لم يتغير؟ إذا كان مجموع اختباري عام كافيًا — كالتحقق من أن ملفًا تم تنزيله يطابق ما نشره الناشر، أو إزالة التكرار من السجلات — فالتجزئة العادية تفي بالغرض ويمكن لأي شخص التحقق منها دون مفتاح. أما إذا كنت بحاجة لإثبات أن الملخّص لا يمكن أن يُنتج إلا من جهة تملك سرًا معينًا — مصادقة متصل API، الوثوق بمرسل ويب هوك — فأنت بحاجة إلى HMAC، لأن التجزئة العادية تمنح مهاجمًا بلا سر نفس القدرة على تزوير ملخّص صالح كالمرسل الحقيقي.

مقارنة خوارزميات HMAC الأربع

تستخدم الخوارزميات الأربع نفس بنية HMAC من RFC 2104، وتختلف فقط في دالة التجزئة الأساسية وبالتالي في طول المخرجات.

الخوارزميةحجم المخرجاتالاستخدام النموذجي
HMAC-SHA1160 بت (40 حرفًا سداسيًا عشريًا)واجهات API القديمة، توقيعات OAuth 1.0a الأقدم
HMAC-SHA256256 بت (64 حرفًا سداسيًا عشريًا)توقيع طلبات API، JWT HS256، التحقق من الويب هوك
HMAC-SHA384384 بت (96 حرفًا سداسيًا عشريًا)التوقيعات عالية الضمان حيث يُطلب إخراج أطول
HMAC-SHA512512 بت (128 حرفًا سداسيًا عشريًا)ملخّصات بأقصى طول للتطبيقات عالية الأمان

حالات الاستخدام الشائعة

  • توقيع طلبات API الصادرة بمفتاح سري مشترك بحيث يمكن للخادم التحقق من هوية المتصل.
  • التحقق من حمولات الويب هوك الواردة (رؤوس مثل Stripe-Signature وGitHub X-Hub-Signature-256 وما شابهها تستخدم كلها HMAC-SHA256).
  • توليد والتحقق من جزء التوقيع في رمز JWT الموقَّع بـ HS256/HS384/HS512.
  • اختبار تطابق تطبيقك لـ HMAC من جانب الخادم أو العميل مع المخرجات المتوقعة قبل نشره.

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

ما هو HMAC؟

يجمع HMAC (رمز مصادقة الرسائل المعتمد على التجزئة) بين مفتاح سري ورسالة باستخدام دالة تجزئة لإنتاج ملخّص يثبت سلامة الرسالة وامتلاك المرسل للمفتاح معًا. وهو معرّف في NIST FIPS 198-1 وIETF RFC 2104.

ما الفرق بين HMAC والتجزئة العادية؟

التجزئة العادية (SHA-256، MD5، إلخ) تأخذ الرسالة فقط كمدخل — يمكن لأي شخص حسابها، لذا فهي تثبت فقط أن الرسالة لم تُفسد، لا من أرسلها. أما HMAC فيأخذ رسالة بالإضافة إلى مفتاح سري: إذا كنت بحاجة لإثبات أن رسالة ما صادرة عن جهة تملك سرًا معينًا (توقيع API، مرسِل ويب هوك)، فأنت بحاجة إلى HMAC. إذا كنت فقط بحاجة للتحقق من أن ملفًا أو رسالة لم تتغير ولا يهمك إثبات هوية المؤلف، فالتجزئة العادية كافية.

هل يُرسل مفتاحي السري إلى خادم؟

لا. تحسب هذه الأداة قيمة HMAC بالكامل في متصفحك باستخدام واجهة Web Crypto API. مفتاحك ورسالتك لا يُنقلان إلى أي مكان أبدًا — يمكنك اختبار أسرار إنتاج حقيقية بأمان.

أي خوارزمية يجب أن أستخدم — SHA-1 أو SHA-256 أو SHA-384 أو SHA-512؟

استخدم HMAC-SHA256 ما لم يتطلب نظام معين خلاف ذلك — فهو المعيار الفعلي لتوقيع API (تستخدمه AWS وStripe وويب هوكس GitHub ومعظم واجهات API الحديثة) ويوفر هامش أمان قوي. لا يزال HMAC-SHA1 شائعًا في الأنظمة القديمة (مثل تطبيقات OAuth 1.0a الأقدم) لكن دالة التجزئة الأساسية لـ SHA-1 تُعتبر أضعف؛ يُستخدم HMAC-SHA384/512 حيث يُطلب صراحة إخراج أطول أو هامش أمان إضافي.

هل HMAC-SHA1 غير آمن، بما أن SHA-1 العادي مكسور؟

كسرت هجمات التصادم عام 2017 خوارزمية SHA-1 كدالة تجزئة عادية، لكن HMAC-SHA1 لا يزال يُعتبر سليمًا من الناحية التشفيرية لأن أمان HMAC لا يعتمد على مقاومة التصادم بنفس الطريقة. مع ذلك، يُفضّل استخدام HMAC-SHA256 أو أعلى للأنظمة الجديدة — لا يوجد عيب عملي وهذا يتجنب المسألة كليًا.

ما هي الاستخدامات الشائعة الواقعية لـ HMAC؟

توقيع طلبات REST API بحيث يمكن للخادم التحقق من أن المتصل يملك سر API المشترك؛ التحقق من حمولات الويب هوك من خدمات مثل Stripe وGitHub وShopify حتى تعرف أن الطلب صادر فعلًا منها ولم يُزوَّر؛ توليد كلمات مرور لمرة واحدة تعتمد على الوقت (TOTP/HOTP) للمصادقة الثنائية؛ وتوقيع رموز JWT بخوارزميات HS256/HS384/HS512.