مولّد HMAC

كيف يعمل

يثبت HMAC أمرين في آن واحد: أن الرسالة لم تتغير، وأن من أنشأها يملك السر المشترك. وهو ما يُوقَّع به webhooks وطلبات API وروابط التنزيل في معظم مواقع الويب.

يختلف عن التجزئة العادية في ما يهم

يمكن لأي شخص حساب SHA-256 لرسالة ما، ولذلك لا تثبت التجزئة المجردة شيئًا عن مُنشئها: غيّر الرسالة وأعد حساب التجزئة ولن يعرف أحد. أما HMAC فيدمج مفتاحًا سريًا في الحساب، فلا يمكن إعادة حسابه دون المفتاح. وهذا هو الغرض كله، ولهذا تستخدم توقيعات webhook الـ HMAC بدلًا من التجزئة.

التحقق بأمان

عند فحص HMAC على الخادم، قارنه بدالة ثابتة الزمن: crypto.timingSafeEqual في Node وhash_equals في PHP. العامل == العادي يعيد النتيجة بمجرد اختلاف بايتين، والزمن الذي يستغرقه يكشف مقدار ما كان صحيحًا من التوقيع، وهذا يكفي لتزوير توقيع إذا توفر الصبر. وهو هجوم حقيقي وليس نظريًا.

أي خوارزمية

SHA-256 ما لم يُحدَّد غيره. يتوفر SHA-1 لأن كثيرًا من واجهات API الأقدم ما زالت تتطلب HMAC-SHA-1، ولم يُكسر HMAC-SHA-1 بالطريقة التي كُسر بها SHA-1 العادي، لكن لا سبب لاختياره في أي استخدام جديد.

Hex أم Base64

الأمر يعتمد فقط على ما يتوقعه الطرف الآخر. Hex أطول بمرتين وأسهل قراءة، أما Base64 فأكثر إيجازًا وشائع في ترويسات HTTP. يُعرض التوقيع نفسه بالشكلين.

مفتاحك يبقى هنا

يُولَّد باستخدام Web Crypto API الخاصة بالمتصفح نفسه. لا يُرسل المفتاح ولا الرسالة إلى أي مكان، وهذه هي الطريقة المسؤولة الوحيدة لتقديم هذه الأداة: فأداة التوقيع التي ترفع سرّك تكون قد سلّمت ما يحميه هذا السر.