security - org - منع Brute Force Logins على مواقع الويب



hackers facebook 2015 (9)

كرد فعل على عمليات خطف Twitter الأخيرة ونشرة جيف على هجمات القاموس ، ما هي أفضل طريقة لتأمين موقع الويب الخاص بك ضد هجمات تسجيل دخول القوة الغاشمة؟

يقترح جيف في وضع تأخير متزايد لكل محاولة تسجيل دخول ، واقتراح في التعليقات هو إضافة كلمة التحقق بعد المحاولة الثانية الفاشلة.

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

أفكار؟ اقتراحات؟

https://ffff65535.com


لتوضيح أفضل الممارسات:

ما قاله krosenvold: سجل num_failed_logins و last_failed_time في جدول المستخدم (ما عدا عندما يتم تعليق المستخدم) ، وبمجرد أن يصل عدد تسجيلات الدخول الفاشلة إلى حد ما ، تقوم بتعليق المستخدم لمدة 30 ثانية أو دقيقة. إنها أفضل الممارسات.

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

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

ويمكنك ، بطريقتين على الأقل.

  1. إذا كان لدى المستخدم ملف تعريف ارتباط مستمر ("تذكرني") ، فقط دعه يمر.

  2. عندما تعرض رسالة "أنا آسف ، تم تعليق حسابك بسبب عدد كبير من محاولات تسجيل الدخول غير الناجحة" ، قم بتضمين ارتباط يقول " تسجيل دخول احتياطي آمن - HUMANS ONLY (bots: no lying) ". نكتة جانبًا ، عندما ينقرون على هذا الرابط ، يقدم لهم نموذج تسجيل دخول مصادق عليه من reCAPTCHA والذي يتجاوز حالة تعليق الحساب. وبهذه الطريقة ، إذا كانوا بشرًا ومعرفة كلمة المرور الصحيحة + وكلمة المرور (وقادرون على قراءة اختبار CAPTCHA) ، فلن يتم إزعاجهم أبدًا بالتأخير ، وسيكون موقعك على الويب غير قادر على الهجمات السريعة.

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

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


أعتقد أنه يجب عليك تسجيل اسم المستخدم. هذا هو الثابت الوحيد (أي شيء آخر يمكن انتحال). ونعم يمكن أن يحبس مستخدم شرعي ليوم واحد. ولكن إذا كان لا بد لي من الاختيار بين حساب اختراق وحساب مغلق (ليوم واحد) اخترت بالتأكيد القفل.

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


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

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


في عيني هناك عدة احتمالات ، لكل منها سلبيات وإيجابيات:

فرض كلمات مرور آمنة

  • Pro : سيمنع هجمات القاموس
  • Con : سوف يمنع أيضا شعبية ، لأن معظم المستخدمين لا يستطيعون تذكر كلمات المرور المعقدة ، حتى لو شرح لهم ، كيف يتذكرونها بسهولة. على سبيل المثال من خلال تذكر الجمل: "اشتريت 1 أبل لمدة 5 سنت في مول" يؤدي إلى "Ib1Af5CitM".

اغلاق بعد عدة محاولات

  • Pro : سوف تبطئ الاختبارات المؤتمتة
  • Con : من السهل قفل المستخدمين لجهات خارجية
  • يخدع : جعلها ثابتة في قاعدة بيانات يمكن أن يؤدي إلى الكثير من عمليات الكتابة في مثل هذه الخدمات الضخمة مثل تويتر أو مقارنات.

كبتشس

  • Pro : تمنع الاختبار التلقائي
  • يخدع : هم يستهلكون وقت الحوسبة
  • يخدع : سوف "تبطئ" تجربة المستخدم
  • معلقة ضخمة : فهي ليست خالية من العوائق

فحوصات بسيطة للمعرفة

  • Pro : سيمنع الاختبار التلقائي
  • الاشتراك : "بسيط" هو في عين الناظر.
  • يخدع : سوف "تبطئ" تجربة المستخدم

تسجيل الدخول واسم المستخدم المختلفة

  • المؤيد : هذا تقني واحد ، بالكاد ينظر إليه ، ولكن في نظري بداية جيدة لمنع هجمات القوة الغاشمة.
  • Con : يعتمد على اختيار المستخدم من الاسمين.

استخدم جمل كاملة ككلمات مرور

  • Pro : يزيد من حجم مساحة الاحتمالات القابلة للبحث.
  • Pro : يسهل تذكرها لمعظم المستخدمين.
  • يخدع : تعتمد على اختيار المستخدمين.

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

أي اقتراحات أخرى؟


مشاركة قديمة ولكن اسمحوا لي بنشر ما لدي في نهاية عام 2016. آمل أن لا يزال يمكن أن يساعد.

إنها طريقة بسيطة ولكن أعتقد أنها قوية لمنع هجوم تسجيل الدخول. على الأقل أنا دائما استخدامه على كل شبكة من الألغام. لا نحتاج إلى اختبار CAPTCHA أو أي مكونات خارجية أخرى.

عند تسجيل دخول المستخدم لأول مرة. نحن ننشئ جلسة مثل

$_SESSION['loginFail'] = 10; // any number you prefer

إذا نجح تسجيل الدخول ، فسندمره وسنساعدك على تسجيل الدخول.

unset($_SESSION['loginFail']); // put it after create login session

ولكن إذا فشل المستخدم ، لأننا عادةً ما نرسل رسالة خطأ إليهم ، فإننا في الوقت نفسه نخفض الجلسة بمقدار 1:

$_SESSION['loginFail']-- ; // reduce 1 for every error

وإذا فشل المستخدم 10 مرات ، فإننا سنوجههم إلى مواقع ويب أخرى أو أي صفحات ويب.

if (!isset($_SESSION['loginFail'])) { 

     if ($_SESSION['login_fail'] < 1 ) {

     header('Location:https://google.com/'); // or any web page

     exit();

}
}

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

يجب على المستخدمين إغلاق المتصفح (لتدمير تسجيل الدخول إلى جلسة العمل التي أنشأناها) ، وفتحها مرة أخرى لمشاهدة صفحة تسجيل الدخول لدينا "مرة أخرى".

هل هو مفيد؟


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

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

تمت مناقشة معظم تقنيات الوقاية الشائعة بالفعل في هذا المنصب. أود أن أضيف مخاوفي فيما يتعلق بقفل الحساب وقفل عنوان IP. أعتقد أن تأمين الحسابات فكرة سيئة كتقنية وقائية. أضع بعض النقاط هنا لدعم قضيتي.

قفل الحساب سيء

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

يعتبر تأمين عنوان IP للحساب فكرة سيئة أيضًا

حل آخر هو تأمين عنوان IP مع تسجيلات الدخول الفاشلة المتعددة. تكمن المشكلة في هذا الحل في إمكانية حظر مجموعات كبيرة من المستخدمين عن غير قصد من خلال حظر خادم وكيل يستخدمه مزود خدمة الإنترنت أو شركة كبيرة. هناك مشكلة أخرى وهي أن العديد من الأدوات تستخدم قوائم الخادم الوكيل وإرسال عدد قليل من الطلبات من كل عنوان IP قبل الانتقال إلى التالي. باستخدام قوائم وكيل مفتوحة متاحة على نطاق واسع في مواقع مثل http://tools.rosinstrument.com/proxy/ ، يمكن للمهاجم بسهولة التحايل على أي آلية لمنع بروتوكول الإنترنت. نظرًا لعدم حظر معظم المواقع بعد كلمة مرور واحدة فاشلة ، يمكن للمهاجم استخدام محاولتين أو ثلاث محاولات لكل وكيل. يمكن للمهاجم الذي لديه قائمة تضم 1000 وكيل أن يحاول استخدام 2000 أو 3000 كلمة مرور دون حظر. ومع ذلك ، على الرغم من نقاط الضعف في هذه الطريقة ، فإن مواقع الويب التي تشهد عددًا كبيرًا من الهجمات ، ومواقع ويب البالغين على وجه الخصوص ، تختار منع عناوين IP للوكيل.

اقتراحي

  • لا قفل الحساب. بدلاً من ذلك ، قد نضع في الاعتبار إضافة تأخير مقصود من جانب الخادم في محاولات تسجيل الدخول / الاشتراك لمحاولات خاطئة متتالية.
  • تتبع موقع المستخدم استنادًا إلى عنوان IP في محاولات تسجيل الدخول ، وهو أسلوب شائع تستخدمه Google و Facebook. ترسل Google خدمة OTP بينما يوفر Facebook تحديات أمان أخرى مثل اكتشاف أصدقاء المستخدم من الصور.
  • Google re-captcha لتطبيق الويب ، SafetyNet لنظام Android وتقنية تصديق تطبيقات الجوّال المناسبة لنظام التشغيل iOS - في طلبات تسجيل الدخول أو الاشتراك.
  • ملف تعريف ارتباط الجهاز
  • بناء نظام مراقبة مكالمات API للكشف عن المكالمات غير العادية لنقطة نهاية API معينة.

شرح المقترحات

تأخير متعمد في الاستجابة

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

لاحظ أنه على الرغم من أن إضافة تأخير قد يؤدي إلى إبطاء هجوم واحد مترابطة ، يكون أقل فعالية إذا كان المهاجم يرسل طلبات مصادقة متعددة في نفس الوقت.

تحديات أمنية

يمكن وصف هذه التقنية بأنها تحديات أمان تكيفية استنادًا إلى الإجراءات التي يقوم بها المستخدم في استخدام النظام في وقت سابق. في حالة وجود مستخدم جديد ، قد تؤدي هذه التقنية إلى حدوث تحديات أمان افتراضية.

قد نأخذ بعين الاعتبار عندما سنواجه تحديات أمنية؟ هناك عدة نقاط يمكننا فيها.

  • عندما يحاول المستخدم تسجيل الدخول من موقع لم يكن موجودًا بالقرب منه من قبل.
  • محاولات خاطئة لتسجيل الدخول.

ما نوع المستخدم الذي يواجه تحديات أمنية؟

  • إذا قام المستخدم بإعداد أسئلة الأمان ، فقد نأخذ في الاعتبار سؤال المستخدم عن تلك الإجابات.
  • بالنسبة إلى التطبيقات مثل Whatsapp و Viber إلخ ، قد نأخذ بعض أسماء جهات الاتصال العشوائية من دليل الهاتف ونطلب وضع أرقامها أو العكس.
  • بالنسبة لأنظمة المعاملات ، قد نفكر في مطالبة المستخدم بأحدث المعاملات والمدفوعات.

لوحة مراقبة API

لإنشاء لوحة مراقبة لمكالمات واجهة برمجة التطبيقات.

  • ابحث عن الحالات التي قد تشير إلى هجوم قوي أو إساءة استخدام حساب أخرى في لوحة مراقبة واجهة برمجة التطبيقات.
  • العديد من عمليات تسجيل الدخول الفاشلة من نفس عنوان IP.
  • تسجيلات الدخول بأسماء مستخدمين متعددة من نفس عنوان IP.
  • تسجيلات الدخول لحساب واحد قادم من العديد من عناوين IP المختلفة.
  • الاستخدام المفرط واستهلاك عرض النطاق الترددي من استخدام واحد.
  • فشل محاولات تسجيل الدخول من أسماء المستخدمين أو كلمات المرور المتسلسلة أبجديًا.
  • تسجيلات الدخول مع كلمات المرور المشبوهة المتسللين تستخدم عادة ، مثل ownsyou (ownzyou) ، washere (wazhere) ، والمتحمسين ، hacksyou الخ

بالنسبة إلى حسابات النظام الداخلية ، قد نفكر في السماح بتسجيل الدخول فقط من بعض عناوين IP. إذا كان من الضروري تثبيت تأمين الحساب ، بدلاً من تأمين حساب بالكامل ، فضعه في وضع تأمين مع إمكانات محدودة.

وهنا بعض القراءات الجيدة.


يجب أن تقوم بتطبيق ذاكرة تخزين مؤقت في التطبيق غير مرتبطة بقاعدة البيانات الخلفية لهذا الغرض.

أولاً وقبل كل شيء يؤدي تأخير أسماء المستخدمين المشروعة فقط إلى "التخلي عن" قاعدة العملاء الصالحة الخاصة بك والتي يمكن أن تكون في حد ذاتها مشكلة حتى لو كان اسم المستخدم ليس سراً تحت حراسة مشددة.

وثانيًا حسب تطبيقك ، يمكنك أن تكون أكثر ذكاءً مع إجراءات تأخير محددة للتطبيق مما قد تريده عند تخزين البيانات في DB.

مقاومتها لمحاولات السرعة العالية التي من شأنها أن تسرّب حالة DOS إلى ديسيبلك الخلفي.

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

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


يمكنك إضافة بعض أشكال اختبار اختبار CAPTCHA. لكن احذر أن معظمهم يجعل الوصول إلى العين أكثر صعوبة أو يضر بالناس. هناك نموذج مثير للاهتمام لـ CAPTCHA يطرح سؤالاً ،

ما هو مجموع 2 و 2؟

وإذا سجلت آخر فشل في تسجيل الدخول ، فيمكنك تخطي اختبار CAPTCHA إذا كان عمره كافٍ. أجرِ اختبار CAPTCHA فقط إذا كان الفشل الأخير خلال آخر 10 دقائق.


أعتقد أن فترة القفل قصيرة الأمد الدائمة للحساب المعطى (1-5 دقائق) هي الطريقة الوحيدة للتعامل مع هذا. يحتوي كل timeOfLastFailedLogin في قاعدة البيانات على timeOfLastFailedLogin و numberOfFailedAttempts . عند numbeOfFailedAttempts > X لبضع دقائق.

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

هناك بلد واحد على الأقل هو بلد في آسيا ، لذلك لا يمكن استخدام IP لأي شيء.





brute-force