لا يرسل SRP كلمة المرور ضمن البروتوكول؛ وهذا لا يعني إلغاء كلمة المرور أو الحصانة من التصيد أو أن بيانات verifier غير ضارة.
مفاتيح المرور وSRP طريقتان مختلفتان للمصادقة. يستخدم مفتاح المرور زوجًا من المفاتيح، ويمكنه إزالة الحاجة إلى كلمة مرور. أما SRP فيظل قائمًا على كلمة مرور، لكنه عند تنفيذ البروتوكول تنفيذًا صحيحًا لا يرسل كلمة المرور نفسها إلى الخادم لإثبات معرفتها.
إذًا «الدخول دون إرسال كلمة مرور» ليس هو «الدخول دون امتلاك كلمة مرور». ينبغي أن يستند الاختيار بين هاتين الطريقتين إلى مخاطر التصيد وإدارة بيانات الاعتماد والاسترداد وجودة التنفيذ، لا إلى وصف عام مثل «المعرفة الصفرية».
ما الذي يغيّره مفتاح المرور؟
في المصادقة القائمة على مفاتيح المرور، تحتفظ الخدمة بالمفتاح العام، ويؤكد المستخدم الدخول من خلال تحكمه في المفتاح الخاص. ربط بيانات الاعتماد بالخدمة والأصل المعنيين جزء مهم من مقاومة هذه الطريقة للتصيد. شرح FIDO لمفاتيح المرور.
ليس من الضروري أن تُزامَن جميع مفاتيح المرور في السحابة. فبعضها مرتبط بجهاز أو مفتاح أمان، وبعضها ينتقل بين الأجهزة عبر مزود بيانات الاعتماد. يجب فحص نموذج الاسترداد وحماية المزامنة لدى المزود نفسه. ولا يمكن الاستنتاج من «المزامنة السحابية» وحدها أن الشركة تحتفظ بالمفاتيح بصيغة قابلة للقراءة.
أمان الجلسة بعد الدخول مسألة منفصلة أيضًا. لا يبطل مفتاح المرور تلقائيًا أثر البرمجيات الخبيثة على الجهاز أو سرقة جلسة صالحة.
ما الذي يمنحه SRP للخادم؟
ينتمي SRP إلى عائلة تبادل المفاتيح المصادَق عليه بكلمة مرور. يحتفظ الخادم ببيانات مثل الملح والمُتحقِّق، أو verifier، بدلًا من الاحتفاظ بكلمة المرور نفسها. ويتبادل الطرفان رسائل البروتوكول للتحقق من معرفة السر والمفتاح المشترك.
لكن verifier ليس بيانات غير ضارة. ينص القسم 3.3 من RFC 5054 صراحةً على أن المهاجم الذي يحصل على المُتحقِّق يستطيع إجراء هجوم قاموس لتخمين كلمة المرور. لذا فالقول إن «سرقة قاعدة البيانات لا تتيح أي تخمين دون اتصال» قول خاطئ.
تظل كلمة المرور القوية وحماية الخادم والمعلمات المناسبة والتحقق من المدخلات وضبط محاولات الدخول أمورًا ضرورية. كما لا يضمن SRP سلامة الصفحة التي تكتب فيها كلمة المرور؛ إذ يمكن لشيفرة خبيثة التقاطها قبل تشغيل البروتوكول.
مقارنة منصفة
| السؤال | مفتاح المرور | SRP |
|---|---|---|
| هل يحفظ المستخدم كلمة مرور للخدمة؟ | عادةً لا؛ لكن يلزم التحكم في بيانات الاعتماد | نعم، تعتمد الطريقة على معرفة كلمة المرور |
| ماذا تحتفظ به الخدمة لأجل الدخول؟ | المفتاح العام والمعلومات المرتبطة به | المُتحقِّق والمعلمات المرتبطة به |
| كيف تتحقق مقاومة التصيد؟ | ربط بيانات الاعتماد بالخدمة/الأصل في تصميم FIDO | عدم إرسال كلمة المرور ضمن البروتوكول لا يكفي لجعل واجهة إدخال مزيفة آمنة |
| هل السحابة إلزامية؟ | لا؛ توجد أيضًا خيارات مرتبطة بالجهاز | لا يتطلب البروتوكول بطبيعته مزود هوية خارجيًا، لكنه يحتاج إلى خدمة مصادقة |
| كيف يتم الاسترداد؟ | يعتمد على نوع بيانات الاعتماد والمزود | تحدده سياسة الحساب والمنتج، لا اسم SRP |
لا يمكن بناء ترتيب مطلق لجميع التطبيقات انطلاقًا من هذا الجدول. فقد يضعف مسار استرداد هش مزايا طريقة دخول قوية.
ما علاقة دخول الحساب بمفاتيح الدردشة؟
تُخبر المصادقةُ الخدمةَ بمن يُسمح له بالعمل. وتحدد مفاتيح تشفير الرسائل من يستطيع فتح المحتوى. قد يربط المنتج بين الأمرين، لكن يجب توثيق هذه العلاقة.
تصف وثائق أمان Livara استخدام SRP للدخول، وتعرض بصورة منفصلة حزمة استرداد v7 للهوية المشفّرة. تستعيد تلك الحزمة الهوية، لا سجل الدردشة. ولذلك لا تعني عبارة «كلمة مرور الدخول صحيحة» أن «جميع المفاتيح والرسائل القديمة قد عادت».
هذا المقال مقارنة مفاهيمية، وليس اختبارًا عمليًا لجميع طرق الدخول في Livara أو تصديقًا على تنفيذ RFC بعينه تنفيذًا دقيقًا في المنتج.
ما الأسئلة التي ينبغي طرحها عند الاختيار؟
- إذا فُقد الجهاز، فما وسيلة الدخول البديلة ومن يتحكم فيها؟
- هل طريقة الاسترداد أضعف من طريقة الدخول الأساسية؟
- كيف يمكن عرض الجلسات غير المعروفة وإبطالها؟
- هل يؤدي تغيير طريقة الدخول إلى تغيير مفاتيح الرسائل أو الأجهزة المرتبطة؟
- ما الحساب وما الحماية المستقلة اللازمان لمزامنة بيانات الاعتماد؟
الخلاصة: لا تصف مفتاح المرور بأنه بطبيعته «غير آمن لأنه سحابي»، ولا SRP بأنه «محصّن من الاختراق لأنه قائم على المعرفة الصفرية». حدود كل طريقة وسياسة الاسترداد في المنتج هما أساس المقارنة الموثوقة.
