SRP: بروتوكول كلمة المرور الآمنة عن بُعد

طوّر Tom Wu بروتوكول Secure Remote Password (SRP) في جامعة Stanford، ونُشر باعتباره RFC 2945 عام 2000، ثم عُرّف لاحقًا إصدار محسّن هو SRP-6a. يتيح SRP مصادقة متبادلة تستند إلى كلمة مرور مشتركة دون نقل كلمة المرور نفسها مطلقًا، حتى في صورة مشفّرة.

أثناء تسجيل SRP، يحسب العميل قيمة تحقق لكلمة المرور v = g^x mod N، حيث x = H(salt || password) وN عدد أولي آمن كبير. ويخزن الخادم الملح وقيمة التحقق v فقط. وحتى إذا اختُرقت قاعدة بيانات الخادم، فلا تكشف قيمة التحقق المخزنة كلمة المرور مباشرةً.

أثناء تسجيل الدخول عبر SRP، يجري العميل والخادم تبادلًا شبيهًا بتبادل Diffie-Hellman ينشئ مفتاح جلسة مشتركًا. وتتضمن العملية في كل جانب القيمة المشتقة من كلمة المرور، ولذلك لا يستطيع حساب مفتاح الجلسة الناتج بصورة صحيحة إلا من يعرف كلمة المرور وقيمة التحقق، على التوالي.

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

تُحسب قيمة التحقق على النحو التالي: v = g^x mod N، حيث x = H(salt || password)، وg مولّد، وN عدد أولي آمن بحجم 2048 بت أو أكبر. وتجعل مسألة اللوغاريتم المتقطع استرداد x من v غير ممكن عمليًا من الناحية الحسابية. ولا يمكن التحقق من كلمة المرور إلا بإكمال تبادل SRP الكامل بنجاح.

يعالج SRP-6a نقاط الضعف في تصميمَي SRP-3 وSRP-6 الأصليين من خلال تقديم معامل الضرب k = H(N, g) وتعديل ترتيب الحسابات لدى العميل والخادم. وتمنع هذه التغييرات بعض هجمات التخمين ذات الفائدتين، وتضمن ربط مساهمة الخادم بالبروتوكول في مرحلة مبكرة.

شهد SRP انتشارًا مهمًا في العالم الحقيقي. تستخدم Apple بروتوكول SRP في مزامنة iCloud Keychain، بما يتيح للأجهزة استرداد بيانات سلسلة المفاتيح دون كشف كلمة مرور الحساب لخوادم Apple. وقد استخدمت 1Password بروتوكول SRP في نموذج المصادقة لديها لمنع كشف بيانات الاعتماد على جانب الخادم.

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

يتطلب SRP موارد حسابية كبيرة، إذ يعتمد على الأسّية المعيارية باستخدام أعداد صحيحة كبيرة (2048 بت أو أكثر). كما يصعب تنفيذه بصورة صحيحة، إذ توجد مخاطر دقيقة كثيرة في التحقق من المعاملات أدت إلى ثغرات في التطبيقات. ويتطلب البروتوكول أيضًا قناة آمنة (TLS) لمنع التنصت السلبي على عملية التبادل نفسها.

يعرّف RFC 5054 مجموعات تشفير TLS-SRP التي تدمج المصادقة المتبادلة عبر SRP مباشرةً في مصافحة TLS. وهذا يلغي الحاجة إلى شهادات الخادم مع الاستمرار في توفير مصادقة متبادلة مشفّرة. ومع ذلك، ظل اعتماد TLS-SRP محدودًا عمليًا مع ظهور FIDO2 وOPAQUE كبدائل أكثر حداثة.

رغم أن SRP كان ابتكارًا رائدًا، فإن البدائل الحديثة مثل OPAQUE توفر ضمانات أمنية أقوى (مقاومة الحساب المسبق)، بينما يلغي FIDO2/passkeys كلمات المرور تمامًا. وبالنسبة إلى الأنظمة الجديدة، يُفضّل استخدام OPAQUE أو FIDO2، لكن يظل SRP خيارًا صالحًا للأنظمة التي تتطلب مصادقة متبادلة قائمة على كلمة المرور دون قابلية للتصيد الاحتيالي.

يخزن SRP قيمة تحقق لكلمة المرور (لا كلمة المرور نفسها)، وينشئ مفتاح جلسة مشتركًا عبر تبادل شبيه بـ DH، ويوفر مصادقة متبادلة تقاوم التصيد الاحتيالي. ويحسّن SRP-6a الإصدار الأصلي من خلال مقاومة هجمات التخمين. وتستخدم Apple iCloud Keychain و1Password بروتوكول SRP في الإنتاج. ويُعد OPAQUE وFIDO2 خلفَين حديثين للأنظمة الجديدة.