1. المقدمة

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

2. المنهجية والنطاق

قمنا بتقييم ثلاثة عشر مدير كلمات مرور، بما في ذلك خمسة إضافات للمتصفح (مثل LastPass، Dashlane)، وستة مديرين مدمجين في المتصفح (مثل Chrome، Firefox)، واثنين من العملاء لسطح المكتب للمقارنة. غطى إطار التقييم ثلاث مراحل أساسية: تحليل عشوائية 147 مليون كلمة مرور تم توليدها، وتقييم أمان التخزين (التشفير، والتعامل مع البيانات الوصفية، والإعدادات الافتراضية)، واختبار نقاط ضعف الملء التلقائي ضد هجمات مثل اختطاف النقر و XSS.

3. تحليل توليد كلمات المرور

يُفصّل هذا القسم أول تحليل واسع النطاق لخوارزميات توليد كلمات المرور في مديري كلمات المرور.

3.1. إطار تقييم العشوائية

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

3.2. نتائج توزيع الأحرف

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

3.3. قابلية التعرض لهجمات التخمين

كانت النتيجة المهمة هي أن مجموعة فرعية من كلمات المرور المُولّدة – خاصة تلك الأقصر من 10 أحرف – كانت عرضة لهجمات القوة الغاشمة عبر الإنترنت. وُجد أن كلمات المرور الأقصر من 18 حرفًا قد تكون عرضة للهجمات دون اتصال بالإنترنت، بافتراض قدرات الأجهزة الحديثة.

4. أمان تخزين كلمات المرور

بتكرار وتوسيع العمل السابق لـ Li وآخرون، قمنا بتقييم كيفية تشفير كلمات المرور وتخزينها محليًا وفي السحابة.

4.1. التشفير وإدارة المفاتيح

بينما يستخدم معظم المديرين تشفيرًا قويًا (مثل AES-256)، اختلفت دواشت اشتقاق المفاتيح وآليات تخزين المفاتيح، حيث كانت بعض التطبيقات أضعف من غيرها.

4.2. حماية البيانات الوصفية

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

4.3. تحليل الإعدادات الافتراضية

كان لدى العديد من مديري كلمات المرور إعدادات افتراضية غير آمنة، مثل تمكين الملء التلقائي أو عدم طلب كلمة المرور الرئيسية عند إعادة تشغيل المتصفح، مما يزيد من سطح الهجوم.

5. نقاط ضعف آلية الملء التلقائي

يُعد الملء التلقائي، على الرغم من كونه مريحًا، مصدرًا كبيرًا لمتجهات الهجوم. اختبرنا ضد فئات الاستغلال المعروفة.

5.1. اختطاف النقر وإعادة توجيه واجهة المستخدم

وجدنا أن العديد من المديرين ظلوا عرضة لهجمات اختطاف النقر، حيث يضع موقع ضار عناصر غير مرئية فوق أزرار واجهة المستخدم المشروعة لخداع المستخدمين لتفعيل الملء التلقائي في حقل يتحكم فيه المهاجم.

5.2. مخاطر البرمجة النصية عبر المواقع (XSS)

إذا كان الموقع يحتوي على ثغرة XSS، فقد يتفاعل البرنامج النصي المحقون مع عناصر DOM الخاصة بمدير كلمات المرور لاستخراج بيانات الاعتماد، وهو خطر سلط عليه الضوء العمل السابق لـ Stock و Johns.

5.3. هجمات حقن الشبكة

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

6. النتائج والتحليل المقارن

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

عدد المديرين الذين تم تقييمهم

13

كلمات المرور المُولّدة والمُحلّلة

147M+

المديرين ذوي الثغرات الحرجة

4

7. التوصيات والاتجاهات المستقبلية

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

8. التحليل الأصلي وتعليقات الخبراء

الفكرة الأساسية: تقدم دراسة Oesch و Ruoti فحصًا واقعيًا صارمًا: فالأدوات المصممة لحل أزمة كلمات المرور هي نفسها عبارة عن ترقيع للثغرات. إن تركيز الصناعة على الراحة وزيادة الميزات قد أضعف، في عدة حالات، الوعود الأمنية الأساسية بشكل مباشر. إن اكتشاف أن كلمات المرور المُولّدة يمكن أن تكون ضعيفة هو أمر مدمر بشكل خاص – فهو يضرب في صميم القيمة المقترحة لمدير كلمات المرور.

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

نقاط القوة والضعف: تكمن قوة الدراسة في شموليتها وتكرار العمل السابق، مما يوفر رؤية طولية نادرة لتطور الأمان. إن مجموعة البيانات الضخمة المكونة من 147 مليون كلمة مرور مُولّدة للتحليل جديرة بالثناء. ومع ذلك، فإن التحليل به عيب شائع في العديد من التقييمات الأمنية: إنه إلى حد كبير اختبار وظيفي صندوق أسود. فهو يحدد ما الذي تعطل ولكنه يوفر رؤية أقل حول لماذا من منظور هندسة البرمجيات – هل كانت هذه العيوب بسبب مواعيد نهائية متسرعة، أو مواصفات غير مفهومة، أو نقص في مراجعة الأمان؟ علاوة على ذلك، بينما تشير إلى إرشادات الهوية الرقمية من NIST، فإن الغوص الأعمق في كيفية توافق (أو عدم توافق) هذه المديرين مع معايير مثل FIPS 140-3 أو متطلبات الأمان الموضحة في مقترحات IETF لـ تبادل المفاتيح المصادق عليها بكلمة المرور (PAKE) كان سيضيف وزنًا كبيرًا.

رؤى قابلة للتنفيذ: بالنسبة لفرق الأمان المؤسسية، تشكل هذه الورقة تفويضًا لفحص مديري كلمات المرور المعتمدين بدقة. الاعتماد على سمعة العلامة التجارية غير كافٍ. يجب أن تتضمن قوائم التحقق الخاصة بالشراء اختبارات محددة لعشوائية التوليد (مثل استخدام مجموعات اختبار موحدة مثل Dieharder أو STS من NIST)، وتشفير البيانات الوصفية، وسلوك الملء التلقائي تحت محاكاة الهجوم. بالنسبة للمطورين، الدرس هو إعطاء الأولوية للبساطة والإعدادات الافتراضية الآمنة. قد تكون آلية الملء التلقائي الأكثر أمانًا هي الأبسط: "النقر للتعمير" يدويًا والذي يتطلب إجراءً صريحًا وواعيًا من المستخدم، كما اقترح بحث من جامعة كاليفورنيا، بيركلي حول واجهات الموافقة الصريحة. لا يكمن المستقبل في محاولة جعل الملء التلقائي الذكي آمنًا تمامًا، بل في تصميم تفاعلات مستخدمية أقل تدخلاً وأكثر وضوحًا تحافظ على الإنسان في الحلقة لاتخاذ القرارات الأمنية الحرجة.

9. التفاصيل التقنية والإطار الرياضي

اعتمد تقييم عشوائية توليد كلمات المرور على حساب إنتروبيا شانون $H$ لكلمات المرور المُولّدة:

$H = -\sum_{i=1}^{n} P(x_i) \log_2 P(x_i)$

حيث $P(x_i)$ هو احتمال ظهور الحرف $x_i$ في موضع معين. بالنسبة لاختيار عشوائي حقيقي من مجموعة مكونة من $C$ حرفًا، فإن الإنتروبيا القصوى لكل حرف هي $\log_2(C)$. لمجموعة أحرف مكونة من 72 حرفًا (26 حرفًا صغيرًا + 26 حرفًا كبيرًا + 10 أرقام + 10 رموز)، فإن $H_{char}$ القصوى $\approx 6.17$ بت. وبالتالي فإن كلمة مرور مكونة من 10 أحرف لها حد أقصى نظري يبلغ حوالي 61.7 بت من الإنتروبيا.

وجدت الدراسة أن التحيزات في خوارزميات بعض المديرين قللت من الإنتروبيا الفعالة. تم تقييم قابلية التعرض للهجمات دون اتصال باستخدام معدل التكسير المقدر $R$ (عدد التجزئات في الثانية) ومساحة كلمات المرور $N$:

$\text{Time to crack} \approx \frac{N}{2 \times R}$

بافتراض معدل مرتفع يبلغ $10^{10}$ تجزئة/ثانية (ضمن نطاق مجموعات وحدات معالجة الرسومات الحديثة)، يمكن كسر كلمة مرور بأقل من حوالي 65 بت من الإنتروبيا ($N = 2^{65}$) في إطار زمني ممكن لمهاجم لديه الدافع.

10. النتائج التجريبية وتصور البيانات

الرسم البياني الرئيسي 1: تحيز توزيع الأحرف. رسم بياني شريطي يقارن التكرار الملاحظ مقابل المتوقع لأنواع الأحرف (كبيرة، صغيرة، أرقام، رموز) عبر مديري كلمات مرور متعددين. أظهر العديد من المديرين انحرافًا ذا دلالة إحصائية (p < 0.01) عن التوزيع المنتظم المتوقع، مع تمثيل زائد للأرقام في مواضع معينة.

الرسم البياني الرئيسي 2: الإنتروبيا مقابل طول كلمة المرور. مخطط مبعثر يظهر الإنتروبيا المقاسة لكل مدير لأطوال كلمات مرور مُهيأة مختلفة (8، 12، 16، 20 حرفًا). سيظهر المخطط أنه بينما تقترب معظم المديرين من خط الإنتروبيا النظري لكلمات المرور الأطول، فإن العديد منها يقع دون ذلك للأطوال الأقصر (8-12 حرفًا)، متجمعًا أسفل الخط، مما يشير إلى عشوائية أضعف.

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

11. إطار التحليل: مثال دراسة حالة

الحالة: تقييم أمان الملء التلقائي لـ "المدير X".

الخطوة 1 - رسم خرائط الميزات: توثيق كيفية تفعيل المدير X للملء التلقائي: هل يملأ تلقائيًا؟ هل يعرض قائمة منسدلة؟ ما هي سمات DOM التي يعتمد عليها (id، name، class، placeholder)؟

الخطوة 2 - نمذجة التهديدات: تطبيق نموذج STRIDE.

  • التزوير (Spoofing): هل يمكن لنموذج تسجيل دخول مزيف خداع المدير؟ (اختبر مع اختلافات `id="password"`).
  • التلاعب (Tampering): هل يمكن لجافا سكريبت تعديل البيانات المملوءة قبل الإرسال؟
  • الإنكار (Repudiation): هل يسجل المدير أحداث الملء التلقائي؟
  • الكشف عن المعلومات (Information Disclosure): هل يمكن لإطار iframe مخفي أو CSS مصمم (opacity:0.001) التسبب في الملء في حقل غير مرئي ثم استخراج البيانات منه؟
  • حرمان الخدمة (Denial of Service): هل يمكن للمواقع الضارة قفل ميزة الملء التلقائي؟
  • تصعيد الامتيازات (Elevation of Privilege): هل يعمل الملء التلقائي على صفحات واجهة المتصفح (chrome pages)؟ (لا ينبغي).

الخطوة 3 - تنفيذ الاختبار: إنشاء صفحة ويب اختبارية تحاول بشكل منهجي كل متجه تهديد. لاختطاف النقر، قم بإنشاء عناصر متداخلة شفافة. لـ XSS، قم بمحاكاة برنامج نصي يقرأ خاصية `value` للحقول المملوءة.

الخطوة 4 - التحليل والتقييم: قيّم كل ثغرة بناءً على الاحتمالية والتأثير (مثل استخدام تقييم DREAD). يحدد المجموع التراكمي التصنيف الأمني العام للملء التلقائي للمدير X.

يُبعد هذا النهج المنظم عن الاختبارات العشوائية ويضمن تغطية شاملة.

12. التطبيقات المستقبلية واتجاهات البحث

1. التكامل مع WebAuthn / مفاتيح المرور (Passkeys): المستقبل خالٍ من كلمات المرور. التطور التالي لمديري كلمات المرور هو أن يصبحوا وسطاء أساسيين لمفاتيح المرور (المبنية على واجهة برمجة تطبيقات مصادقة الويب W3C). هناك حاجة للبحث حول المزامنة الآمنة واستعادة المفاتيح الخاصة لمفاتيح المرور عبر الأجهزة، وهو تحدٍ سلط عليه تحالف FIDO الضوء.

2. الملء التلقائي الواعي بالسياق والقائم على المخاطر: بدلاً من منطق الملء/عدم الملء الثنائي، يمكن للمديرين المستقبليين استخدام التعلم الآلي لتقييم شرعية الصفحة (التحقق من عمر النطاق، شهادة SSL، درجات السمعة) وسياق المستخدم (وقت تسجيل الدخول المعتاد، الجهاز) لضبط سلوك الملء التلقائي، مما يتطلب مصادقة إضافية في السيناريوهات عالية المخاطر.

3. التحقق الرسمي والأجهزة الآمنة: يمكن التحقق رسميًا من المكونات الحرجة، خاصة مولد الأرقام العشوائية وروتينات التشفير/فك التشفير الأساسية، باستخدام أدوات مثل Coq أو Tamarin Prover. يمكن أن يرفع التكامل مع وحدات المنصة الموثوقة (TPMs) أو Secure Enclaves لتخزين المفاتيح مستوى الأمان للأهداف عالية القيمة.

4. البنى اللامركزية والمرتكزة على المستخدم: يمكن أن يخفف الانتقال من الخزائن السحابية المركزية إلى البروتوكولات اللامركزية (مثل تلك القائمة على الحساب الآمن متعدد الأطراف أو الخوادم الشخصية) من مخاطر اختراقات الموفرين على نطاق واسع. يتوافق هذا مع رؤية مشروع "Solid" الأوسع لحزم البيانات الشخصية.

13. المراجع

  1. Oesch, S., & Ruoti, S. (2020). That Was Then, This Is Now: A Security Evaluation of Password Generation, Storage, and Autofill in Browser-Based Password Managers. USENIX Security Symposium.
  2. Li, Z., He, W., Akhawe, D., & Song, D. (2014). The Emperor’s New Password Manager: Security Analysis of Web-based Password Managers. IEEE Symposium on Security and Privacy.
  3. Stock, B., & Johns, M. (2016). Protecting the Intranet Against "JavaScript Malware" and Related Attacks. IEEE EuroS&P.
  4. National Institute of Standards and Technology (NIST). (2017). Digital Identity Guidelines (SP 800-63B).
  5. FIDO Alliance. (2022). FIDO2: WebAuthn & CTAP Specifications. https://fidoalliance.org/fido2/
  6. Grassi, P., et al. (2017). NIST Special Publication 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management.
  7. Silver, D., Jana, S., Boneh, D., Chen, E., & Jackson, C. (2014). Password Managers: Attacks and Defenses. USENIX Security Symposium.
  8. Shannon, C. E. (1948). A Mathematical Theory of Communication. The Bell System Technical Journal.