اختبار المصادقة

لماذا يهم

المصادقة هي الباب الأمامي. وتُفرد قائمة OWASP Top 10 فئة خاصة لإخفاقات المصادقة (تعرفت عليها في درس OWASP Top 10)، وكثير من الاختراقات الحقيقية لا يحتاج إلى استغلال بارع (Exploit): كلمة مرور تسرّبت من موقع آخر، أو رابط إعادة تعيين لا تنتهي صلاحيته أبداً، أو تسجيل دخول لا يُبطئ المحاولات أبداً. والثمن هو الاستيلاء على الحساب، وما يتبعه من احتيال وفقدان للبيانات وأضرار تنظيمية.

وبالنسبة إلى المختبِر، هذا مجال مثمر: لمعظم الفحوص نتيجة متوقعة واضحة ينص عليها دليل منشور، NIST SP ⁦800-63B⁩ لكلمات المرور وحدود المحاولات، وأوراق OWASP المرجعية (Cheat Sheets) لمسارات إعادة التعيين وتعداد المستخدمين، ويكاد كله لا يحتاج إلا إلى متصفح وعميل HTTP وحسابين تجريبيين. أما ما يحتاج إليه فعلاً فهو الإذن: اختبر فقط الأنظمة التي تملكها أو لديك تصريح كتابي باختبارها، وبحسابات أُنشئت للاختبار.

محاولة تسجيل دخول واحدة، وأين يقع كل فحص

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

عند كل خطوة اطرح سؤالين: هل يُجرى الفحص أصلاً؟ وهل يسرّب شيئاً (رسالة مختلفة أو رمز حالة مختلفاً أو زمن استجابة مختلفاً) يخبر المهاجم بأكثر من مجرد «لا»؟

سياسة كلمة المرور: اختبر ما يطلبه NIST SP ⁦800-63B⁩

NIST SP ⁦800-63B⁩ هو الدليل الفدرالي الأمريكي للمصادقة، وتعتمده مؤسسات كثيرة خارج الحكومة أيضاً، وهو يُبطل عدة عادات قديمة. فإصداره الحالي، المراجعة ⁦4⁩ (⁦2025⁩)، يشترط ⁦15⁩ حرفاً على الأقل حين تكون كلمة المرور العامل الوحيد، ويسمح بحد أدنى قدره ⁦8⁩ أحرف حين لا تُستخدم إلا مع عامل ثانٍ؛ أما إصدار ⁦2017⁩ الذي بُنيت عليه منتجات كثيرة فكان يشترط ⁦8⁩ في الحالتين. ويُستحسن أن يسمح المتحقق (Verifier)، أي النظام الذي يفحص كلمة المرور، بـ⁦64⁩ حرفاً على الأقل، وأن يقبل كل حروف ASCII المطبوعة والمسافة وحروف Unicode؛ ويجب أن يتحقق من كلمة المرور كاملة دون اقتطاع أي جزء منها، وأن يقارن كل كلمة مرور جديدة بقائمة حظر (Blocklist) للقيم الشائعة أو المتوقعة أو المسرَّبة. وتمنع المراجعة ⁦4⁩ قواعد التركيب («حرف كبير ورقم ورمز») والتغيير الدوري الإجباري دون دليل على الاختراق، وقد كان إصدار ⁦2017⁩ ينصح بعدمهما أصلاً، ويمنع الإصداران كلاهما تلميحات كلمة المرور والأسئلة الأمنية. ويجب أن تعمل برامج إدارة كلمات المرور والتعبئة التلقائية، ويُستحسن السماح باللصق وإتاحة إظهار كلمة المرور أثناء الكتابة.

هذا هو مرجعك للحكم، بعد أن يحدد الفريق الإصدار والحالة اللذين يتبعهما المنتج. طبّق تحليل القيم الحدّية على الطول، مع عدّ كل نقطة ترميز (Code Point) في Unicode حرفاً واحداً كما ينص SP ⁦800-63B⁩: ⁦14⁩ و⁦15⁩ و⁦64⁩ و⁦65⁩ حرفاً لتسجيل دخول تحميه كلمة المرور وحدها، أو ⁦7⁩ و⁦8⁩ بدلاً من ⁦14⁩ و⁦15⁩ حين يكون العامل الثاني مطلوباً دائماً. وجرّب كلمة مرور بالعربية أو بالخط الديفاناغاري تحتوي مسافات، وأرسل قيماً يُفترض أن تحويها قائمة الحظر: كلمة مرور شائعة مُدّت إلى الحد الأدنى مثل Password1234567، واسم المنتج نفسه ممدوداً بالطريقة نفسها. ثم افحص التخزين: الملح (Salt) قيمة عشوائية تُخزَّن مع كل مستخدم كي تنتج كلمتا مرور متطابقتان تجزئتين مختلفتين، والخوارزمية البطيئة عمداً مثل Argon2 أو bcrypt أو PBKDF2 تجعل كل تخمين مكلفاً للمهاجم الذي يسرق الجدول. لذا يجب أن يحوي جدول المستخدمين في قاعدة بيانات الاختبار تجزئات مملّحة (Salted Hashes)، لا نصاً صريحاً أبداً، ويجب ألا تظهر كلمة المرور في السجلات أو عناوين URL.

#  Input (password is the only factor)   Expected
1  14 characters                         rejected: fewer than 15
2  15 characters                         accepted, and login works with it
3  64 characters                         accepted, and login works with it
4  65 characters                         rejected with a message, or accepted whole;
                                         never silently truncated
5  Arabic words with spaces              accepted (Unicode and the space)
6  Password1234567, product name padded  rejected: blocklist
7  paste, autofill, show password        all allowed
8  users table in a test database        salted slow hash, not the password

جرّبها: مولّد كلمات المرور جرّبها: عدّاد طول السلاسل النصية جرّبها: مولّد مجموعات بيانات Unicode

القفل والتقييد والعامل الثاني

القفل (Lockout) يعطّل تسجيل الدخول إلى الحساب بعد عدد من المحاولات الفاشلة، لمدة محددة أو حتى يفتحه أحد؛ أما التقييد (Throttling) فيبطئ المحاولات بدلاً من ذلك: تأخير يتزايد، أو CAPTCHA بعد بضع محاولات فاشلة، أو حد لكل حساب ولكل عنوان مصدر. ويشترط SP ⁦800-63B⁩ أن يحدّ المتحقق المحاولات الفاشلة المتتالية على الحساب الواحد بما لا يزيد على ⁦100⁩. والقفل الذي يستطيع أي شخص إطلاقه بكتابة بريد الضحية مع كلمات مرور خاطئة يمكن أن يُستخدم بحد ذاته لحجب الخدمة (Denial of Service)، لذا سجّل كيف يُرفع القفل وكم يدوم.

تضيف المصادقة متعددة العوامل فحصاً من فئة مختلفة، هو في الغالب شيء يملكه المستخدم: رمزاً لمرة واحدة من تطبيق مصادقة، أو مفتاح أمان، أو رمزاً يُرسل إلى الهاتف. اختبر هذه الخطوة كمصادقة صغيرة قائمة بذاتها: فالرمز المعتمد على الوقت (TOTP) يتغير كل ⁦30⁩ ثانية وفق الإعداد الافتراضي في RFC 6238، والرمز المكوّن من ⁦6⁩ أرقام له مليون قيمة فقط، فالخطوة تحتاج إلى حد محاولات خاص بها؛ كما يشترط SP ⁦800-63B⁩ قبول كل رمز لمرة واحدة فقط ما دام صالحاً. ويَعُدّ الدليل نفسه شبكة الهاتف قناة مقيّدة (Restricted)، فسجّل الرموز المرسلة عبر SMS مخاطرةً لا عيباً.

• احسب عدد كلمات المرور الخاطئة التي تُطلق التقييد أو القفل، بحساب تجريبي ثانٍ، وتحقق من أن العدّاد محفوظ على الخادم: فلا يُصفّره إعادة تحميل الصفحة ولا جلسة متصفح جديدة ولا مسح ملفات تعريف الارتباط (Cookies)، بل تسجيل دخول ناجح أو انتهاء مدة القفل الموثّقة فقط.
• كرّر المحاولات الفاشلة عبر كل منفذ دخول: نموذج الويب، وواجهة تطبيق الجوال، وصفحة إعادة التعيين، وخطوة MFA. يجب أن يسري الحد في كل مكان، ويجب ألا تكشف الرسالة وجود الحساب.
• في MFA: اطلب الصفحة أو الواجهة التالية لتسجيل الدخول مباشرةً بعد خطوة كلمة المرور دون رمز؛ وأرسل الرمز نفسه مرتين؛ وجرّب رمزاً انتهت صلاحيته قبل عدة خطوات زمنية، ويجب أن يُرفض متى تجاوز عمره النافذة التي يوثّقها الفريق (يوصي RFC 6238 بقبول خطوة زمنية سابقة واحدة على الأكثر لتأخر الشبكة، وبحدّ معيّن لفارق توقيت الساعة)؛ وتحقق من أن رموز الاسترداد تُستخدم مرة واحدة، وأن خيار «تذكّر هذا الجهاز» تنتهي صلاحيته، وأن إعادة تعيين كلمة المرور لا تتخطى العامل الثاني.

جرّبها: منشئ طلبات API

مثال تطبيقي: مسار إعادة التعيين وتعداد المستخدمين في تسجيل دخول متجر

لمتجر صفحة تسجيل دخول ونموذج تسجيل وصفحة «نسيت كلمة المرور». لديك حسابان تجريبيان، qa.one@example.com وqa.two@example.com، وعنوان مؤقت لم يُسجَّل قط. أرسل الطلب نفسه بعنوان معروف وآخر غير معروف إلى كل صفحة من الصفحات الثلاث، والتقط كل زوج بالوكيل الاعتراضي (Intercepting Proxy) من الدرس السابق أو بعميل HTTP، وقارن كل شيء في الاستجابتين: الرسالة، ورمز حالة HTTP، ووجهة إعادة التوجيه، وحجم المتن، والزمن المستغرق. وزوج تسجيل الدخول أدناه يفشل منذ أول مقارنة.

• تسجيل الدخول: ⁦401⁩ للعنوان المعروف و⁦404⁩ لغير المعروف هو تعداد مستخدمين. المتوقع: الحالة نفسها والرسالة نفسها ولا فرق ملحوظ في الزمن (فالحساب غير المعروف كثيراً ما يجيب أسرع لأن الخادم يتخطى مقارنة التجزئة البطيئة).
• التسجيل: «هذا البريد الإلكتروني مسجَّل مسبقاً» تعداد أيضاً. تقبله بعض الفرق لسهولة الاستخدام؛ والبديل أن تكون الإجابة دائماً «تحقق من بريدك» مع إرسال رسالة ترحيب أو رسالة «لديك حساب بالفعل». سجّل أي الخيارين اختاره المنتج.
• نسيت كلمة المرور: يجب أن تجيب الصفحة بالطريقة نفسها للعنوانين. ثم اختبر الرمز الذي ترسله بالبريد: عيّن كلمة مرور جديدة عبر الرابط ثم افتحه مرة أخرى (يجب أن يفشل لأن الرمز استُخدم)، وانتظر حتى تنتهي صلاحيته، وغيّر حرفاً واحداً من الرمز، واطلب إعادة تعيين مرتين لترى هل ما زال الرابط الأول يعمل. ويجب ألا تسرّب صفحة إعادة التعيين الرمز الموجود في عنوانها عبر ترويسة Referer، وهي الترويسة التي يرسل فيها المتصفح عنوان الصفحة التي صدر منها الطلب: فعليها أن تضبط Referrer-Policy: no-referrer كما توصي ورقة OWASP المرجعية لمسار «نسيت كلمة المرور» (Forgot Password Cheat Sheet)، كي لا يتلقى الرمز أي نص برمجي أو صورة أو رابط لطرف ثالث في تلك الصفحة.
• بعد إعادة تعيين ناجحة: يجب أن تتوقف كلمة المرور القديمة عن العمل، وأن تنتهي الجلسات التي فُتحت قبل إعادة التعيين (أو يُعرض على المستخدم خيار إنهائها على الأقل)، وأن يُبلَّغ المستخدم بأن كلمة المرور تغيّرت.

# Known test account, wrong password
POST /api/login HTTP/1.1
Host: staging.shop.example
Content-Type: application/json

{"email": "qa.one@example.com", "password": "Not-the-password-1"}

HTTP/1.1 401 Unauthorized
{"error": "Invalid e-mail or password"}

# Same request, an address that never registered
POST /api/login HTTP/1.1
Host: staging.shop.example
Content-Type: application/json

{"email": "never.registered@example.com", "password": "Not-the-password-1"}

HTTP/1.1 404 Not Found
{"error": "No account for this e-mail"}

جرّبها: مقارنة استجابات API جرّبها: بريد إلكتروني مؤقت

أسئلة شائعة

المراجع

• NIST SP 800-63B: Digital Identity Guidelines — Authentication and Lifecycle ManagementNIST · 2017متطلبات كلمات المرور وأدوات التوثيق: الطول أهم من قواعد التعقيد، وقوائم حظر لكلمات المرور المسرَّبة، وتحديد المعدل، وعدم فرض التغيير الدوري.
• OWASP Cheat Sheet Series: AuthenticationOWASP Foundationضوابط التوثيق: رسائل الخطأ العامة، والقفل والتقييد، والمصادقة متعددة العوامل، واستعادة بيانات الاعتماد.
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• OWASP Cheat Sheet Series: Password StorageOWASP Foundationكيف تُخزَّن كلمات المرور: Argon2id أو scrypt أو bcrypt مع الملح — لا MD5 ولا SHA-1 ولا تجزئة بلا ملح.