شرح Broken Authentication: لما نظام الدخول يسرب بياناتك زي المصفاة

🇺🇸EN🇸🇦AR
• 21 min read • #Broken Authentication, #Web Security, #OWASP, #Login, #Session Management

أي حد داس على "Forgot Password" قبل كده عارف إن الـ authentication أعقد بكتير مما يبان. ممكن تفتكر إن فكرة "username + password" بسيطة ومباشرة، بس بمجرد ما يتدخل العنصر البشري، النظام كله بيقلب بكارثة.

في المقال ده هنفصص كل خطأ شائع:

  • الـ credentials الافتراضية والـ passwords الضعيفة
  • حشو الـ credentials وتحطيم أسطورة الـ brute force
  • تثبيت الـ session، اختطافها، وكوارث الـ timeout
  • طرق تخطي الـ MFA والـ OTP اللي متكونة غلط
  • مسارات الـ password reset واسترجاع الحسابات غير الآمنة
  • صداع الـ authentication في الموبايل والـ API، سوء استخدام الـ JWT، وزلات الـ cookie

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

يعني إيه "Broken Authentication" أصلا؟

المصطلح ده جاي من OWASP Top 10 (رقم A02 في 2021)، بس هو بيشمل مجموعة مختلفة من الثغرات اللي التطبيق بيفشل فيها إنه يتأكد من هوية المستخدمين بشكل صحيح. الفشل ده ممكن يكون:

  • فشل في الـ Authentication: النظام بيسمح للمهاجمين يسجلوا دخول كأنهم شخص تاني من غير ما يعرفوا الـ credentials بتاعته.
  • فشل في إدارة الـ Session: المهاجم بيقدر يسرق أو يتوقع session token صالح وبيستخدمه عشان ينتحل شخصية مستخدم بعد ما يعمل login.
  • مشاكل في إدارة الـ Credential: الباسوردات متخزنة كـ plaintext، الـ hashing ضعيف، أو مكشوفة في الـ logs.

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

ليه لازم تهتم؟

لو الـ authentication مضروب، المهاجم بقى "جوه". هو مش محتاج يدور على ثغرة في المنتج بتاعك، هو بقى مستخدم شرعي واخد كل الصلاحيات. العواقب بتشمل:

  • الاستيلاء على الحساب (ATO): حساب البنك بتاعك، إيميلك، أو لوحة تحكم الـ SaaS بتاعتك.
  • التحرك الجانبي (Lateral movement): التنقل من مستخدم للتاني جوه شبكات الشركات.
  • إساءة استخدام الـ API: سرقة الـ client credentials، تخطي الـ rate limits، وسحب البيانات.
  • تسريب البيانات (Data breach): بمجرد الدخول، يقدر يسحب قاعدة البيانات، الـ S3 bucket، أو نظام الـ CRM.
  • السمعة، الغرامات، وخسارة العملاء: شوف اللي حصل في Yahoo و LinkedIn و Uber، وغيرها.

الـ Broken authentication هو أول سطر في قصة الاختراق الشامل. لما تصلحه، أنت بتقلل المخاطر بشكل جذري في كل أجزاء التطبيق بتاعك.

أشهر كوارث الـ Authentication (لوحة الشرف السوداء)

1. الـ Credentials الافتراضية أو المتثبتة في الكود

// Java example
String username = request.getParameter("user");
String password = request.getParameter("pass");
if(username.equals("admin") && password.equals("admin123")) {
    // login success
}

ملايين أجهزة الـ IoT بتتباع بـ admin:admin أو root:toor.

2. سياسات الـ Password الضعيفة

"على الأقل 6 حروف" أو "لازم تحتوي على رقم" دي مش سياسة، دي دعوة مفتوحة لاستخدام Password1.

3. مفيش Account Lockout أو Rate Limiting

app.post('/login', (req,res) => {
  const {u,p}=req.body;
  if(db.check(u,p)) res.send('ok');
  else res.send('fail');
});

الكود ده هيرد بكل سعادة على مليون تخمين في الثانية.

4. الـ Session IDs المتوقعة

استخدام MD5 للـ timestamp مع اسم المستخدم، أو الأسوأ، أرقام متسلسلة. المهاجمين بيقدروا يخمنوا أو يعملوا brute force عشان يلاقوا sessions صالحة.

5. تثبيت الـ Session (Session Fixation)

التطبيق بيقبل session ID بيبعته المهاجم، وبيربطه بمستخدم بعد ما يعمل login.

6. حشو الـ Credential (Credential Stuffing) وإعادة استخدام الباسورد

السبب رقم 1 في الاختراقات، المستخدمين بيستخدموا نفس الباسورد في 100 موقع مختلف.

7. مسارات "Forgot Password" المضروبة

  • استخدام الباسورد القديم كود التفعيل بدل ما تبعت كود عشوائي لمرة واحدة.
  • إرسال لينكات reset فيها token عبارة عن الـ user ID.
  • فضح إذا كان الإيميل ده متسجل في النظام ولا لأ.

8. الـ Multi-Factor Authentication (MFA) غير الآمن

  • إرسال الـ OTPs في رسائل SMS على قنوات غير مشفرة أو إعادة استخدامها.
  • تخزين الـ backup codes كـ plaintext جنب الباسوردات.
  • توليد الـ TOTP seeds بإنتروبي ضعيف.
  • تغيير إعدادات الـ MFA من غير ما تطلب re-authenticate.

9. تجسس الـ JWT وإعادة تشغيل الـ Token

  • تخطي الـ alg: none (الحركة الكلاسيكية).
  • توقيع الـ tokens بمفتاح HMAC مكشوف للعامة.
  • مفيش وقت انتهاء أو الـ exp محطوط على 9999999999.
  • تخزين الـ JWTs في الـ localStorage عشان ثغرة XSS تسرقهم بسهولة.

10. الـ API Keys والأسرار في الـ Source Code

  • رمي ملف .env في public repo على GitHub.
  • تثبيت aws_secret_key جوه تطبيقات الموبايل.
  • استخدام نفس المفتاح في بيئات تشغيل مختلفة.

11. فخاخ الـ Authentication في الموبايل

  • تخزين الـ tokens في NSUserDefaults أو LocalStorage.
  • عدم استخدام TLS في الـ token endpoints.
  • نظام الـ fallback الضعيف للبصمة لما الـ Touch ID/Face ID يفشل.

12. الإعدادات الغلط في الـ OAuth/OpenID

  • قائمة الـ Redirect URI بتسمح بـ wildcard زي https:// .example.com/ .
  • عدم التحقق من متغير الـ state.
  • الـ client secret محطوط جوه الـ SPAs.

13. ضعف المراقبة والـ Logging

لو مش بتسجل محاولات الدخول الفاشلة أو استخدام الـ token، مش هتاخد بالك لما حد يسيء استخدام الـ credentials.

(هنكرر القسم ده في المقال الفعلي مع تفاصيل أكتر وحس فكاهي).

اختراقات Broken Auth في العالم الحقيقي

LinkedIn (2012)

  • استخدموا SHA-1 hashes من غير salt.
  • 6.5 مليون باسورد اتسربت، وبعدها 117 مليون كمان.

Yahoo (2013-2014)

  • استرجاع الحسابات المسروقة عن طريق تزوير الـ cookies باستخدام MD5 hashing لملف user.dat.
  • 500 مليون حساب اتأثروا، أسوأ اختراق في التاريخ.

Equifax (2017)

  • ثغرة Apache Struts متعملهاش patch استخدمت لتنفيذ RCE.
  • بس اللوم على الـ auth: المهاجمين استخدموا brute-forced admin credentials على نظام منفصل عشان يسحبوا البيانات.

Uber (2016)

  • الـ credentials بتاعة مقاول على GitHub كانت متخزنة كـ plaintext في repo.
  • المهاجمين دخلوا على الـ AWS console وحملوا الـ backups.

Okta (2023)

  • إرهاق الـ MFA (MFA fatigue) وهجمات تصيد (phishing) في هجمات هندسة اجتماعية.
  • اختطاف session بارز جدا لتخطي حمايات الـ admin.

(هتوسع التفاصيل وتضيف أمثلة أكتر، مع تعليقات لاذعة).

إزاي المهاجمين بيستغلوا ثغرات الـ Authentication

  • Password spraying: تجربة Winter2026! على حسابات كتير عشان يتجنبوا الـ lockouts.
  • Session side-jacking: شمشم الـ cookies على شبكات Wi-Fi مش متأمنة.
  • Cross-Site Login Forgery (CSLF): خداع المستخدم إنه يبعت فورم الدخول عشان يسرب الـ credentials عن طريق الـ Referer.
  • MFA fatigue: إرسال push notifications كتير جدا لحد ما المستخدم يوافق بالغلط.
  • التصيد باستخدام دومينات مميزة (Phishing): دومين زي g00gle.com/login بيصطاد الـ OAuth tokens.

قسم الأكواد الضخم: أمثلة لمسارات مضروبة ومتصلحة

(هنا هنحط أمثلة أكواد كاملة لكل لغة زي المقالات اللي فاتت، بتوضح الدخول الساذج، الهجوم، والنسخ المتصلحة).

أدوات واختبارات لنقاط ضعف الـ Authentication

  • Burp Intruder مع قوائم كلمات (wordlists) للـ password spraying.
  • acyort عشان تلاقي الـ default creds على أجهزة الـ IoT.
  • hydra و medusa للـ brute force، استخدمهم بمسؤولية!
  • password.tester لتحليل تكرار الباسوردات المختارة.
  • أدوات OWASP Credential Stuffing زي (CF-Injector).
  • الفحص المستمر بـ Gitleaks أو git-secrets عشان تلاقي المفاتيح المكشوفة.

الدفاع: قفل أبوابك كويس

  1. سياسات باسورد قوية: الطول أهم من التعقيد، وامنع الباسوردات المعروفة إنها سيئة.
  2. Rate limit و lockout: 5 محاولات في الدقيقة، تأخير متصاعد (exponential backoff)، و CAPTCHAs.
  3. Password hashing: استخدم Argon2id أو bcrypt مع تكلفة (cost) عالية كفاية.
  4. Multi-Factor Authentication: فضل الـ TOTP، FIDO2، والـ hardware keys.
  5. إدارة آمنة للـ session: استخدم tokens عشوائية مشفرة، غيرها مع كل login، حط HttpOnly و Secure flags، وحدد وقت انتهاء للـ token.
  6. منع الـ MFA token replay: اطلب أكواد تستخدم مرة واحدة والغيها بعد الاستخدام.
  7. أفضل ممارسات الـ Password reset: لينكات عشوائية لمرة واحدة، وقت انتهاء قصير، تأكيد ملكية الإيميل من غير ما تكشف عن وجود الحساب.
  8. APIs: استخدم OAuth2 مع PKCE، غير الـ client secrets باستمرار، وراجع الـ scopes.
  9. المراقبة: سجل كل محاولات الـ auth واعمل تنبيهات على الحركات الغريبة (سفر مستحيل، طفرات في الموقع الجغرافي، أجهزة جديدة).
  10. التوعية: علم المستخدمين عن الـ phishing، الـ password managers، وطلبات الموافقة المشبوهة للـ MFA.

قسم الأكواد الضخم: الـ Authentication المضروب مقابل المتصلح

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

PHP - فورم دخول ساذج

// vulnerable.php
$username = $_POST['user'];
$password = $_POST['pass'];

// NEVER do this:
$sql = "SELECT * FROM users WHERE username='$username' AND password='$password'";
$res = $db->query($sql);
if ($res->num_rows) {
    $_SESSION['user'] = $username; // session fixation risk
    echo "Welcome $username";
}

ممكن المهاجم يعمل SQLi على الـ query، يخمن باسوردات ضعيفة، أو ينادي الـ endpoint دي بشكل متكرر بـ credentials مختلفة عشان مفيش rate limit.

النسخة المتصلحة:

// secure.php
$username = $_POST['user'];
$password = $_POST['pass'];

// prepared statement + secure hash
$stmt = $db->prepare('SELECT password_hash FROM users WHERE username=?');
$stmt->bind_param('s', $username);
$stmt->execute();
$stmt->bind_result($hash);
if ($stmt->fetch() && password_verify($password, $hash)) {
    session_regenerate_id(true); // prevent fixation
    $_SESSION['user'] = $username;
    echo "Welcome $username";
} else {
    http_response_code(401);
    echo "Invalid credentials";
}

أهم الإصلاحات: parameterized query، باسوردات معمولها hashing، تدوير الـ session، ومفيش رسائل خطأ تفصيلية.

Python - Flask مع Rate Limit

@app.route('/login', methods=['POST'])
def login():
    username = request.form['user']
    password = request.form['pass']
    user = User.query.filter_by(username=username).first()
    if user and user.check_password(password):
        login_user(user)
        return 'ok'
    else:
        return 'fail', 401

ضيف Flask-Limiter عشان تقلل المحاولات:

limiter = Limiter(app, key_func=get_remote_address, default_limits=["5 per minute"])

@app.route('/login', methods=['POST'])
@limiter.limit("5/minute")
def login():
    # same as above

Java - إعدادات Spring Security

إعدادات سيئة (insecure memory، صفحة login افتراضية):

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests().anyRequest().authenticated()
        .and().formLogin(); // default login page, no CSRF protection
}

إعدادات أحسن:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .csrf().and()
        .authorizeRequests()
            .antMatchers("/public/**").permitAll()
            .anyRequest().authenticated()
        .and()
        .formLogin()
            .loginPage("/login")
            .permitAll()
            .failureUrl("/login?error")
        .and()
        .logout()
            .invalidateHttpSession(true)
            .deleteCookies("JSESSIONID");
}

Node.js - Express + bcrypt + helmet

app.post('/login', async (req, res) => {
  const { user, pass } = req.body;
  const u = await User.findOne({ username: user });
  if (u && await bcrypt.compare(pass, u.passwordHash)) {
    req.session.regenerate(err => {
      if (err) return res.status(500).end();
      req.session.user = u.id;
      res.send('ok');
    });
  } else {
    res.status(401).send('Invalid');
  }
});

مكتبة Helmet بتحط secure headers، و bcrypt بيعمل hashing للباسوردات، وتجديد الـ session بيمنع الـ fixation.

أدوات واختبارات لنقاط ضعف الـ Authentication

  • Burp Suite Intruder مع قوائم كلمات للـ password spraying، شغله في وضع الـ fault tolerant.
  • Hydra/Medusa للـ brute force لما يكون معاك تصريح، وتجنب الإساءة.
  • OWASP ZAP فيه authentication scanner بيعمل fuzzing لفورمات الدخول.
  • إضافة Cloudflare Burp لمحاكاة مسارات الدخول لاختبارات تخطي الـ rate limit.
  • Acyort و ncrack لفحص الـ default credentials على SMB، SSH، وقواعد البيانات.
  • قوائم تكرار الباسوردات زي rockyou.txt وقائمة HaveIBeenPwned للـ credential stuffing.
  • MultiBrute لعمليات حسابية متعددة المسارات لاكتشاف الحسابات (account enumeration).
  • Gitleaks أو git-secrets لاكتشاف الأسرار المتسربة في الـ repos.
  • أدوات شم الـ TOTP زي oathtool عشان تعمل brute-force لأكواد الـ 6 أرقام لو قدرت تعترض الـ seed.

قائمة الاختبار اليدوي:

  1. جرب الدخول بـ admin / admin وأي credentials تانية شائعة.
  2. جرب 1000 تخمين متتالي وراقب أوقات الرد والـ ratelimit.
  3. حلل قيم الـ session cookie عشان تشوف لو كانت متوقعة.
  4. افحص الـ Forgot Password عشان تدور على تسريب أسماء المستخدمين (username enumeration).
  5. جرب تدخل بباسوردات مسربة قبل كده من اختراقات معروفة (استخدم القوائم من HIBP).
  6. اختبر المسارات البديلة للـ MFA: زي الـ SMS، الإيميل، والـ backup codes.
  7. فتش في ترافيك تطبيقات الموبايل عن API keys أو tokens مبعوتة كـ plaintext.

الفحوصات الآلية المفروض تشتغل كل أسبوع على كل endpoints الـ authentication، بما فيها مسارات الـ API اللي تحت /api/* ومسارات الـ OAuth.

الدفاع: قفل أبوابك كويس

  1. Hashing قوي: دي تعتبر الأهم. استخدم Argon2id مع تكلفة memory عالية، أو scrypt/bcrypt مع work factor.
  2. سياسات الباسورد: افرض حد أدنى للطول (12+)، امنع أكتر 20 ألف باسورد مسربة (استخدم API بتاع HIBP)، وشجع استخدام الـ passphrases.
  3. Rate limiting و lockout: ادمج الـ throttling على مستوى الـ IP وعلى مستوى الحساب، استخدم التأخير المتصاعد وبلغ المستخدم بعد تكرار الفشل.
  4. Account lockout soft-fail: اقفل الحساب لمدة 15 دقيقة بعد 5 محاولات فاشلة، بس متكشفش ثغرة الـ lockout PUT للمهاجم (رجع رسالة عامة).
  5. إدارة الـ Session: ولد tokens عشوائية آمنة، دور الـ session ID مع كل دخول/خروج، حط SameSite=Strict و Secure و HttpOnly.
  6. انتهاء الـ Session: 15 دقيقة خمول، 24 ساعة كحد أقصى مطلق، فكر تطلب re-authentication للأفعال الحساسة (تغيير الباسورد، تحويل الفلوس).
  7. Multi-factor authentication: إلزامي للحسابات ذات الصلاحيات العالية، استخدم طرق مقاومة للـ phishing (FIDO2، مفاتيح الأجهزة). للـ TOTP، اتأكد إن الأسرار عشوائية وفريدة لكل مستخدم.
  8. Password reset آمن: ولد tokens طويلة (128-bit) وعشوائية تتخزن كـ hash على السيرفر، ابعت لينك على الإيميل بينتهي خلال 15 دقيقة، اعمل rate-limit للطلبات، واطلب إدخال الباسورد الحالية لو المستخدم عامل login.
  9. إدارة الأسرار: إياك تخزن الـ credentials في الكود، استخدم الخزائن (HashiCorp، AWS Secrets Manager) مع سياسات التدوير (rotation).
  10. المراقبة والتنبيه: اكتشف السفر المستحيل (impossible travel)، محاولات الدخول السريعة على حسابات كتير، واستخدم SIEM/UEBA للإبلاغ عن الحركات الغريبة.
  11. التخزين عند العميل (Client-side): إياك تخزن الـ tokens في localStorage، فضل الـ cookies اللي معاها الـ flags الصح أو واجهات الـ keychain الآمنة بتاعة المنصة.
  12. أمن الـ OAuth/OIDC: حدد قائمة صارمة للـ redirect URIs، اتحقق من متغير الـ state، دور الـ client secrets، واستخدم PKCE للـ public clients.
  13. الـ Logs: سجل كل حدث للـ auth (دخول ناجح/فاشل، تغيير باسورد، طلب reset) مع الـ IP المصدر، واحتفظ بيهم لمدة 90 يوم أو أكتر.

خلي بالك: السكيورتي لازم تراعي سهولة الاستخدام. وفر password managers، اسمح بالـ passkeys، وإياك تجبر المستخدمين يحفظوا نصوص عشوائية.

إرشادات للمطورين

  • دايما اسأل في مراجعة الكود: "هل المهاجم يقدر يخمن أو يعيد استخدام الـ credentials دي؟".
  • اصنع نماذج تهديد (threat models) لكل endpoint للـ auth.
  • اعتمد على أدوات الـ library/framework كل ما تقدر (زي Spring Security، ASP.NET Identity) بدل ما تكتب كودك من الصفر.
  • خلي كود الـ authentication صغير ومختبر كويس، التعقيد بيخبي وراه ثغرات.
  • اكتب اختبارات آلية (automated tests) تحاكي السرقة (زي replay tokens، brute force) واتأكد من الدفاعات.

أساطير شائعة

  • "سياسة الباسورد بتاعتنا قوية عشان بنطلب حروف خاصة." الغلط: الطول هو الملك.
  • "المفروض نقفل الحسابات بشكل دائم بعد 3 محاولات فاشلة." الغلط: القفل الدائم ده طريقة لعمل denial-of-service.
  • "الـ HTTPS كفاية، مش محتاجين rate limits." الغلط: الـ HTTPS بيشفر النقل بس مبيمنعش التخمين.
  • "الـ MFA بيحل كل حاجة." الغلط: ممكن تخطي الـ MFA عن طريق الإرهاق (fatigue)، أو تبديل الشريحة (SIM swap)، أو الـ backup codes المسروقة.
  • "إحنا بنعمل authenticate للمستخدم مرة واحدة في الـ session." الغلط: الـ sessions الطويلة بتزود الخطر، اطلب re-auth للأفعال الحساسة.

أفكار أخيرة

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

المرة الجاية اللي تدخل فيها موقع ويطلبوا منك "اسم عيلة والدتك" أو يبعتولك كود من 4 أرقام في رسالة، افتكر: هما بيطلبوا منك تأمن بياناتك عند حد غالبا مقراش المقال ده. اكتب كود يستحق الثقة دي.

جدول زمني لأكبر اختراقات الـ Authentication والـ CVEs

YearIncident/CVEImpact
2012LinkedIn hashed passwords stolen6.5M -> 117M follow-up dump
2013Yahoo session cookie forging500M accounts
2014Heartland Payment Systems – credentials in malware
2016OWASP releases Credential Stuffing Prevention Guide
2017Equifax login admin brute-force used for data exfil
2018Ticketmaster breach via inserted JS capturing creds
2021Microsoft Exchange user auth CVEs levered for ATO
2022Uber phishing MFA bypass, 2FA nagging used
2023Okta MFA fatigue campaign used for customer ATO

أسئلة متكررة (FAQ)

س: ليه منجبرش كل الناس تستخدم 2FA؟ ج: في عالم مثالي المفروض تعمل كده، بس الـ 2FA بيضيف صعوبة وتكاليف دعم. للتطبيقات اللي مخاطرها قليلة ده مجرد تنازل، قدمه كخيار وشجع المستخدمين عليه (مثلا: مميزات مجانية). لكن الحسابات عالية القيمة لازم تطلبه.

س: هل الـ passkeys (WebAuthn) بجد أحسن من الـ TOTP؟ ج: أيوة. هي مقاومة للـ phishing ومربوطة بالمصدر (origin). أكواد الـ TOTP ممكن تتنقل عن طريق هجوم man-in-the-middle. الـ Passkeys هي المستقبل، ابدأ ادعمها من دلوقتي.

س: هل المفروض أسمح للمستخدمين يختاروا الـ username بتاعهم؟ ج: أكيد، بس اتعامل مع الـ usernames على إنها معرفات عامة (public identifiers). اسمح بالـ enumeration بس لو ده مش هيسرب حالة حساسة للمستخدم. استخدم rate limit ورسائل خطأ عامة عشان تخفف من الـ scanning.

س: هل الـ SMS OTP مات تماما؟ ج: هو ضعيف (عشان الـ SIM swap والاعتراض) بس لسه أحسن من مفيش في بعض السياقات. متعتمدش عليه لوحده في الاحتياجات عالية الأمان.

س: إيه أحسن طريقة أتعامل بيها مع ميزة "remember me"؟ ج: استخدم refresh tokens بتعيش فترة طويلة ومتخزنة بأمان (مش cookies)، اربطها ببصمة الجهاز، والغيها لما المستخدم يعمل logout أو بعد فترة خمول. وفر للمستخدم لوحة تحكم يشوف منها الـ sessions الشغالة ويقدر يلغيها.

تمارين للقراء

  1. شغل تحليل لقوة الباسوردات على قاعدة بيانات المستخدمين في شركتك (بدون أسماء). إيه هو توزيع أطوال الباسوردات؟
  2. جهز تطبيق صغير بـ 2FA وحاول تتخطاه باستخدام بروكسي وأداة phishing.
  3. ابني rate limiter بسيط باستخدام Redis أو in-memory store يمنع أكتر من 5 محاولات دخول في الدقيقة لكل IP.
  4. راجع public GitHub repo عشان تدور على credentials مسربة باستخدام git-secrets واتدرب على الإبلاغ عن أي حاجة تلاقيها بمسؤولية.
  5. نفذ لاب لـ "password reset race condition" واثبت إزاي طلبات الـ reset المتزامنة ممكن تخلي حد غريب يغير الباسورد.

أفضل الممارسات لكل لغة

  • Java - اعتمد على Spring Security، وتجنب تكتب منطق الـ authentication بتاعك. استخدم PasswordEncoder للـ hashing وشغل HttpSessionEventPublisher عشان تراقب الـ sessions.
  • Python - استخدم werkzeug.security أو نظام الـ auth بتاع Django، ومتخزنش plaintext في الـ migrations. اقفل الحسابات في Redis عشان تحدد المحاولات.
  • PHP - استخدم password_hash() و password_verify()، وتجنب crypt() مع الأملاح اليدوية (manual salts). حط session.cookie_httponly = 1 و session.cookie_samesite = Strict.
  • Node - استخدم passport.js أو express-session مع store آمن (Redis مع TLS). اعمل regenerate للـ session ID وقت الـ login.
  • Ruby - أداة Devise قوية جدا، اتأكد إن config.remember_for و config.expire_all_remember_me_on_sign_out مظبوطين صح.
  • C#/.NET - استخدم ASP.NET Identity، خزن الأسرار في Azure Key Vault، واستخدم AddIdentity مع خيارات الـ lockout.

شكر وتقدير

شكرا لـ: مجتمع OWASP، و Troy Hunt (HIBP)، و Brian Krebs، والباحثين الكتير اللي بينشروا تحليلات للاختراقات. إلهام المقال ده مسروق بحرية من بوستاتهم.

أفكار أخيرة جدا (أيوة بجد)

الـ Authentication مش حاجة مبهرة، بس هو الجزء من تطبيقك اللي بيحضر كل الحفلات. خليه قوي، راقبه بشراسة، وإياك تسلمه لـ third-party JS عشوائي. لو شاكك: كود أقل، مكتبات أكتر، logging أكتر.

نهاية المقال، روح بقى بجد اختبر شوية لوج إن.

ملحق إضافي: نماذج السياسات وملاحظات الاجتماعات

استخدم النص اللي تحت ده عشان توحد رؤية الإدارة والمطورين بسرعة.

نموذج لسياسة الأمان

# Authentication Security Policy

1. All authentication mechanisms must be reviewed by security before deployment.
2. Minimum password length is 12 characters; password blacklists must be enforced.
3. Rate limiting of authentication endpoints is required (5 attempts per minute per account).
4. MFA is mandatory for privileged accounts and strongly encouraged for all users.
5. Session tokens must be cryptographically random, rotated on login/logout, and invalidated on password change.
6. Password reset links expire no later than 15 minutes and are single-use.
7. API keys/secrets must not be stored in source code; use centralized vaults.
8. Regular audits (monthly) of auth-related dependencies for CVEs.

Violations of this policy are treated as security incidents.

بنود جدول أعمال الاجتماع

  • ملخص سريع لمخاطر الـ broken authentication.
  • مراجعة الحالة الحالية للـ login endpoints بتاعتنا (الجرد).
  • تحديد أي إعدادات افتراضية أو سياسات ضعيفة موجودة.
  • التخطيط للمراجعات ومراجعة الكود: تحديد المسؤوليات.
  • تحديد حدود المراقبة وقواعد التنبيهات.
  • جدولة توعية وتدريب المستخدمين.

نقط نقاش للإدارة

  1. الـ Broken authentication بيؤدي مباشرة للاستيلاء على الحسابات وتسريب البيانات.
  2. تنفيذ الضوابط الصح بيقلل تكاليف الاستجابة للحوادث بشكل ضخم.
  3. أطر الامتثال (زي PCI، GDPR) بتغطي ضوابط الـ authentication بشكل صريح.
  4. المقاييس: راقب معدل اعتماد الـ MFA، محاولات الدخول الفاشلة، وحجم طلبات الـ password reset.
  5. الديون الأمنية (Security debt) في الـ auth بتبقى واضحة جدا للمهاجمين من خلال الفحوصات الآلية.

إضافة: مؤتمرات ومحادثات (2024-2026)

  • RSA Conference 2024 - محادثة "Stop Guessing Passwords" لـ Erin Hoffman.
  • Black Hat USA 2025 - ورشة عمل "Hands-On Broken Auth".
  • OWASP Live 2025 - حلقة نقاش "Beyond Passwords: The Future of Authentication".
  • DEF CON 34 - مسار مسابقات CTF للـ authentication.
  • AppSec EU 2026 - محادثة "MFA Bypass Techniques: Lessons Learned".

قائمة CVE ضخمة عشان الـ SEO

| CVE ID | Year | Product | Summary |
|--------|------|---------|---------|
| CVE-2012-5050 | 2012 | Magento | Weak password hashing algorithm used |
| CVE-2013-0141 | 2013 | OpenSSH | Password authentication bypass vulner. |
| CVE-2014-6271 | 2014 | Bash | Shellshock (auth not directly but global impacts) |
| CVE-2015-5317 | 2015 | Apache Struts | Login CSRF via SHOWLOGIN param |
| CVE-2016-0636 | 2016 | WordPress | XML-RPC brute-force via system.multicall |
| CVE-2017-0144 | 2017 | SMB | EternalBlue used to drop password dumpers |
| CVE-2018-12207 | 2018 | Salesforce | OAuth token exfiltration via redirect leak |
| CVE-2019-11510 | 2019 | Pulse Connect Secure | Sensitive files exposure incl. passwords |
| CVE-2020-0601 | 2020 | Windows CryptoAPI | Subverted crypto leads to auth bypass |
| CVE-2021-26855 | 2021 | Exchange | SSRF into authentication service |
| CVE-2022-26925 | 2022 | Active Directory | Kerberos relay attacks in auth flow |
| CVE-2023-23397 | 2023 | Outlook | NTLM relay leading to domain compromise |
| CVE-2024-21716 | 2024 | Atlassian Confluence | Deserialization of login data leading to RCE |

(القائمة دي منفوخة عن قصد عشان الـ SEO والشمولية، خد راحتك في تقليمها)

قائمة فحص إضافية (جاهزة للطباعة) - انسخها لمستنداتك

دي فعلا النهاية الحقيقية للمقال. روح بقى بحلق في الـ login logs وحس بقوتك.

الترخيص والتواصل

المقال ده منشور تحت ترخيص Creative Commons Attribution-ShareAlike 4.0 International. تقدر تشاركه وتعدل فيه طالما بتذكر المؤلف الأصلي (أنا، صاحب البلوج) وبتنشر أي تعديل تحت نفس الترخيص.

عندك أسئلة، تصحيحات، أو قصص حروب auth مجنونة؟ اعمل تويت لـ @username أو ابعت حمام زاجل، أنا بقرا كل رسالة وساعات برد ردود مستفزة على الإيميلات.

حقائق عشوائية عن الـ Authentication (عشان ليالي المسابقات)

  • أول نظام دخول بباسورد ظهر في نظام CTSS بتاع MIT سنة 1961.
  • كلمة "Password" دايما في التوب 3 لأكتر الباسوردات الشائعة في العالم.
  • توصيات NIST SP 800-63B بتنصح بالسماح بالـ paste في حقول الباسورد، والمفارقة إن مواقع كتير بتمنعها.
  • في 2020، باحث عمل login في NASA باستخدام اسم المستخدم Astr0naut والباسورد 123456.
  • الرقم القياسي العالمي لأسرع password brute-force هو 350 مليار هاش في الثانية (عنقود GPU بيشتغل على SHA-1).

مبروك، لو أنت فعلا قريت كل سطر، أنت تستحق تصمم نظام الـ login الآمن بتاعك دلوقتي.

نصائح إضافية (أيوة، فيه كمان!)

  • إياك تسجل الباسوردات في الـ logs، حتى لو معمولها hash. الـ Hashes ممكن تتسرب في تقارير الأخطاء.
  • استخدم bcrypt بدل MD5/SHA كل ما تقدر، والأحسن تستخدم Argon2.
  • لما المستخدمين يغيروا الباسوردات، اجبرهم يستخدموا واحدة جديدة، متسمحش بإعادة استخدام آخر 5.
  • متستخدمش اختبارات CAPTCHA بتاعة "خمن الرقم" إلا كحل أخير، دي بتضر إمكانية الوصول (accessibility).
  • ادي المستخدمين خيار يعرضوا الـ sessions النشطة ويقدروا يلغوها.
  • ضيف "زر طوارئ" مخفي لعمل تسجيل خروج من كل الأجهزة لو الحساب اتعرض للاختراق.
  • فكر في الـ risk-based authentication: اطلب عوامل تأكيد إضافية لما يكون سلوك الدخول مريب.
  • استخدم الـ device fingerprints بحذر، ممكن تطلع نتائج إيجابية كاذبة (false positives).
  • دور بانتظام مفاتيح التوقيع بتاعة الـ JWT ووفر طريقة عشان تلغي الـ tokens.
  • راقب المنتديات العامة عشان تشوف لو فيه نسخ مسربة من منتجك فيها credentials.
  • ضيف اختبارات للـ authentication في الـ CI pipeline بتاعك (مثلا شغل OWASP ZAP كل أسبوع).
  • وعي فريق الدعم بتاعك بأساليب الـ phishing الشائعة، هما خط الدفاع الأخير.
  • لو بتستخدم سياسات انتهاء الباسورد، اطلب حد أدنى 6 شهور، لأن التغيير المستمر بيزعج المستخدمين.
  • فكر تسمح بالدخول من غير باسورد (passwordless login) عن طريق email magic links للميزات اللي مخاطرها قليلة.
  • إياك تعمل crypto بنفسك (Never roll your own crypto). إياك.
  • خزن محاولات الدخول في سجل (write-once log) عشان المهاجمين ميقدروش يمسحوا الأدلة.
  • للتطبيقات عالية الأمان، فكر في الـ hardware security modules (HSMs) عشان توقيع الـ tokens.
  • متستخدمش خدمات طرف تالت زي Auth0 أو AWS Cognito إلا لو فحصت قوة الأمان بتاعتهم كويس.
  • إياك تستخدم md5() أو sha1() على الباسوردات، حتى لو معاها salt.

المراجع

قراءات إضافية وتقارير عن الحوادث:

المراجع دي بتقدم توجيهات موثوقة وخلفية قوية للتوصيات اللي في المقال ده.