حول HMAC

مثال توضيحي لتنفيذ HMAC (رمز مصادقة الرسالة القائم على التجزئة) باستخدام Flask بلغة Python.

ما هو HMAC؟!

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

مثال

(1) طلب العميل إلى الخادم

• عندما يرسل العميل طلبًا إلى الخادم، يتضمن الرؤوس التالية:

• X-Authorization-Content-HMAC: تجزئة HMAC (URI الطلب بالكامل، الطابع الزمني الحالي لـ Unix (UTC)، ومفتاح HMAC السري)

• X-Authorization-Timestamp: الطابع الزمني الحالي لـ Unix (UTC) للعميل

(request)
GET /example/users?user=test&institutionID=999&signature=7e745d74b69b7f62e8e2 HTTP/1.1
Host: example.com
X-Authorization-Content-HMAC: 1c73495878ccea24af9dd281a4c883c40a3551ba799d30f4ad7d9afb6a60fbd4
X-Authorization-Timestamp: 1711662980

[ عملية طلب العميل ]

• يقوم العميل بتحضير الطلب وإرساله إلى الخادم.
• يقوم الخادم بالتحقق من صحة الطلب عن طريق التحقق من سلامة HMAC وصحة الطابع الزمني.
• إذا نجح التحقق، يقوم الخادم بمعالجة الطلب؛ وإلا، فإنه يرسل استجابة خطأ.

(2) استجابة الخادم للعميل

• عندما يستجيب الخادم لطلب صالح، يتضمن الرؤوس التالية:

• X-Response-Content-HMAC: تجزئة HMAC (نص الاستجابة بالكامل، الطابع الزمني الحالي لـ Unix (UTC)، ومفتاح HMAC السري)

• X-Response-Content-TimeStamp: الطابع الزمني الحالي لـ Unix (UTC)

(response)
HTTP/2 200 OK
Date: Fri, 29 Mar 2024 06:50:49 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 52
X-Response-Content-HMAC: 529c33aac3e33bf2a95d534f8b3ac61dee2ed79232d729e571dc669417a1a2ae
X-Response-Content-TimeStamp: 1711663027
Connection: close

{"result": "ok", "users": "test", "sub": 2840345654}

[ عملية الاستجابة ]

• يقوم الخادم بتحضير بيانات الاستجابة وإرسالها إلى العميل.
• (إضافي) إذا لزم الأمر، يمكن للعميل التحقق من سلامة HMAC لبيانات الاستجابة.
• إذا فشل التحقق، يرفض العميل بيانات الاستجابة.

Server response HMAC verification successful
--------------
Response timestamp: 2024-03-29T09:25:31
Current time: 2024-03-29T09:25:31
Time difference: 0

ملاحظات إضافية

• لا توجد قاعدة صارمة بشأن استخدام GET أو POST؛ ومع ذلك، يُفضل استخدام POST بشكل عام لأسباب أمنية. استخدام طلبات GET قد يؤدي إلى تسجيل جميع سلاسل الاستعلام في سجلات الوصول.
• استخدم دائمًا الطابع الزمني لـ Unix (UTC) لمعلومات الطابع الزمني لضمان الاتساق وتجنب المشكلات المتعلقة بالمنطقة الزمنية.
• يمكن أن يختلف نطاق حساب HMAC. بينما يتضمن عادةً تجزئة نص الاستجابة بالكامل، فإن التجزئة الانتقائية للبيانات ممكنة أيضًا، خاصةً عندما يكون نص الاستجابة كبيرًا.
• يجب أن يعتمد اختيار خوارزمية HMAC (مثل Hmac-SHA256، Hmac-SHA512) وطول المفتاح السري على متطلبات الأمان وأفضل الممارسات.

منع إعادة إرسال الطلبات

• يمكن للخادم تخزين الطلبات التي تمت معالجتها في الذاكرة (مثل Redis) وتجاهل الطلبات المتكررة خلال إطار زمني محدد لمنع هجمات إعادة الإرسال.
• بالإضافة إلى ذلك، يمكن للخادم تعزيز منع هجمات إعادة الإرسال من خلال مقارنة رأس الطابع الزمني (X-Authorization-Timestamp) الذي أرسله العميل في رأس الطلب مع وقت الخادم الحالي. إذا وقع الطابع الزمني خارج إطار زمني معين، يمكن للخادم تجاهل الطلب.

وأيضًا...

إذا وجدت هذا مفيدًا، فيرجى منح "نجمة" 🌟 لدعم المزيد من التحسينات.