محاولات تسجيل الدخول الاختناق

Question

(هذا هو في المديرة السؤال اللغوي، على الرغم من ذلك في حالتي أنا أستخدم ASP.NET 3.5)

أنا أستخدم ASP.NET القياسية التحكم في تسجيل الدخول وأود أن تنفيذ محاولة تسجيل الدخول الفاشلة التالية منطق الاختناق.

• التعامل مع OnLoginError الحدث والصيانة، في جلسة, ، عدد محاولات تسجيل الدخول الفاشلة
• عندما يصل هذا العدد إلى بعض القيمة القابلة للتكوين حظر محاولات تسجيل الدخول الإضافية من عنوان IP الأصلي أو لهذا المستخدم / هؤلاء المستخدمين لمدة ساعة واحدة

هل هذا يبدو وكأنه نهج معقول؟ هل أفتقد الوسائل الواضحة التي يمكن من خلالها تجاوز مثل هذه الشيكات؟

ملاحظة: ترتبط جلسة ASP.NET مع متصفح المستخدم باستخدام ملف تعريف ارتباط

يحرر

هذا هو لموقع الإدارة التي ستستخدم فقط من المملكة المتحدة والهند

Answer 1

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

1st failed login    no delay
2nd failed login    2 sec delay
3rd failed login    4 sec delay
4th failed login    8 sec delay
5th failed login    16 sec delay

من شأنه أن يقلل من المخاطر التي يمكن إساءة استخدام تدبير الحماية هذا بسبب حرمان هجمات الخدمة.

يرى http://www.codinghorroror.com/blog/archives/001206.html.

Answer 2

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

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

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

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

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

Answer 3

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

إذا قمت بإدراج التأخير باستخدام Thread.Sleep (n)، فستقوم بربط مؤشر ترابط تجمع موضوع ASP.NET لمدة التأخير. لن يكون هذا الخيط متاحا لتنفيذ الطلبات الأخرى. في هذا السيناريو، سيكون هجوم أسلوب DOS بسيط هو الحفاظ على تقديم نموذج تسجيل الدخول الخاص بك. في النهاية سيكون كل مؤشر ترابط متاح لتقديم الطلبات (وزيادة فترات الزمن).

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

1. محاولة المصادقة أثناء بدء التشغيل وتحديد التأخير عند الفشل
2. إرجاع iAsyncresult فضح whithandle التي سيتم تشغيلها بعد التأخير
3. تأكد من أن Waithandle قد تم تشغيله (أو كتلة حتى كان) في EndProcessRequest

Answer 4

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

بدلا من ذلك، يمكنك إدراج اختبار CAPTCHA بعد محاولات فشل X لإحباط Kiddies.

Answer 5

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

وإلا فإن العدد والقفل هو معقول - على الرغم من أن الحل الأسهل قد يكون له مهلة مضاعفة بين كل فشل تسجيل الدخول. أي 2 ثانية بعد محاولة تسجيل الدخول الأولى، بعد 4 ثوان بعد المقبل، 8 إلخ.

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

أيضا مراقبة نفس IP / مستخدم مختلف ونفس المستخدم / IP مختلف.