آلية التحقق من الهوية باستخدام نظام التحدي والاستجابة المملح

📅 آخر تحديث: ٤ أغسطس ٢٠٢٦
✍️ نُشر في: ٤ أغسطس ٢٠٢٦
الموسوعة الحرة

في علم التشفير، تُعدّ آلية المصادقة بالتحدي والاستجابة المُملّحة ( SCRAM ) مجموعة من آليات المصادقة الحديثة القائمة على كلمات المرور، والتي تُتيح التحقق من هوية المستخدم لدى الخادم. وبما أنها مُخصصة لطبقة المصادقة والأمان البسيطة (SASL)، يُمكن استخدامها لتسجيل الدخول باستخدام كلمات المرور إلى خدمات مثل LDAP و HTTP و SMTP و POP3 و IMAP و JMAP ( للبريد الإلكتروني )، و XMPP (للمحادثات)، و MongoDB و PostgreSQL (لقواعد البيانات). ويُعدّ دعمها إلزاميًا لبروتوكول XMPP. [ 1 ]

تحفيز

تريد أليس تسجيل الدخول إلى خادم بوب. وهي بحاجة إلى إثبات هويتها. ولحل مشكلة المصادقة هذه، اتفقت أليس وبوب على كلمة مرور، تعرفها أليس، ويعرف بوب كيفية التحقق منها.

الآن، تستطيع أليس إرسال كلمة مرورها عبر اتصال غير مشفر إلى بوب كنص عادي ليتحقق منها، لكن هذا سيجعل كلمة المرور متاحة لمالوري التي تتنصت على الخط. يمكن لأليس وبوب محاولة تجاوز هذا عن طريق تشفير الاتصال. مع ذلك، لا تعرف أليس ما إذا كان بوب هو من قام بالتشفير أم مالوري عبر هجوم الوسيط . لذلك، ترسل أليس نسخة مشفرة من كلمة مرورها، كما في CRAM-MD5 أو DIGEST-MD5 . ولأنها نسخة مشفرة، لا تحصل مالوري على كلمة المرور نفسها. ولأن النسخة المشفرة مُملّحة بتحدٍ، لا يمكن لمالوري استخدامها إلا لعملية تسجيل دخول واحدة. لكن أليس تريد إعطاء بوب بعض المعلومات السرية، وتريد التأكد من أنه بوب وليس مالوري.

لحل هذه المشكلة، سجّل بوب نفسه لدى جهة إصدار شهادات (CA) وقّعت شهادته. كان بإمكان أليس الاعتماد كليًا على نظام التوقيع هذا، لكنها تدرك وجود ثغرات فيه. ولضمان عدم وجود هجوم وسيط، أنشأ بوب دليلًا على معرفته بكلمة المرور (أو تجزئة مُملّحة لها)، وأدرج شهادته في هذا الدليل. يُسمى هذا الإدراج ربط القناة، حيث تُربط قناة التشفير الأدنى بقناة التطبيق الأعلى.

تمكنت أليس من التحقق من هوية بوب، وقام بوب بالتحقق من هوية أليس. وبذلك، يكون لديهما مصادقة متبادلة . كان بروتوكول DIGEST-MD5 يدعم المصادقة المتبادلة، ولكن غالبًا ما كان يُطبّق بشكل خاطئ. [ 2 ] [ 3 ]

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

سمع بوب عن اختراقات بيانات قواعد بيانات الخوادم، وقرر عدم تخزين كلمات مرور مستخدميه كنص عادي. سمع عن أنظمة تسجيل الدخول CRAM-MD5 وDIGEST-MD5، لكنه يعلم أنه لتقديم هذه الأنظمة لمستخدميه، سيضطر إلى تخزين كلمات مرور مشفرة بشكل ضعيف وغير مُملّحة. لم يُعجبه هذا الخيار، لذا اختار طلب كلمات المرور كنص عادي. بعد ذلك، يُمكنه تشفيرها باستخدام أنظمة تشفير آمنة مثل bcrypt أو scrypt أو PBKDF2 ، وإضافة الملح حسب رغبته. مع ذلك، سيظل بوب وأليس يواجهان المشاكل المذكورة سابقًا. لحل هذه المشكلة، يستخدمان SCRAM، حيث يُمكن لبوب تخزين كلمة المرور بتنسيق مُملّح باستخدام PBKDF2. أثناء تسجيل الدخول، يُرسل بوب إلى أليس قيمة الملح وعدد تكرارات خوارزمية PBKDF2، ثم تستخدم أليس هذه المعلومات لحساب كلمة المرور المُشفرة الموجودة في قاعدة بيانات بوب. تعتمد جميع الحسابات اللاحقة في نظام SCRAM على هذه القيمة التي يعرفها كلا المشاركين.

نظرة عامة على البروتوكول

على الرغم من أن جميع العملاء والخوادم مُلزمون بدعم خوارزمية التجزئة SHA-1 ، فإن SCRAM، على عكس CRAM-MD5 أو DIGEST-MD5 ، مستقل عن دالة التجزئة الأساسية . [ 4 ] يمكن استخدام أي دالة تجزئة مُعرّفة من قِبل IANA بدلاً منها. [ 5 ] كما ذُكر في قسم الدوافع، يستخدم SCRAM آلية PBKDF2 ، التي تُعزز مقاومته لهجمات القوة الغاشمة عند حدوث تسريب للبيانات على الخادم. لنفترض Hأن هي دالة التجزئة المُختارة، والتي يُحددها اسم الخوارزمية التي يُعلن عنها الخادم ويختارها العميل. على سبيل المثال، يستخدم 'SCRAM-SHA-1' خوارزمية SHA-1 كدالة تجزئة.

مفتاح مشتق قائم على كلمة المرور، أو كلمة مرور مملحة

يستخلص العميل مفتاحًا، أو كلمة مرور مُملّحة، من كلمة المرور، والملح، وعدد من التكرارات الحسابية على النحو التالي:

SaltedPassword = H(password, salt, iteration-count) = PBKDF2(HMAC, password, salt, iteration-count, output length of H).

رسائل

يُحدد RFC 5802 أربعة رسائل متتالية بين الخادم والعميل:

إعطاء الأولوية للعميل
تتكون رسالة العميل أولاً من رأس GS2 (يتضمن علامة ربط القناة، واسم اختياري لمعلومات التفويض)، والمطلوب username، و nonce العميل الذي تم إنشاؤه عشوائيًا c-nonce.
الخادم أولاً
يقوم الخادم بإلحاق قيمة nonce الخاصة به بهذا العميل s-nonce، ويضيفها إلى رسالة الخادم أولاً ، والتي تحتوي أيضًا على قيمة saltيستخدمها الخادم لتمليح تجزئة كلمة مرور المستخدم، وعدد التكرارات iteration-count.
العميل النهائي
بعد ذلك، يرسل العميل رسالة العميل النهائية التي تحتوي على ربط القناة ، ورأس GS2 وبيانات ربط القناة المشفرة في base64 ، وتسلسل nonce الخاص بالعميل والخادم، وإثبات العميل proof.
الخادم النهائي
تنتهي عملية الاتصال برسالة الخادم النهائية ، والتي تحتوي على توقيع الخادم verifier.

البراهين

يثبت كل من العميل والخادم للآخر أنهما يمتلكان نفس Authالمتغير، والذي يتكون من:

Auth = client-first-without-header + , + server-first + , + client-final-without-proof(مُدمجة بفواصل)

وبشكل أكثر تحديداً، يتخذ هذا الشكل التالي:

= n=username,r=c‑nonce,[extensions,]r=c‑nonce‖s‑nonce,s=salt,i=iteration‑count,[extensions,]c=base64(channel‑flag,[a=authzid],channel‑binding),r=c‑nonce‖s‑nonce[,extensions]

يتم حساب البراهين على النحو التالي:

ClientKey = HMAC(SaltedPassword, 'Client Key')
ServerKey = HMAC(SaltedPassword, 'Server Key')
ClientProof = p = ClientKey XOR HMAC(H(ClientKey), Auth)
ServerSignature = v = HMAC(ServerKey, Auth)

حيث يتم تطبيق عملية XOR على سلاسل البايت ذات الطول نفسه، وهي عبارة عن تجزئة عادية لـ . و هي سلاسل حرفية.H(ClientKey)ClientKey'Client Key''Server Key'

يمكن للخادم أن يُخوّل العميل عن طريق الحساب ClientKeyثم ClientProofالمقارنة H(ClientKey)مع القيمة المخزنة.

يمكن للعميل أن يُخوّل الخادم عن طريق الحساب والمقارنة ServerSignatureالمباشرة.

كلمة المرور المحفوظة

يخزن الخادم اسم المستخدم فقط، saltو iteration-count، و، و . ويتمتع الخادم بوصول مؤقت إلى هذه البيانات حيث يتم استعادتها من دليل العميل، بعد تشفيرها باستخدام .H(ClientKey)ServerKeyClientKeyH(ClientKey)

يحتاج العميل فقط إلى password.

ربط القناة

يصف مصطلح ربط القنوات استراتيجية منع هجمات الوسيط ، والتي تقوم على ربط طبقة التطبيق ، المسؤولة عن المصادقة المتبادلة، بطبقة أدنى (غالباً طبقة التشفير)، مما يضمن تطابق نقاط نهاية الاتصال في كلتا الطبقتين. يوجد اتجاهان رئيسيان لربط القنوات: ربط القنوات الفريد وربط القنوات بنقاط النهاية . يضمن الأول استخدام اتصال محدد، بينما يضمن الثاني تطابق نقاط النهاية.

توجد عدة أنواع لربط القنوات، ولكل نوع منها بادئة فريدة خاصة به . [ 6 ] يحدد كل نوع من أنواع ربط القنوات محتوى بيانات الربط ، والتي توفر معلومات فريدة عن القناة ونقاط النهاية. على سبيل المثال، بالنسبة لربط قناة tls-server-end-point ، فإن البادئة هي شهادة TLS الخاصة بالخادم. [ 7 ] من الأمثلة على استخدام ربط القنوات مع SCRAM كطبقة تطبيق، استخدام بروتوكول أمان طبقة النقل (TLS) كطبقة دنيا. يحمي TLS من التنصت السلبي، لأن الاتصال مشفر. مع ذلك، إذا لم يُصادق العميل على الخادم (مثلاً عن طريق التحقق من شهادة الخادم)، فلن يمنع ذلك هجمات الوسيط. لذا، تحتاج نقاط النهاية إلى تأكيد هوياتها لبعضها البعض، وهو ما يمكن أن يوفره SCRAM.

يحدد متغير SCRAM gs2-cbind-flag ما إذا كان العميل يدعم ربط القنوات أم لا، أو يعتقد أن الخادم لا يدعم ربط القنوات، ويحتوي c-bind-input على gs2-cbind-flag بالإضافة إلى البادئة الفريدة لربط القنوات وبيانات ربط القنوات نفسها.

ربط القنوات اختياري في SCRAM، والمتغير gs2-cbind-flag يمنع هجمات خفض المستوى .

عندما يدعم الخادم ربط القنوات، فإنه يضيف تسلسل الأحرف '-PLUS' إلى اسم خوارزمية SCRAM المعلن عنها.

نقاط القوة

  • تخزين كلمات المرور بشكل قوي: عند تطبيقها بالطريقة الصحيحة، يمكن للخادم تخزين كلمات المرور بتنسيق تجزئة متكرر مع إضافة ملح ، مما يجعل الهجمات غير المتصلة بالإنترنت أكثر صعوبة، ويقلل من تأثير اختراقات قواعد البيانات. [ 8 ]
  • البساطة: يُعدّ تطبيق SCRAM أسهل [ 9 ] من DIGEST-MD5. [ 10 ]
  • التوافق الدولي: يتطلب RFC استخدام UTF-8 لأسماء المستخدمين وكلمات المرور، على عكس CRAM-MD5. [ 9 ] [ 11 ]
  • بما أنه لا يُستخدم في عملية تسجيل الدخول سوى النسخة المُشفّرة والمُملّحة من كلمة المرور، وبما أن قيمة الملح على الخادم ثابتة، فإن العميل الذي يخزن كلمات المرور يستطيع تخزين النسخ المُشفّرة، وبالتالي لا يُعرّض كلمة المرور الأصلية للمهاجمين. ترتبط هذه النسخ المُشفّرة بخادم واحد، مما يُسهّل إعادة استخدام كلمات المرور. [ 12 ]

مراجع

  1. ↑ "بروتوكول المراسلة والحضور القابل للتوسيع: للسرية والمصادقة باستخدام كلمات المرور" . IETF . مارس 2011. تم الاطلاع عليه بتاريخ 4 أغسطس 2023 .
  2. ↑ كورت زيلينغا (19 مايو 2010). "SCRAM في LDAP: تحسين المصادقة القائمة على كلمة المرور" (ملف PDF) . مؤرشف من الأصل (ملف PDF) بتاريخ 4 أغسطس 2023. تم الاطلاع عليه بتاريخ 4 أغسطس 2023 .
  3. ↑ سيمون جوزيفسون (2011-02-06). "متاهة أمن شبكة جنو" (ملف PDF) . تم الاطلاع عليه بتاريخ 2023-08-04 .
  4. ↑ "آلية مصادقة التحدي والاستجابة المملحة (SCRAM) وآليات SASL وGSS-API: أسماء آليات SCRAM" . IETF. يوليو 2010. تم الاطلاع عليه بتاريخ 4 أغسطس 2023 .
  5. ↑ "أسماء الدوال النصية للتجزئة" . هيئة الأرقام المخصصة للإنترنت (IANA) . 16-12-2019 . تم الاطلاع عليه بتاريخ 04-08-2023 .
  6. ↑ "حول استخدام روابط القنوات لتأمين القنوات: إجراءات التسجيل" . IETF. نوفمبر 2007. تم الاطلاع عليه بتاريخ 4 أغسطس 2023 .
  7. ↑ "ربط القنوات لبروتوكول TLS: نوع ربط القناة 'tls-server-end-point'" . IETF. يوليو 2010. تم الاطلاع عليه بتاريخ 4 أغسطس 2023 .
  8. ↑ "SCRAM: بروتوكول جديد للتحقق من صحة كلمة المرور" . 19 مايو 2010. تم الاطلاع عليه بتاريخ 27 مايو 2024 .
  9. توبياس ماركمان ( 2 ديسمبر 2009). "احذف ملخص DIGEST-MD5!" . مؤرشف من الأصل بتاريخ 17 أبريل 2021. تم الاطلاع عليه بتاريخ 4 أغسطس 2023 .
  10. ↑ "RFC6331: نقل DIGEST-MD5 إلى الإصدار التاريخي" . IETF. يوليو 2011. تم الاطلاع عليه بتاريخ 4 أغسطس 2023 .
  11. ↑ "CRAM-MD5 to Historic" . IETF. نوفمبر 2008. تم الاطلاع عليه بتاريخ 4 أغسطس 2023 .
  12. ↑ توبياس ماركمان (2023-08-04). "نم قرير العين ليلاً وأنت مطمئن إلى أن كلمات مرورك آمنة" . مؤرشف من الأصل بتاريخ 2021-04-17.
  • RFC 5802 ، آلية مصادقة التحدي والاستجابة المملحة (SCRAM) وآليات SASL وGSS-API 
  • RFC 5803 ، مخطط بروتوكول الوصول إلى الدليل الخفيف (LDAP) لتخزين أسرار آلية مصادقة التحدي والاستجابة المملحة (SCRAM) 
  • RFC 6120 ، بروتوكول المراسلة والحضور القابل للتوسيع (XMPP): الأساسي 
  • RFC 6331 ، نقل DIGEST-MD5 إلى الإصدار التاريخي 
  • RFC 7677 ، SCRAM-SHA-256 و SCRAM-SHA-256-PLUS: آليات طبقة المصادقة والأمان البسيطة (SASL) 
  • RFC 7804 ، آلية مصادقة HTTP باستخدام التحدي والاستجابة مع إضافة الملح 
  • RFC 8600 ، استخدام بروتوكول المراسلة والحضور القابل للتوسيع (XMPP) لتبادل معلومات الأمان 
  • RFC 8621 ، بروتوكول تطبيقات JSON Meta (JMAP) للبريد الإلكتروني 
  • RFC 9051 ، بروتوكول الوصول إلى رسائل الإنترنت (IMAP) - الإصدار 4rev2 
  • RFC 9266 ، روابط القنوات لبروتوكول TLS 1.3 
  • draft-ietf-sasl-crammd5-to-historic-00 & draft-zeilenga-luis140219-crammd5-to-historic-00 , CRAM-MD5 to Historic
  • draft-melnikov-scram-sha-512 و SCRAM-SHA-512 و SCRAM-SHA-512-PLUS آليات طبقة المصادقة والأمان البسيطة (SASL)
  • draft-melnikov-scram-sha3-512 و SCRAM-SHA3-512 و SCRAM-SHA3-512-PLUS آليات طبقة المصادقة والأمان البسيطة (SASL)
  • draft-melnikov-scram-bis ، آلية المصادقة باستخدام التحدي والاستجابة المملحة (SCRAM) وآليات SASL وGSS-API
  • draft-ietf-kitten-scram-2fa ، امتدادات لبروتوكول الاستجابة للتحدي المملح (SCRAM) للمصادقة الثنائية
  • draft-melnikov-sasl2 ، طبقة المصادقة والأمان البسيطة القابلة للتوسيع (SASL)
  • حالة اللعب ، مزيد من التفاصيل حول دعم SCRAM SASL