مولّد HMAC

المصادقة، لا التشفير

لا يخفي HMAC أي شيء. إنه يجيب عن سؤال مختلف: هل أنتج هذه الرسالة بالضبط شخص يحمل السر المشترك، وهل تعرضت للتعديل منذ ذلك الحين؟ الناتج وسم ثابت الحجم ترسله مع الرسالة؛ يعيد المستقبل حسابه بنفس المفتاح ويقارن. الوسوم المتطابقة تعني أن الرسالة أصلية وسليمة. الوسوم غير المتطابقة تعني أنها ليست كذلك، ولا توجد طريقة لمعرفة أي الحالتين.

هذا يجعل HMAC المحرك الأساسي خلف توقيعات webhook وتوقيع طلبات API وملفات تعريف الارتباط الموقعة ورموز الجلسة. توقّع Stripe وGitHub ومعظم مزودي webhook حمولاتهم بهذه الطريقة لتتمكن من التحقق من أن الطلب جاء منهم فعلًا وليس من شخص خمّن رابط نقطة النهاية الخاصة بك.

لماذا لا نجزّئ المفتاح والرسالة معًا فقط

البناء الواضح — SHA256(key + message) — معطّل ضد تجزئات Merkle-Damgard مثل SHA-1 وSHA-256. تعالج هذه التجزئات البيانات في كتل وتحمل الحالة إلى الأمام، لذا يمكن لمهاجم يعرف ملخصًا صالحًا إلحاق بيانات وحساب ملخص صالح للرسالة الموسعة دون أن يتعلم المفتاح أبدًا. هذا هو هجوم تمديد الطول، وهو ليس نظريًا؛ فقد كسر واجهات برمجية حقيقية.

يغلق البناء المتداخل لـ HMAC، H(key XOR opad || H(key XOR ipad || message))، تلك الثغرة. مروران بمفتاحين مبطنين مختلفين يعنيان أن الملخص النهائي ليس الحالة الداخلية الخام لتجزئة فوق بيانات يتحكم فيها المهاجم. لهذا يجب أن تلجأ دائمًا إلى HMAC بدلاً من ابتكار تجزئة بمفتاح خاصة بك.

ملاحظات عملية

اختر SHA-256 ما لم يجبرك شيء خارجي على غيره. ما زال SHA-1 آمنًا داخل HMAC لأن البناء لا يعتمد على مقاومة التصادم، لكن لا يوجد سبب لأنظمة جديدة لاستخدامه وسيضع المراجعون علامة عليه. SHA-512 ليس أقوى بشكل ملموس لهذا الغرض وأحيانًا يكون أسرع على أجهزة 64-بت.

تفصيلان في التنفيذ أهم من اختيار التجزئة. أولاً، قارن الوسوم في وقت ثابت — تعود المقارنة النصية العادية مبكرًا عند أول بايت مختلف، مما يسرّب معلومات توقيت كافية لتزوير وسم بايتًا ببايت. ثانيًا، يجب أن تكون المفاتيح بايتات عشوائية بطول الملخص على الأقل، لا عبارة مرور يسهل تذكرها؛ مفاتيح HMAC ليست تجزئات كلمات مرور ولا تحصل على أي تمديد.