پیاده سازی روش تاخیر زمانی برای جلوگیری از حمله های Brute force

[eshpilen]

در این منبع چند راهکار منجمله راهکار تاخیر زمانی برای جلوگیری از حمله های Brute force مطرح شده:
https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks

بنظر شما روش تاخیر زمانی رو چطور پیاده سازی کنیم؟
در وهلهء اول بنظر میرسه که استفاده از یک sleep ساده راهگشا است، اما این روش در برابر حمله هایی که از چند Thread بصورت همزمان استفاده کنن ضعف داره.
برای روشن شدن مطلب مثال میزنم:
فرض کنید ما یک sleep(1) برای ایجاد محدودیت یک تلاش برای لاگین در هر ثانیه استفاده کردیم (راستی زمانش بنظر شما باید چقدر باشه؟ آیا یک ثانیه کافیه؟). ولی برنامه ای که مثلا 10 تا Thread رو همزمان (یا فرقی نمیکنه، بهرصورت با فاصلهء زمانی کوتاه) اجرا و تلاش برای لاگین میکنه بعد از این حدود 1 ثانیه 10 تا پسورد رو تست کرده و عملا سیستم امنیتی ما رو دور زده.
حالا ما نیاز به یه مکانیزم داریم تا در برابر روش مالتی ترد هم درست کار کنه.
بنظر شما اون رو به چه شکلی پیاده سازی کنیم؟

البته چیز خاص و پیچیده ای نباید باشه، ولی فکر کردم جالب و آموزنده هست و برای اطمینان از روش بهینه باید روش بصورت عمومی گفتگو بشه.

[MMSHFE]

با سلام، من شخصاً CAPTCHA رو ترجيح ميدم. بخصوص كد CAPTCHA خاصي كه خودم ساخته باشم.

[eshpilen]

البته کپچا هم خوبه و جزو روشهایی هست که در منبع معرفی شده تحلیل شدن. منبع پیشنهاد میکنه از ترکیب چند روش استفاده کنیم.
ظاهرا تونستن برنامه هایی بنویسن که کپچاهای حرفه ای تر از اونایی که من و شما مینویسیم رو بخونن، بنابراین زیاد به کپچا به تنهایی نمیشه اتکا کرد. ضمنا یه کپچا ممکنه امروز امن باشه اما فردا ممکنه کرک بشه. حتما کپچاهای بعضی سایتهای معروف رو دیدید که چقدر پیچیده هستن و خوندن اونا حتی برای انسان هم سخته و ضریب خطای بالایی داره، این بخاطر همینه که تونستن برنامه های قوی ای برای کرک کردن کپچا تولید کنن که کپچاهای ساده تر رو با ضریب موفقیت بالا کرک میکنن (در این زمینه حتی 30% هم ضریب موفقیت بالایی محسوب میشه).
بنابراین بهتره از روش تاخیری هم استفاده کنیم چون روش خوب و اصولی ای هست و میشه گفت مکمل یا یک لایهء امنیتی اضافه هست. البته اگر پسورد کاربران بیش از حد ضعیف نباشه این روش به تنهایی هم کفایت میکنه.

لطفا اگر درمورد پیاده سازی روش تاخیری نظری دارید بفرمایید.

[MMSHFE]

درمورد روش ايجاد تأخير، همونطور كه خودتون هم اشاره كردين، با استفاده از Thread ميشه يه جورايي دورش زد ولي به نظرم اگه براي Session تأخير ايجاد كنيم و از هر Session در فواصل زماني مشخص فقط Request قبول كنيم، ديگه با Thread و... هم نميشه جلوش رو گرفت. اگه از اين روش در كنار CAPTCHA استفاده بشه، تركيب مفيدي ميشه. البته CAPTCHAهاي هوشمند باشه بهتره. مثلاً همون بحث تشخيص شباهت چند تصوير. ميشه تصاوير مختلفي رو همراه با TAG اونها توي DB ذخيره كرد (البته نه خود تصوير رو، فقط اسمش منظورمه) و موقع نمايش، بصورت رندوم چند تصوير با TAGهاي مشابه نشون بديم و بگيم كاربر وجه تشابه اونها رو انتخا كنه. البته اين روش هم وقتي سودمند هست كه اولاً تعداد تصاوير زياد باشه، ثانياً با كمك تصاوير خوانده شده، يك تصوير جديد با نام فايل رندوم ساخته و نمايش داده بشه چون اگه از اسامي اصلي فايلها استفاده كنيم، هكر ميتونه به راحتي يكبار تصوير رو ببينه و توي برنامه نام فايل رو با تگ مربوطه ذخيره كنه و در دفعات بعدي، كد صفحه رو بخونه و اگه اون نام فايل توي صفحه بود، به راحتي TAG رو بفهمه.
موفق باشيد.

[eshpilen]

درمورد روش ايجاد تأخير، همونطور كه خودتون هم اشاره كردين، با استفاده از Thread ميشه يه جورايي دورش زد ولي به نظرم اگه براي Session تأخير ايجاد كنيم و از هر Session در فواصل زماني مشخص فقط Request قبول كنيم، ديگه با Thread و... هم نميشه جلوش رو گرفت.
سشن رو هم که میشه راحت دور زد.
یعنی چی چجوری با سشن؟
کد بذار.


اگه از اين روش در كنار CAPTCHA استفاده بشه، تركيب مفيدي ميشه. البته CAPTCHAهاي هوشمند باشه بهتره. مثلاً همون بحث تشخيص شباهت چند تصوير. ميشه تصاوير مختلفي رو همراه با TAG اونها توي DB ذخيره كرد (البته نه خود تصوير رو، فقط اسمش منظورمه) و موقع نمايش، بصورت رندوم چند تصوير با TAGهاي مشابه نشون بديم و بگيم كاربر وجه تشابه اونها رو انتخا كنه. البته اين روش هم وقتي سودمند هست كه اولاً تعداد تصاوير زياد باشه، ثانياً با كمك تصاوير خوانده شده، يك تصوير جديد با نام فايل رندوم ساخته و نمايش داده بشه چون اگه از اسامي اصلي فايلها استفاده كنيم، هكر ميتونه به راحتي يكبار تصوير رو ببينه و توي برنامه نام فايل رو با تگ مربوطه ذخيره كنه و در دفعات بعدي، كد صفحه رو بخونه و اگه اون نام فايل توي صفحه بود، به راحتي TAG رو بفهمه.
موفق باشيد.تصاویر رو از روی محتویات بایتهای اونا هم میشه براحتی تشخیص داد. تغییر نام فایل جلوش رو نمیگیره.

[MMSHFE]

اگه تصوير رو با يك كد Random واترمارك كنيم چطور؟

[eshpilen]

باید دید تشخیص شباهت دو تصویر به این شکل ساده تر هست یا خوندن 6 کاراکتر کپچا!؟
البته از این روش هم ظاهرا بعضی جاها استفاده میکنن.
ولی من فکر میکنم برای تشخیص شباهت دو تصویر بشه الگوریتم های قوی ای نوشت. ساده ترین حالتش مثلا انتخاب و ذخیرهء 1000 پیکسل بصورت رندوم از جاهای مختلف هر تصویر و بعد مقایسهء پیکسل های تصاویر بعدی با اونهاست که اگر تعداد بیشتری از پیکسل ها در یک تصویر خاص یکسان یا مشابه بودن یا فرضا روابط ثابتی بین اون پیکسل ها وجود داشتن میتونیم با ضریب اطمینان خوبی بگیم که اون تصویر همون تصویر قبلی بوده.
اگر هم تصویر رو خیلی دستکاری کنیم که تمام یا بیشتر پیکسل هاش تغییر کنن باید دید چطوری و آیا اصلا تصویر خوانایی کافی رو حفظ میکنه یا نه. بهرحال بنظرم روش این دستکاری باید مفصل تر و هوشمندانه تر از ایجاد یک واترمارک ثابت و ساده باشه.
ضمنا اصلا نیازی هم نیست خودمون رو به 1000 پیکسل محدود کنیم، میتونیم الگوریتم تشخیص شباهت رو روی تمام پیکسل ها اجرا کنیم.
اونایی که روی پردازش تصاویر و هوش مصنوعی کار میکنن احتمالا بهتر بدونن که الگوریتم های تشخیص شباهت چطوری کار میکنن و تا چه حدی قوی هستن. بنده اطلاعات بیشتری ندارم و نمیتونم بگم خوندن کپچای کاراکتری ساده تر هست یا تشخیص شباهت بین تصاویر.

حالا بگذریم داشتیم روش پیاده سازی سیستم تاخیری رو میگفتیم.

در ارتباط با روش تاخیری، بنده فکر کنم باید یه Lock پیاده سازی کنیم. حالا یا در دیتابیس یا در سیستم فایل یا جور دیگه ای (راستی فکر کنم MySQL بصورت درونی یه همچین چیزی داشت که نیازی به استفاده از جدول و خواندن و نوشتن در دیتابیس هم نداره).
فرض کن مثلا وقتی درخواست برای لاگین با یه نام کاربری دریافت میشه برنامه یک فایل با اون نام کاربری ایجاد میکنه (در یک دایرکتوری مخصوص ذخیرهء فایلهای Lock). فقط همین برنامه که فایل رو ایجاد کرده حق داره اون رو دلیت کنه و وقتی تاخیر زمانی (با تابع sleep) رو سپری کرد این کار رو میکنه. در این مدت هر لاگین دیگری که بخواد بشه برنامه اول چک میکنه اگر فایل Lock برای اون نام کاربری وجود داشت صبر میکنه تا فایل Lock دلیت بشه. البته برنامهء اول هم که همین برنامه بوده همین کار رو در ابتدا انجام داده و بعد فایل Lock رو ایجاد کرده.
به این شکل ما یه سیستمی ایجاد کردیم که در برابر حملات مالتی ترد هم امنیت داره. چون در هر بازهء زمانی تعیین شده تنها یک لاگین میتونه اجرا بشه و لاگین های بعدی باید منتظر تموم شدن لاگین درحال اجرا بشن و فقط میتونن یکی یکی به نوبت اجرا بشن.

اما حتی این سیستم هم در برابر تمام حالات امن نیست. چون فرضا اگر کرکر 10 نام کاربری مختلف رو بصورت همزمان چک بکنه، سیستم ما جلوش رو نمیگیره! این روش حمله برای حمله های رندوم و نه نسبت به یک نام کاربری خاص، استفاده میشه. یعنی کرکر میگرده دنبال یک نام کاربری نامشخص که یکی از عبارات ساده و متداول بعنوان پسورد براش انتخاب شده.

حالا باید فکر کنیم ببینیم آیا میشه جلوی اینطور حمله ها رو هم گرفت یا نه!
میتونیم بر اساس IP قفل پیاده سازی کنیم اما این کار بازم جلوی همهء حالتها رو نمیگیره. خیلی از ابزارهای هک از پراکسی ها و IP های متعدد استفاده میکنن. ولی بهرصورت بد هم بنظر نمیرسه و از بعضی حالات و افراد جلوگیری میکنه. البته اگر یک IP بین کاربران خیلی زیادی که با سایت ما کار داشته باشن به اشتراک گذاشته شده باشه ممکنه با این روش مشکل پیش بیاد، اما فکر میکنم چنین شرایطی خیلی کم احتمال هست.

راستی برای اون سیستم فایل Lock که گفتم مثلا باید یک سیستمی هم درنظر بگیریم که اگر به هر دلیلی اسکریپتی که فایل Lock رو ایجاد کرده اون رو دلیت نکرد (مثلا بر اثر Crash)، سیستم درحالت قفل باقی نمونه. میشه این کار رو بر اساس زمان ایجاد Lock انجام داد. یعنی هر اسکریپت طول عمر فایل Lock رو چک میکنه که اگر از یک زمان معقولی بیشتر بود خودش فایل Lock رو دلیت کنه.
ضمنا اینکه از فایل استفاده کردیم بخاطر اینه که فرایند ایجاد فایلها اتمیک هست. از این خصیصهء سیستم فایل به همین شکل خیلی جاها استفاده شده. ضمنا فکر میکنم این روش از دیتابیس خیلی سبک تر و به صرفه تر باشه، چون حداقل اطلاعات لازم پردازش و روی هارد ذخیره و بازیابی میشن و کانکشن های دیتابیس هم بیخودی اشغال نمیشه.

[MMSHFE]

منظورم رو خوب متوجه نشدين. منظورم اين نيست كه يك تصوير رو چندبار تغيير بديم و نمايش بديم. منظورم اينه كه چند تصوير كاملاً متفاوت ولي با موضوع اصلي مشابه رو نشون بديم (مثلاً چهار تصوير كه موضوع اصلي توي اونها سيب هست) و از كاربر بخوايم موضوع اصلي رو انتخاب كنه. براي مثال، اينجا (http://server251.theory.cs.cmu.edu/cgi-bin/esp-pix/esp-pix) رو ببينيد.

[eshpilen]

خب بالاخره تعداد تصاویر شما محدود هست. چه یک تصویر مربوط به سیب باشه و چه ده تا و چه صدتا بازم فرقی نمیکنه.
مثلا اگر دوتا تصویر سیب هست خب این دوتا تصویر رو اول برای برنامه (برنامهء کرک) مشخص میکنیم. بعد برنامه هر بار میتونه از روی محتویات بایتهای تصویر تشخیص بده که آیا تصویر مربوط به سیب دریافت شده یا نه. این برای یک تصویر تا هر تعداد تصویر تفاوتی نمیکنه چون اگر شما بتونی ده هزار تصویر سیب ذخیره و به برنامت معرفی کنی، پس برنامهء کرکر هم میتونه همین کار رو بکنه.
یعنی میتونیم تصاویر استاتیک شما رو از قبل به برنامه بشناسونیم.
اگر هم تصاویر رو بصورت رندوم و دینامیک دستکاری کنید که میشه همون بحث اخیر.

[MMSHFE]

اول مثالي كه گذاشتم رو ببينيد. ميتونيم تصوير نهايي رو با تركيب تصاوير مذكور ايجاد كنيم و يك نام كاملاً تصادفي هم بهش بديم كه نتونه نام فايل رو ذخيره كنه. ضمناً كارهاي مختلفي مثل چرخاندن تصاوير (در حد چند درجه) يا تغيير مقياس هم ميتونيم موقع ادغام تصاوير انجام بديم كه كار تشخيص تصوير رو براي نرم افزار خيلي سخت ميكنه. حتماً اطلاع دارين كه پردازش تصوير اينقدرها هم راحت نيست. تازه به نظرم اگه يك هكر بتونه چنين الگوريتمي رو رمزگشايي كنه، واقعاً حقشه به سايت دسترسي پيدا كنه. :لبخند:

[eshpilen]

هووم شاید قوی بشه به این شکل :متفکر:
ولی پیچیده تر از کپچای کاراکتری میشه و ضمنا از نظر ظاهر و فضایی که میگیره و ترافیکی که مصرف میکنه و راحتی کاربران و اینا زیاد جالب بنظر نمیرسه. کپچای کاراکتری خیلی قشنگ تر و بهینه تره بنظرم؛ با بقیهء چیزا هماهنگی بهتری داره و خیلی شیک تره. از دست این کرکرها ببین به چه روزی افتادیم چقدر بازی باید دربیاریم! لابد چند وقت دیگه باید بازی کامپیوتری بذاریم توی سایت هرکس که بازی کرد و تونست رایانه رو ببره میفهمیم که آدمه!!
دست آخر هم فکر کنم یه نفر باید بشینه پشت سرور و از کاربران سوالاتی بپرسه تا بفهمه آدم هستن یا نه!
تازه بعید نیست اینقدر رایانه ها و برنامه ها قوی بشن که در آینده حتی به این شکل هم نشه آدم رو از رایانه تشخیص داد!!

[eshpilen]

میگم اصلا بیایم بیخیال بشیم، همون کپچای کاراکتری با یه سیستم تاخیر زمانی و اینا کافیه. کاربر هم اگر پسورد ضعیف گذاشته تقصیر خودشه بذار هک بشه اصلا!!
اگر پسورد خیلی ضعیف نباشه بدون این سیستمها هم کسی نمیتونه به این سادگی ها کرک کنه. اگر پسورد قوی باشه که اصلا غیرممکنه. مثلا بنده برای ایمیلم یک پسورد طولانی کاملا رندوم گذاشتم. البته پسورد سایتهای مختلف رو جایی ذخیره کردم تحت یک پسورد اصلی دیگه.

البته این بحث درمورد Brute force بود. بحث جلوگیری از روبات ها در جاهایی مثل فرم ثبت نام و کامنت جداست.

[MMSHFE]

موافقم ولي من خودم از اين روش CAPTCHA تصويري خيلي خوشم مياد. تازه با كمك GD و GZIP ميشه تصاوير رو فشرده هم بكنيم.

[eshpilen]

خب تا اینجا به این نتیجه رسیدیم که یه سیستم Lock با استفاده از سیستم فایل ایجاد میکنیم که فرضا اسم هر فایل برابر نام کاربری برای لاگین باشه (یا اگر مناسب نیست، آیدی عددی اون نام کاربری).
اما علاوه بر این، یک محدودیت بر اساس IP هم میذاریم. یعنی یک فایل Lock به ازای هر IP که میخواد لاگین کنه هم خواهیم داشت.
بنابراین اسکریپت لاگین اول وجود هردوی یک فایل Lock برای کاربر مورد نظر و یک فایل Lock برای IP کاربر رو چک میکنه که اگر هرکدام از اینا وجود داشتن، باید منتظر بمونه تا قفل برداشته بشه.

ضمنا قبلا به لازم بودن مکانیزمی برای حذف فایلهای Lock که به هر دلیلی حذف نشدن هم اشاره کردم.

شاید بتونیم راهی برای جلوگیری از حمله هایی که از چند IP استفاده میکنن هم پیدا کنیم.

البته با وجود ترکیب همزمان این سیستم و کپچای کاراکتری فکر میکنم امنیت سیستم ما برای موارد عادی مناسب باشه.

[eshpilen]

تازه با كمك GD و GZIP ميشه تصاوير رو فشرده هم بكنيم.
چطوری یعنی؟ تصویر رو وقتی توسط GD با فرمت jpg تولید کنی مگه از قبل فشرده نیست؟

[eshpilen]

اما یه اشکال بنظرم رسید!
فرض کنیم دو تلاش برای لاگین بصورت کاملا همزمان اجرا بشن.
حالا هردوی این اسکریپت ها چک میکنن که آیا فایل Lock وجود داره یا نه، و این بخش برنامه در هردو بصورت همزمان اجرا میشه. هردوی اونا میبینن که فایل Lock وجود نداره و هر دو همزمان اقدام به ایجاد فایل Lock میکنن و بقیهء فرایند لاگین در اونها هم همزمان اجرا میشه. درحالیکه باید فقط یک برنامه در واحد زمان اجرا بشه. تعداد این اسکریپت های همزمان میتونه حتی از دو تا هم بیشتر باشه.

باید یه راهکاری هم برای حل این اشکال بیاندیشیم.

[Metal Gear Solid]

دوستان ایده ی بهتری حداقل برای ما ایرانی ها هم هست چون هنوز الگوریتم هایی نوشته نشده که بتونه فارسی رو درست متوجه بشه تا جایی که میدونم
میشه یک اسلایدر ساخت. که از عددی تصادفی شروع و تا عددی تصادفی ختم بشه.
هربار که قراره عمل کنه عددی تصادفی رو به فارسی بنویسه و از کاربر بخواد که اسلایدر رو به همون عدد ( البته توی اسلایدر به عدد ) ببره و بعد لاگین کنه.
این روش چطوره؟
اسلایدرش شبیه این باشه
http://maxcdn.webappers.com/img/2011/03/captcha.jpg
البته فقط برای اینکه اسلایدر رو متوجه بشید عکس رو گذاشتم . خود عکس ربطی به صحبت هام نداشت :D

[MMSHFE]

با GD ميشه موقع ساخت تصوير jpg، كيفيتش رو برحسب درصد بيان كنيم. اگه مثلاً روي 70% بگذاريم، هم ميشه راحت تشخيص داد، هم حجم فايل كاهش پيدا ميكنه. پارامتر سوم تابع imagejpeg اين وظيفه رو بر عهده داره.

[MMSHFE]

جالب بود. اسلايدر رو چطوري ميسازيد؟

[Metal Gear Solid]

من دقیق نفهمیدم شما راجع به چی صحبت میکردید اما در صورتی که کاربران بخوان ثبت نام کنند یا لاگین میشه کدهای اسلایدر رو با JQuery نوشت و توی برنامه استفاده کرد
الان توی اینترنت اگه دنبال Drag Captcha بگردید کلی نتیجه ی مطلوب میگیرید.
البته این هم یه نمونه ی متوسطی میتونه باشه
http://www.myjqueryplugins.com/QapTcha/demo
البته این مورد فقط باید اون علامت اسلایدر رو تا آخر ببرید تا باز شه.
یه مدل دیگه دارم الان آپلود میکنم. اون هم ایده ی جالبی داره. یه پازل 6 تای رو باید مرتب کرد تا بشه لاگین یا ثبت نام کرد.

[Metal Gear Solid]

این رو توی سایت خودم آپلود کردم
http://www.parsgamers.com/downloads/slider/captcha.html
البته نمیدونم شاید احتمالش باشه اینارو هم هک کرد اما اگه بشه از کلمات فارسی استفاده کرد به طوری که کلمات فارسی در انتخاب گزینه ی درست دخیل باشن به این زودی ها هک نمیشن چون کسی نمیاد الگوریتم برای زبان فارسی بنویسه!

[alismith]

سلام دوستان

من بحث رو دنبال کردم امکانش هست که شما اساتید لطف کنید که در رابطه با این روش sleep و lock file بیشتر توضیح بدید و آموزشی تو همین تاپیک قرار بدید!؟ لطفا...

البته من فکر کنم یک سیستمی بود که سایت club گذاشته بود مثل اینکه کاربر بعد از log in باید یک تصویر رو از روی چندتا تصویر دیگه انتخاب می کرد که مثلا اون تصویر رو قبلا خودش کشیده بود و تشخیص عکس درست هم خیلی راحت نبود ولی باز ی جورایی تصادفی هستش و کلا به مرحله بعد از ورود به سایت مربوط میشد و مثلا شاید اگر در اون مرحله سیستم نفوذ پذیر بود در این مرحله سعی کرده بودند تا از اطلاعات کاربر محافظت کنند
و یک مورد دیگه اینکه شنیدم سیستم google captcha هم قوی هستش!

امیدوارم لطف کنید و آموزش رو قرار بدید :قلب:

دیگه مزاحم نمیشم به بحثتون ادامه بدید :چشمک:

موفق باشید

[eshpilen]

من بحث رو دنبال کردم امکانش هست که شما اساتید لطف کنید که در رابطه با این روش sleep و lock file بیشتر توضیح بدید و آموزشی تو همین تاپیک قرار بدید!؟ لطفا...در یک حملهء Brute force برای کشف پسورد کاربران، یک برنامه بصورت خودکار پسوردهای مختلف رو روی اکانت کاربران تست میکنه. یعنی درخواستهای HTTP با فواصل خیلی کوتاه (بسته به سرعت شبکه و محدودیت پهنای باند - مثلا سرعت اجرا در یک LAN میتونه خیلی بالاتر باشه) برای لاگین با پسوردهای مختلف ارسال میشن. باید توجه داشت که این درخواست ها در برنامه های مالتی ترد میتونن تقریبا همزمان باشن و برنامه نیازی نداره منتظر دریافت پاسخ درخواست قبلی بمونه تا درخواست جدیدی رو ارسال کنه. فرضا برنامه میتونه همزمان 100 درخواست رو ارسال کنه و هر ثانیه یک بار این کار رو انجام بده (فرضا زمان لازم برای ارسال و دریافت نتیجهء هر درخواست 1 ثانیه هست). البته همهء برنامه ها مالتی ترد نیستن، اما باید جلوی هردو نوع مالتی ترد و single thread رو بگیریم (اگر به بحثهای قبلی دقت کرده باشید، یک الگوریتم که جلوی single thread رو میگیره ممکنه در برابر مالتی ترد ضعف داشته باشه).

برای جلوگیری از چنین حمله هایی میشه از چند روش استفاده کرد. مثلا یکی از این روشها کپچا هست که جلوی برنامه های خودکار رو میگیره. اما ضریب موفقیت و امن بودن یک کپچا برای آیندهء حتی نزدیک چیزی نیست که بشه تضمین کرد.
بنا بر توصیه کارشناسان امنیت و تحلیل منطقی خودمون، بهتره همزمان از دو یا بیشتر از این روشها استفاده کنیم. بسته به اهمیت و شرایط برنامه.
یک روش دیگر اینه که اگر تلاشهای لاگین اشتباه متعددی در بازهء زمانی کوتاهی صورت گرفت، اکانت مورد نظر رو برای مدتی قفل کنیم (حتما بعضی جاها این روش را دیده اید). اما این روش هم ضعف های بزرگ خودش رو داره. مثلا به این طریق هکرها میتونن اکانت هر کاربر یا همهء کاربران رو قفل کنن و این عمل رو بصورت نامحدود ادامه بدن و عملا حملهء DOS رو با موفقیت اجرا کنن. البته باید به محیط اجرا هم توجه داشت. مثلا در شبکهء داخلی یک شرکت شاید استفاده از این روش مناسب باشه، اما در سایتهای عمومی اینترنت که نمیشه خرابکاری رو کنترل و پیگرد کرد میتونه نامناسب باشه.
هرکدوم از این روشهای رو معمولا میشه به شکلهای مختلف و از ساده و ضعیف تا پیچیده ای پیاده سازی کرد که هرکدوم ضعف و قوت خودشون رو دارن.

یکی دیگر از روشهای پایه و تقریبا بدون عوارض جانبی که میشه بکار برد روش تاخیر زمانی هست (البته بنده این اسم رو بهش میگم). البته امنیتی که این روش میده درحد خیلی بالای بعضی روشهای دیگه نیست، اما درعوض امکان سوء استفاده از اونهم خیلی کمتر هست.
در این روش ما کاری میکنیم که در بازهء زمانی مشخصی، مثلا یک ثانیه، فقط یک درخواست بتونه پردازش بشه، و درخواست های دیگه باید در صف انتظار بمونن تا درخواست های قبلی به ترتیب در بازهء زمانی خودشون اجرا بشن و نوبت برسه. یعنی عمدا یک دستور sleep در فرضا اسکریپت لاگین خودمون کار میذاریم که باعث بشه اجرای هر درخواست لاگین مثلا حداقل یک ثانیه طول بکشه، و از طرف دیگه نمیذاریم در این مدت درخواست دیگری بصورت همزمان اجرا بشه.
یعنی حتی اگر 1000 درخواست همزمان برای لاگین به یک سرور برسه، در هر ثانیه فقط یکی از اونها پردازش خواهد شد و به این صورت میشه سرعت ممکن برای اجرای حملات Brute force رو از ظرفیت واقعی سرور و محیط ارتباطی خیلی پایین تر آورد. هرچی سرعت کم بشه شانس موفقیت و نیز سماجت از جانب کرکر کمتر هست و پسوردهای ضعیف تری امن میمونن. مثلا پسوردی که خیلی ضعیف نیست اما قوی هم نیست و درحالت عادی میشه در ظرف چند روز اون رو با روش Brute force کرک کرد، به این شکل نیاز به زمان خیلی بیشتری برای کرک شدن خواهد داشت (مثلا 100 برابر).
پسوردهای کاملا قوی البته دربرابر حمله های Brute force بدون هیچ مکانیزم امنیتی هم امن هستن، اما خیلی از پسوردهایی که توسط افراد انتخاب میشن اونقدر قوی نیستن. پسورد قوی مثلا یک پسورد حداقل 6 کاراکتری که از کاراکترهای رندوم شامل حروف کوچک و بزرگ، اعداد، و علامتهای خاص تشکیل شده باشه است (شاید هم نیاز به حداقل 8 کاراکتر باشه؟). پسوردها گرچه طولانی باشن اما اگر فرضا از عباراتی که در یک دیکشنری موجود باشن انتخاب شده باشن قوی نیستن. خیلی از برنامه های کرک کلمات داخل دیکشنری و لیست پسوردهای متداولی رو که در اختیار دارن تست میکنن (و شاید مقداری ترکیبات سادهء اونها رو مثل اضافه کردن ارقام به انتهای اونها).

خب ما اگر بخوایم سیستم تاخیر زمانی رو در PHP پیاده سازی بکنیم، بنظر شما چطور باید این کار رو بکنیم؟
هر درخواست لاگین که توسط PHP بصورت همزمان با درخواست های دیگر اجرا میشه، اطلاعی نسبت به وجود درخواست های همزمان دیگه نداره و بنابراین ما باید به طریقی کاری کنیم تا هر درخواست لاگین که اجرا میشه بتونه بفهمه آیا درخواست دیگری که هنوز کارش تمام نشده درحال اجرا هست یا نه، و چنانچه درخواست دیگری درحال اجرا بود منتظر بشه تا کار اون درخواست تموم بشه. یعنی باید مکانیزمی برای اطلاع یافتن درخواست ها از اینکه درخواستی درحال اجرا هست و همچنین وقتی که اون درخواست کارش تمام شد برای فهمیدن اینکه اجرا آزاد شده داشته باشیم و هرگز در یک زمان دو درخواست اجرا نشن. یعنی فرضا اگر دو درخواست در صف انتظار اجرا هستن و بعد درخواست درحال اجرای قبلی کارش تموم میشه، باید فقط یکی از این درخواست های درحال انتظار وارد حالت اجرا بشه و دیگری باید همچنان منتظر بمونه.
ما برای این کار از ایجاد و حذف یک فایل با نام مشترک استفاده میکنیم که نقش یک Lock یا قفل رو ایفا میکنه. وقتی یک درخواست اجرا میشه اول چک میکنه آیا فایل Lock وجود داره یا نه، اگر وجود داشته باشه میفهمه که درخواست دیگری درحال اجرا هست که اون فایل Lock رو ایجاد کرده (و هنوز به انتهای کار خودش نرسیده که اون رو دلیت کنه) بعد مثلا هر یک ثانیه چک میکنه تا ببینه فایل Lock دلیت شده یا نه، و هروقت فایل Lock وجود نداشت (دلیت شده بود) خودش یک فایل Lock ایجاد میکنه تا به درخواست های دیگر بگه که من در حال اجرا هستم و شما باید منتظر بمونید.
البته پیاده سازی این سیستم به همین سرراستی نیست و چند مورد جزییات و ظرافت داره که باید درنظر گرفت و براشون تمهید کرد.

بعدا یک کد مثال پایه ای از چنین الگوریتمی رو درج میکنم.
میتونید فعلا مطالب رو بررسی کنید و اگر مشکل، سوال، یا پیشنهادی داشتید مطرح کنید.

[Metal Gear Solid]

در حالت فایلی که میگید ممکنه درخواست ها به حدی زیاد باشه که دو درخواست دقیقاً در یک زمان رخ بدن و ایجاد فایل هم در یک زمان انجام بگیره و سایر مشکلاتش
برای رفع این مشکل میشه برای یک سری از اعمال از یک فایل و یک سری دیگه از فایل دیگه استفاده کرد. یعنی تعداد درخواست ها رو بین فایل های لاک تقسیم کرد. مثلا برای ثبت نام یک فایل مجزا باشه که اگر وجود داشته باشه ( Lock ) هر کاربری درخواست ثبت نام داشته باشه تا باز شدن فایل یا نبود فایل صبر کنه
همین کار رو به صورت مجزا برای ورود کاربران به سایت انجام داد.
یا نمیدونم آدرس آیپی ها رو تقسیم کرد به فایل های مجزا و هر روش دیگه!
در کل تقسیم کردن میتونه از مشکل همزمان اجرا شدن درخواست ها کمی جلوگیری کنه.

[alismith]

سلام

خیلی ممنون از پاسخی که دادید ، اما من باز چندتا سوال دارم :

1- اینکه میگید فایل lock یعنی دقیقا یک فایل درست کنیم؟ (چی فایلی!!!)
2- این روش ترافیک سرور را زیاد نمی کند
3- خوب اگر هم این روش درست باشد ، درست کردن فایل و انجام عملیات login توسط php که زمانی را نمی گیرد کامپیوتر تمام این کارها را در چند ثانیه انجام می دهد. اینطور نیست؟
4- لطفا اگر این روش را به وسیله sleep پیاده سازی می کنید تا وقت بیشتری بگیرد (مطابق فرمایشات شما) ، این کار باید با چه ساختاری انجام شود ؟ مثلا google یا yahoo هم همین کار را می کنند؟

خیلی ممنون میشم اگر لطف کنید که این ساختار رو با code نویسی بیشتر توضیح بدید

البته در رابطه با مسدود سازی ip هم شما می تونید مثلا ip رو مسدود کنید بعد یک ایمیل فعال سازی account به کاربر واقعی بفرستید و بعد با پرسش سوالات امنیتی کاربر را login کنید
این نظر من بود شما اساتید بهتر می دونید:چشمک:

خیلی ممنون


موفق باشید

[eAmin]

اما یه اشکال بنظرم رسید!
فرض کنیم دو تلاش برای لاگین بصورت کاملا همزمان اجرا بشن.
حالا هردوی این اسکریپت ها چک میکنن که آیا فایل Lock وجود داره یا نه، و این بخش برنامه در هردو بصورت همزمان اجرا میشه. هردوی اونا میبینن که فایل Lock وجود نداره و هر دو همزمان اقدام به ایجاد فایل Lock میکنن و بقیهء فرایند لاگین در اونها هم همزمان اجرا میشه. درحالیکه باید فقط یک برنامه در واحد زمان اجرا بشه. تعداد این اسکریپت های همزمان میتونه حتی از دو تا هم بیشتر باشه.

باید یه راهکاری هم برای حل این اشکال بیاندیشیم.
این قضیه منتفیه.
در وب سرور Apache برای هردرخواست یک Thread درنظر گرفته میشه و طبیعتا هر thread بعد از thread قبلی اجرا میشه.

روش فایل Lock هم روش جالبیه، از این روش در بعضی از جاهای لینوکس و Mac OSX استفاده شده. مثلا در قسمت Repository (مخزنهای نرم افزاری) بهنگام آپدیت و انجام دادن عملیات مختلف از روش های مشابه فایل Lock استفاده شده.

[eshpilen]

در حالت فایلی که میگید ممکنه درخواست ها به حدی زیاد باشه که دو درخواست دقیقاً در یک زمان رخ بدن و ایجاد فایل هم در یک زمان انجام بگیره و سایر مشکلاتش
برای رفع این مشکل میشه برای یک سری از اعمال از یک فایل و یک سری دیگه از فایل دیگه استفاده کرد. یعنی تعداد درخواست ها رو بین فایل های لاک تقسیم کرد. مثلا برای ثبت نام یک فایل مجزا باشه که اگر وجود داشته باشه ( Lock ) هر کاربری درخواست ثبت نام داشته باشه تا باز شدن فایل یا نبود فایل صبر کنه
همین کار رو به صورت مجزا برای ورود کاربران به سایت انجام داد.
یا نمیدونم آدرس آیپی ها رو تقسیم کرد به فایل های مجزا و هر روش دیگه!
در کل تقسیم کردن میتونه از مشکل همزمان اجرا شدن درخواست ها کمی جلوگیری کنه.
روش پیشنهادی شما برام نامفهوم بود. اگر خواستید میتونید نمونه کد بذارید.
ولی بهرحال این مشکل رو با استفاده از مد x در تابع fopen (http://php.net/manual/en/function.fopen.php) حل کردم. این فلگ باعث میشه:
If the file already exists, the fopen() call will fail by returning FALSE
چون ایجاد فایل فرایندی اتمیک هست بنابراین حتی اگر 100 برنامه بصورت کاملا همزمان برای ایجاد یک فایل مشترک اقدام کنن، فقط دستور fopen یکی از اونا موفق میشه و بقیه false برمیگردونن.

[eshpilen]

این قضیه منتفیه.
در وب سرور Apache برای هردرخواست یک Thread درنظر گرفته میشه و طبیعتا هر thread بعد از thread قبلی اجرا میشه.

عزیز جان این درست، ولی تنها ترتیب ایجاد و اجرای اولیهء تردها روی این مسئله تاثیر نداره.
خطها/دستورات برنامه هایی که در هر ترد اجرا میشن میتونن با توجه به بار لحظه ای سیستم و پردازشهای دیگر و Priority پراسسهای مختلف و کلی مسائل دیگه که در کنترل و آگاهی برنامه نیستن در زمانهای متفاوتی اجرا بشن. در برنامه نویسی مالتی ترد همیشه باید به این مسئله توجه داشت و باید فرض کرد که هر دستور و هر ترد حتی بعد از اجرا ممکنه در زمانهای مختلفی اجرا بشن و نمیشه فرض زمانبندی و ترتیب اجرای ثابتی رو داشت.

بنابراین فرضا ترد 1 و 2 رو درنظر بگیرید که با اختلاف زمانی کمی ایجاد شدن (هرچند حتی اختلاف زمان ناچیز هم ملاک و نیاز نیست)، ترد 1 دستور file_exists("lock") رو اجرا میکنه، اما تضمینی وجود نداره بلافاصله بعد از این دستور و قبل از اینکه دستور file_exists("lock") ترد 2 اجرا بشه دستورات بعدی ترد 1 اجرا بشن و به فرمان ایجاد فایل برسه، بنابراین ترد 2 میتونه قبل از اینکه ترد 1 موفق به ایجاد فایل Lock بشه دستور file_exists رو اجرا بکنه؛ در نتیجه ترد 1 و 2 هردو برای ایجاد فایل Lock اقدام خواهند کرد، اما فقط یکی از اونا عملا باعث ایجاد فایل میشه. ما باید مکانیزمی داشته باشیم که هر ترد بتونه بفهمه آیا واقعا فرمان ایجاد فایل خودش فایل رو برای اولین بار ایجاد کرده یا خیر.
برای رفع این مشکل، بنده از مد x در تابع fopen استفاده کردم که باعث میشه اگر فایل از قبل وجود داشته باشه، fopen مقدار false رو برگردونه.


روش فایل Lock هم روش جالبیه، از این روش در بعضی از جاهای لینوکس و Mac OSX استفاده شده. مثلا در قسمت Repository (مخزنهای نرم افزاری) بهنگام آپدیت و انجام دادن عملیات مختلف از روش های مشابه فایل Lock استفاده شده. بله این روش بخاطر سادگیش و اتمیک بودن اینطور عملیات در سیستم فایل زیاد استفاده میشه.
البته همونطور که دیدید، نکات ظریفی داره و هر پیاده سازی ای لزوما ایمن نیست (پیاده سازی های اشتباه که دچار ضعف Race condition بودن حتی در نرم افزارهای معروف بی سابقه نیستن). پیاده سازی باید حساب شده و با درنظر گرفتن تمام جوانب باشه.

[eshpilen]

1- اینکه میگید فایل lock یعنی دقیقا یک فایل درست کنیم؟ (چی فایلی!!!)

این فایل وسیلهء ارتباطی بین پراسسها/تردها هست. هر پراسسی که فایل رو میبینه متوجه میشه که پراسس دیگری درحال اجراست و منتظر میمونه تا اون پراسس کارش رو تموم کنه و فایل رو دلیت کنه.

2- این روش ترافیک سرور را زیاد نمی کنددر بعضی شرایط ممکنه. البته تحلیلش پیچیده هست و الان حضور ذهن ندارم.
بهرحال هرچیزی هزینه داره. رمزنگاری هزینه داره، امنیت هزینه داره. برای زیبایی و یوزرفرند بودن و امکانات بیشتر سایت خیلی وقتا خیلی بیش از اینها هزینه میشه، تازه مسئلهء امنیت که اغلب از بالاترین اولویت هاست.
اما بنده فکر نمیکنم این روش لزوما هزینهء قابل توجهی هم ایجاد بکنه. چون این روش درواقع داره جلوی حمله رو میگیره و وقتی به سیستم حمله بشه اصولا این ترافیک قابل توجه وجود خواهد داشت که در اینصورت چه با این سیستم و چه بدون اون، سیستم تحت فشار خواهد بود. در غیراینصورت فکر نمیکنم این برنامه هزینهء مهمی داشته باشه.


3- خوب اگر هم این روش درست باشد ، درست کردن فایل و انجام عملیات login توسط php که زمانی را نمی گیرد کامپیوتر تمام این کارها را در چند ثانیه انجام می دهد. اینطور نیست؟نکته همین جاست که ما با تابع sleep یک وقفهء زمانی بین ایجاد فایل تا دلیت کردنش، بوجود میاریم.
تا وقتی فایل دلیت نشه برنامه های دیگه مجبور هستن منتظر بمونن.


4- لطفا اگر این روش را به وسیله sleep پیاده سازی می کنید تا وقت بیشتری بگیرد (مطابق فرمایشات شما) ، این کار باید با چه ساختاری انجام شود ؟ مثلا google یا yahoo هم همین کار را می کنند؟بنده جایی چیزی ندیدم و منبعی برای پیاده سازی نداشتم. این روش رو بر اساس دانش و تحلیل خودم طراحی کردم. اما حداقل تا این حد قبلا جاهایی مطالعه کرده بودم که از سیستم فایل بخاطر اتمیک بودنش و فایلهای lock برای مدیریت و ترتیب دسترسی همزمان بین پردازشهای مختلف استفاده میشه.
این بحث رو اینجا مطرح کردم تا هرکس ایده و نمونه کد بهتری داره بذاره تا بررسیش کنیم.


خیلی ممنون میشم اگر لطف کنید که این ساختار رو با code نویسی بیشتر توضیح بدیددر پست بعدی یک نمونه رو درج میکنم.


البته در رابطه با مسدود سازی ip هم شما می تونید مثلا ip رو مسدود کنید بعد یک ایمیل فعال سازی account به کاربر واقعی بفرستید و بعد با پرسش سوالات امنیتی کاربر را login کنید
این نظر من بود شما اساتید بهتر می دونید:چشمک:بنظرم ایدهء بدی نیست شاید بعضی جاها بشه ازش استفاده هایی کرد.
اما همچنان هکرها میتونن اکانت کاربران رو قفل کنن. فرض کنید حمله با فواصل کوتاه تکرار بشه، در اینصورت به فرض هم که کاربر بتونه لاگین کنه دوباره بعد از مدت کوتاهی امکان لاگین از کاربر گرفته میشه و دوباره باید بره به ایمیلش و فعال سازی کنه (البته اگر نیاز به لاگین دوباره باشه).
ضمنا حالا اگر به ایمیل کاربر هم حمله شد، طرف باید چکار کنه؟ لابد یه ایمیل فعال سازی هم بابت اون ارسال بشه به یه ایمیل دیگه :متفکر:
البته درکل ایدهء شما رو اگر گسترش بدیم و با اجزای دیگری ترکیب کنیم فکر میکنم در بعضی برنامه ها و شرایط بشه باهاش کارهای خوبی انجام داد.
ولی فعلا میخوام بحث سیستم تاخیر زمانی رو به جایی برسونم و روی چیز دیگه وقت و انرژی خاصی صرف نمیکنم.

و بعد با پرسش سوالات امنیتی کاربر را login کنید
فکر نمیکنم به سوال امنیتی نیازی باشه. لینک/کد فعال سازی کافیه.

[eshpilen]

این یه نمونه از سیستم تاخیر زمانی با استفاده از Lock file که تا اینجا درست کردم:


<?php

ignore_user_abort(true);
set_time_limit(60); // needed for testing case

for($i=0; $i<256; $i++) echo " "; // needed for some browsers to start to show content incrementally

function echo_flush($msg) {
echo $msg;
@ ob_flush(); flush();
}

echo "<pre>";
echo_flush("start\n");

while(true) {
$i=0;
while(file_exists("lock")) {
echo_flush("lock file exists | ");
clearstatcache(); // very important for the following check
if((time()-filemtime('lock')) > 10) {
// lock file too old; seems orphaned!
// we should log this incident and probably send an email to admin - it can be the sign of a bug in some situations
echo_flush("\nlock file too old\ndeleting the lock file...\n");
unlink("lock");
echo_flush("lock file deleted\n");
break;
}
if(++$i%5==0) echo "\n"; // just for output formatting
sleep(1);
}
echo_flush("\nlock file does not exist: ".date('H:i:s')."\n");
echo_flush("attempting to create the lock file...\n");

sleep(5); // temporary sleep for testing the algorithm

if(@ fopen("lock", "x")) {
echo_flush("lock file created\n");
break;
}
else echo_flush("lock file creation failed\n"); // apparently, another request preempted in obtaining the lock
}

// login proccess
echo_flush("\nlogin process executed\n\n");
// login proccess
sleep(1); // this is the sleep that makes the needed time to make brute force attacks slow

echo_flush("deleting the lock file...\n");

sleep(5); // temporary sleep for testing the algorithm

if(file_exists("lock")) {
unlink("lock");
echo_flush("lock file deleted\n");
}
else echo_flush("Error: lock file does not exist!\nwatch for a bug in the algorithm.\n");

echo_flush("\nfinish: ".date('H:i:s'));

echo "</pre>";

?>

این کد رو در سه فایل با نامهای مختلف ذخیره کنید و هر سه فایل رو در مرورگر اجرا کنید (سعی کنید حداکثر ظرف چند ثانیه همهء صفحات رو باز کنید تا بین باز کردن صفحات بیش از حد فاصله نیفته و بشه کارکرد برنامه رو درحالت درخواستهای همزمان مشاهده کرد).
البته بنده دو دستور sleep اضافه با تاخیر 5 ثانیه ای به برنامه اضافه کردم تا اجرای دستورات برنامه ها اونقدری طول بکشه تا بشه شرایط درخواست های همزمان رو شبیه سازی و مشاهده کرد. در موقع استفادهء واقعی باید اون دو sleep رو حذف کرد و فقط دستور sleep یک ثانیه ای باقی بمونه (البته این زمان رو هم باید فکر کرد شاید بهتر باشه بیشتر یا کمترش کنیم).

ضمنا این کد فقط برای تست و نشون دادن طرز کار کلی الگوریتم هست. در شرایط واقعی احتمالا میخوایم که قفل بر اساس نام کاربری لاگین و احتمالا بعلاوه بر اساس IP باشه. یعنی نام فایل lock که برنامه ایجاد میکنه بر اساس نام کاربری باشه. اگر محدودیت بر اساس IP هم ایجاد کنیم، یک فایل lock به ازای هر IP هم خواهیم داشت که اسم این فایل مثلا همون آدرس IP خواهد بود. بنابراین برنامه مثلا اول قفل نام کاربری رو باید بدست بیاره، بعد از اینکه قفل نام کاربری رو گرفته قفل IP رو باید بدست بیاره و بعد از اجرا باید هر دو قفل رو آزاد کنه.
توجه کنید که اگر محدودیت بر اساس نام کاربری نباشه، مثلا 5 نفر که بصورت تقریبا همزمان اقدام به لاگین کنن، نفر آخری که نوبتش میرسه حدود 5 ثانیه منتظر مونده. پس اگر 50 نفر همزمان باشن 50 ثانیه و ... .

---------------------------------
ویرایش:
الان داشتم منبع (https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks) رو نگاه میکردم، دیدم یک پارامتر رندوم رو وارد مقدار تاخیر زمانی کرده. و این نکته ای بود که بهش دقت نکرده بودم.
مثلا این خط از کد مثالش به زبان سی شارپ:
Thread.Sleep(rand.Next(minSeconds, maxSeconds) * 1000);
حالا اینکه مقدار minSeconds و maxSeconds باید در چه حدودی باشه اشاره ای نکرده. منم دنبال همین بودم که ببینم زمان پیشنهادی این منبع چقدر هست.
اما عوضش نکته ای که از قلم انداخته بودم رو دیدم که متغییر بودن زمان تاخیر هست.
دقیقا نمیدونم این زمان متغییر رندوم برای چیه و تا چه حدی مهمه. باید سرفرصت بیشتر روش فکر کنم. بهرحال گفتم فعلا مطلب تاپیک رو از نظر فنی کامل کنم. یعنی اگر ما بخوایم این سیستم رو پیاده سازی کنیم احتمالا باید میزان تاخیر زمانی رو هم بصورت متغییر و رندوم در یک بازه تعیین کنیم. بدیهی هست که هیچ کار سختی هم نیست؛ کد برناممون فقط چند خط و دستور بیشتر میشه.

[Bahram0110]

شما چرا اینقد قضیه رو پیچیده می کنید؟ حتی گوگل هم مثل شما فکر نمی کنه!


یک کد captcha بنویسید با فونت های مختلف (هر بار لود یک فونت تصادفی لود بشه)
اگر کاربران شما همه ایرانی هستند از اعداد فارسی استفاده کنید
هر نام کاربری در x دقیقه فقط y بار می تونه اشتباه login کنه (این مورد دلخواه هست)! نیازی نیست ip رو قفل کنید
نیازی نیست فایل های جداگانه برای هر کاربر ایجاد کنید
کد رو اونقد ناخوانا نکنید که کاربر نتونه بخونه. ممکنه چشم بازدید کننده ضعیف باشه
کد رو طولانی نکنید، 3 تا 4 کاراکتر هم کافیه


نمونه (http://www.talahost.com/security.gif)

[eshpilen]

شما چرا اینقد قضیه رو پیچیده می کنید؟ حتی گوگل هم مثل شما فکر نمی کنه!شما از کجا مطمئنید؟ همه جاش رو تست کردید؟ از ساختار داخلی برنامه هاشون خبر دارید؟ مثلا شاید اونا هم از سیستم تاخیر زمانی استفاده میکنن.
ضمنا این سیستم رو بنده اختراع نکردم و لازم ندونستم، بلکه در یکی از منابع تخصصی امنیت بهش اشاره شده و درکل توصیه میکنه از بیش از یک سیستم و لایهء امنیتی استفاده کنیم: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
ضمنا حالا ما در سایت های معمولی از این سیستم استفاده بکنیم یا نکنیم، بهرحال هر سیستمی یه جایی ممکنه نیاز بشه و بنابراین باید آدم با سیستمهای مختلف آشنایی کافی داشته باشه و بتونه هر نوعش رو پیاده سازی بکنه.


هر نام کاربری در x دقیقه فقط y بار می تونه اشتباه login کنه (این مورد دلخواه هست)! نیازی نیست ip رو قفل کنیدخب کاربر هنوز x دقیقه نشده y بار اشتباه میکنه. حالا چکار میکنید؟ باید مدتی امکان لاگین اون کاربر رو قفل کنید دیگه! این همون سیستم قفل اکانت هست دیگه!!
و قبلا عیب این سیستم رو گفتیم.

[Bahram0110]

معمولا هیچ کس نمیاد وقت خودش رو تلف کنه و برای سایت هایی مانند فروشگاه، تالار، وبلاگ و ... کد امنیتی رو هک کنه (عکس رو به متن تبدیل کنه)
حتی اگر شخصی این کار رو انجام بده، با کوچکترین تغییری در کد امنیتی سیستم شخص هک کننده از کار می افته و باید از 0 شروع کنه. برای سایت هایی مانند گوگل و یاهو و ... واجب هست که روی عکس کار کنند. چون کاربران این سایت ها از سراسر دنیا هستند، اطلاعات مهمی پشت لاگین نهفته شده، افراد زیادی قصد نفوذ دارند و ...
شما می خواهید بار اضافی بذارید رو سیستم که چی بشه؟

این مطلبی که نوشتم واضح هست:
هر نام کاربری در x دقیقه فقط y بار می تونه اشتباه login کنه
من هم گفتم یوزر کاربر قفل بشه چیزی غیر از این که نگفتم.

[MMSHFE]

به نظرم اسلايدرهاي jQuery و... هم قابل اعتماد نيستن چون ممكنه سمت كاربر غيرفعال بشن (كلاً JavaScript ممكنه غيرفعال بشه) و درنتيجه اگه سايت ما به اين امكانات وابسته باشه، عملاً از كار خواهد افتاد. بايد روشي رو انتخاب كنيم كه همه كاربران بتونن ازش استفاده كنن.

[eshpilen]

شما می خواهید بار اضافی بذارید رو سیستم که چی بشه؟

بنظر من این سیستم برای یک سایت معمولی بار اضافی چندانی نداره. چون این عملیات فقط برای لاگین اجرا میشه و همزمان تعداد زیادی کاربر لاگین نمیکنن. فایلهای Lock هم به همین نسبتا تعدادشون کم هست و ضمنا فقط در بازهء زمانی کوتاهی بوجود میان و بعد دلیت میشن.
اینکه این رو پیاده سازی کنیم و بصورت یک لایهء اضافی بعد از کپچا قرار بدیم چه مشکلی داره؟
البته منم نمیگم واجبه، ولی میخواستم روی این روش بحث بشه و ببینم چه روشها و الگوریتم هایی پیشنهاد میشه. ولی ظاهرا بیشتر بحث روی کپچا صورت گرفته که به موضوع و هدف تاپیک ربط چندانی نداره.


این مطلبی که نوشتم واضح هست:
هر نام کاربری در x دقیقه فقط y بار می تونه اشتباه login کنه
من هم گفتم یوزر کاربر قفل بشه چیزی غیر از این که نگفتم.
بنده هم گفتم قبلا این روش رو ذکر کردیم و در منبع معرفی شده اشکالاتی رو بهش نسبت داده.
در قسمت Locking Accounts منبعی که معرفی کردم اگر نگاه کنید کامل و روشن توضیح داده که دیگه نیازی به کپی کردن متنش در اینجا نمیبینم.
بهرحال بنده هم قصد ندارم بگم از کدوم روش استفاده کنیم و نکنیم. هر روشی در شرایط و موارد خاصی میتونه مناسب باشه یا نباشه. و بعضی وقتا باید از ترکیبی از چند روش استفاده کرد.
هدف این تاپیک بررسی پیاده سازی صحیح روش تاخیری بوده.

[eshpilen]

به نظرم اسلايدرهاي jQuery و... هم قابل اعتماد نيستن چون ممكنه سمت كاربر غيرفعال بشن (كلاً JavaScript ممكنه غيرفعال بشه) و درنتيجه اگه سايت ما به اين امكانات وابسته باشه، عملاً از كار خواهد افتاد. بايد روشي رو انتخاب كنيم كه همه كاربران بتونن ازش استفاده كنن.
اصلا این روش تا چه امن هست؟ بنظرم کرک کردنش راحتتر از کپچای تصویری هست!
ابداع کنندگان این روش تا چه حد حرفه ای و متخصص بودن و آیا منابع معتبر این روشها رو تایید میکنن؟
بنده فکر میکنم این روشها صرفا راههایی موقتی هستن که برنامه های فعلی رو که برای کرک کردن این روش طراحی نشدن ناکام میکنن، اما میشه راحت تر از کرک کپچای تصویری برنامه ای برای دور زدن روشهایی مثل اسلایدری که کاربر باید درگ کنه تهیه کرد. یعنی فرضا برنامه ای که از کامپوننت مرورگر استفاده میکنه و عملا یک مرورگر صفحه رو در داخل اون برنامه اجرا میکنه و بنابراین جاوااسکریپت هم اجرا میشه و میتونیم Event هایی رو که میخوایم توسط برنامه تولید کنیم. نیازی نیست حتما انسان باشه که یک اسلایدر رو میگیره و میکشه، برنامه میتونه خودش این کار رو انجام بده. در زبانها و فریمورک های امروزی انجام اینطور کارها سخت نیست.
از طرف دیگه فرضا اسلایدر رو که میکشیم بعد چی میشه؟ چه کدی زیر کار اجرا میشه؟ مثلا یک پارامتر توسط AJAX به یک آدرس ارسال میشه. بنابراین اگر اون آدرس و پارامتر رو بتونیم از توی سورس صفحه استخراج کنیم که اصولا کار خیلی راحتتر هم میشه و کافیه برنامه اون آدرس رو با همون پارامتر فراخوانی کنه.
شما میدونید دقیقا طرز کار و ساختار زیرین این اسلایدرها چیه؟

[alismith]

سلام

ببخشید این روشی که شما دوست عزیز eshpilen گفتید در زمانی که کاربر حقیقی login کرده چطور عمل می کنه؟
مثلا به نظر شما درست هستش که بعد چک کردن وضعیت نام کاربری درخواست شده، در فهرست کاربران حاظر در سایت، ما به فردی که قصد داره با همان نام کاربری login کنه پیغامی را نمایش بدیم و اینجوری از ادامه عملیات هم امتناع کنیم (فایل ایجاد نکنیم)؟
و کلا اینکه ما به فردی که این عمل رو انجام داده (هکر) بگیم که کاربر در سایت حضور دارد منطقی هستش؟ (البته در بعضی سایتها خود cms این کار رو به عنوان یکی از امکانات انجام میده )


با تشکر

[eshpilen]

در زمانی که کاربر حقیقی login کرده چطور عمل می کنه؟
در این حالت رفتارش هیچ فرقی نمیکنه.
این سیستم فقط اجرای درخواست های لاگین در واحد زمان رو محدود میکنه. یعنی کرکر نمیتونه فرضا در یک ثانیه 100 تا پسورد رو چک کنه، بلکه فقط یکی در هر ثانیه میتونه چک کنه. البته توجه دارید که کرکرها این کار رو با استفاده از برنامه های مخصوص انجام میدن، وگرنه آدم که نمیتونه به این سرعت کار کنه.


مثلا به نظر شما درست هستش که بعد چک کردن وضعیت نام کاربری درخواست شده، در فهرست کاربران حاظر در سایت، ما به فردی که قصد داره با همان نام کاربری login کنه پیغامی را نمایش بدیم و اینجوری از ادامه عملیات هم امتناع کنیم (فایل ایجاد نکنیم)؟
و کلا اینکه ما به فردی که این عمل رو انجام داده (هکر) بگیم که کاربر در سایت حضور دارد منطقی هستش؟ (البته در بعضی سایتها خود cms این کار رو به عنوان یکی از امکانات انجام میده )
این مسئله بحث دیگریست و باید در هر موردی فکر کرد دید چه رفتاری مناسبه. اگر بخواید همچین چیزی پیاده سازی کنید باید سیستم و الگوریتم مخصوص خودش رو طراحی کنید. بنظرم میتونه ایدهء مکمل جالبی باشه. ولی شاید خیلی هم مهم نباشه!!
ضمنا حالا لازم نیست ما حضور فرد رو به هکر اطلاع بدیم، میتونیم هرچی تلاش برای لاگین میشه دقیقا طوری رفتار کنیم که پسورد غلط بوده. البته این چیزی هست که الان بالبداهه به ذهن بنده رسید و مسائل جانبی احتمالیش رو تحلیل نکردم.

[eshpilen]

تا اینجا دو ایدهء جالب از جانب شما مطرح شده.
یکی اینکه گفتید در روشی که اکانت قفل میشه یک لینک فعال سازی به کاربر بفرستیم تا بتونه با اون در سایت لاگین کنه. به این شکل بنظرم میشه جلوی اشکال قفل کردن عمدی اکانت کاربر و جلوگیری از لاگینش توسط هکر رو برطرف کرد. البته بصورت راحت و سریع نیست، ولی بازم خیلی بهتر از حالت دیگه بنظر میرسه. البته بازم باید بیشتر تحلیل بشه تا دید آیا سایدافکت و محدودیت دیگری داره یا نه. البته اینطور فکر نکنید که این راهکار لزوما بطور کامل و جلوی تمام موارد ضعف این روش رو میگیره، ولی یکی از مهمترین موارد ضعفش رو حداقل تاحد زیادی کاهش میده.

این ایدهء اخیر هم بنظرم از نظر امنیتی بد نیست که اگر کاربر در سایت فعالیت داشت و بعد تلاشی برای لاگین صورت گرفت جلوش گرفته بشه و این مسئله میتونه بصورت یک هشدار امنیتی هم در سیستم لاگ و برای کاربر و ادمین ارسال بشه.
البته چون سیستمهای تعیین حضور کاربر در سایت بر اساس فاصلهء زمانی آخرین فعالیت کاربر عمل میکنن، باید یخورده روش بیشتر فکر کرد و سعی کرد یه سیستم درست و حسابی که اشتباها جلوی تلاش های لاگین مشروع رو نگیره طراحی کرد (بنظرتون میشه؟). یعنی مثلا کاربر که آخرین زمان فعالیتش در سایت 5 دقیقهء پیش بوده اگر خودش باشه که دوباره میخواد لاگین کنه چی؟ بنظرتون ما چطور بفهمیم که طرف کس دیگری هست یا نه؟

[alismith]

به نظر شما لازمه که ما حتما کاربر رو مثلا بعد از 5 دقیقه sign out کنیم؟

البته مثلا اگر در یاهو این اتفاق بیفته یا صفحه مرورگر بسته بشه دوباره از کاربر password میخاد و userName رو نگه میداره!!
مثلا در همین انجمن من اگه خروج نزنم شاید بعد از مدتی من رو off نشون بده اما من هنوز در سیستم هستم و می تونم به اطلاعاتم دسترسی داشته باشم و پست بفرستم. به نظر شما در این روش از cookie استفاده می کنند؟
اگر اینطور هست امکانش هست که در این سیستم هم استفاده بشه؟ از لحاظ امنیتی میگم؟
کلا اگه ما ساختار درستی برای log in نگه داشتن کاربر داشته باشیم می تونیم روی مسائل دیگر هم کنترل قابل قبولی داشته باشیم
ولی حالا چه ما با database یا cookie و موارد دیگر وضعیت کاربر را کنترل کنیم باز طبق الگوریتم درستی که خودمون نوشتیم کاربر بعد از مدتی از سیستم خارج میشه حتی اگر خودش اینکار رو نکنه پس در این حالت login کردن دوباره کاربر باید منطقی باشه و باز می تونیم از همین روش تاخییر زمانی ای که شما لطف کردید و توضیح دادید برای احراز هویت کاربر حقیقی استفاده کنیم (یعنی همون کنترل تعداد درخواستها) و در خوش بینانه ترین حالت کاربر حقیقی با اطلاعات درست login می کند

اینطور نیست؟ :متفکر:

[eshpilen]

به نظر شما لازمه که ما حتما کاربر رو مثلا بعد از 5 دقیقه sign out کنیم؟ما sign out نمیکنیم. فقط فرض میکنیم که از سایت رفته.
ممکنه کاربر دوباره برگرده و نیازی به لاگین مجدد نداره، چون اطلاعات لازم برای احراز هویتش در کوکی ذخیره شده.
اما ممکنه موقعی که کاربر برمیگرده، کوکی های مرورگرش رو پاک کرده باشه یا از مرورگر یا سیستم دیگری استفاده میکنه و بنابراین نیاز داره مجددا لاگین کنه.

[alismith]

خوب وقتی که دوباره باید login کنه یعنی اینکه ما cookie رو چک کردیم و میدونیم که پاک شده یا session به دلیل بسته شدن صفحه سایت از بین رفته پس الان فکر نکنم مشکلی باشه چون خلاصه کاربر واقعی هم می تونه برای login اقدام کنه دیگه !

البته یک سوال برام پیش اومد در رابطه با session ها مثلا ما میگیم اگر در عملیات login از cookie استفاده نکنیم و بعد مرورگر رو ببندیم و حتی از خروج هم استفاده نکنیم session ها پاک می شوند این قضیه تا چه حد درست هست؟

مثلا در رابطه با cookie ما چه زمانی رو برای login بودن فرد قرار بدیم بهتره؟
و یک سوال دیگه که شاید مبتدیانه هم باشه اینکه اگر session از بین بره، چطوری می تونیم در موارد بعدی که کاربر به سایت مراجعه می کنه از cookie استفاده کنیم تا کاربر login نمایش داده بشه؟
و این کار درست هستش که ما در زمانی که از cookie استفاده می کنیم مقادیر session هم با مقادیر موجود در cookie تنظیم کنیم ؟ مثلا نام کاربری و پسورد؟
اصلا در cookie معمولا چه اطلاعاتی ذخیره می کنند؟ چون روی سیستم کاربر هستش دیگه کلا منطقی هستش که در login هم از این روش استفاده کنیم و اطلاعات مهمی در cookie ذخیره کنیم؟

با تشکر

خیلی ممنون

[eshpilen]

خوب وقتی که دوباره باید login کنه یعنی اینکه ما cookie رو چک کردیم و میدونیم که پاک شده یا session به دلیل بسته شدن صفحه سایت از بین رفته پس الان فکر نکنم مشکلی باشه چون خلاصه کاربر واقعی هم می تونه برای login اقدام کنه دیگه !

چی میگی تو من بالاخره نفهمیدم.
سعی کن توضیح که میدی کامل و دقیق باشه.


البته یک سوال برام پیش اومد در رابطه با session ها مثلا ما میگیم اگر در عملیات login از cookie استفاده نکنیم و بعد مرورگر رو ببندیم و حتی از خروج هم استفاده نکنیم session ها پاک می شوند این قضیه تا چه حد درست هست؟

درحالت عادی اینطوریه. ولی میشه تنظیمش کرد که اینطور نباشه.


مثلا در رابطه با cookie ما چه زمانی رو برای login بودن فرد قرار بدیم بهتره؟
بستگی به کاربرد داره. اگر از نظر امنیتی مهم نباشه میشه تا یک سال هم اتولاگین باشه.
البته این امر بنا به انتخاب خود کاربر هست (گزینهء Remember me).


و یک سوال دیگه که شاید مبتدیانه هم باشه اینکه اگر session از بین بره، چطوری می تونیم در موارد بعدی که کاربر به سایت مراجعه می کنه از cookie استفاده کنیم تا کاربر login نمایش داده بشه؟
در کوکی یک Login key قرار میدیم و با مقدار داخل دیتابیس چک میکنیم.


و این کار درست هستش که ما در زمانی که از cookie استفاده می کنیم مقادیر session هم با مقادیر موجود در cookie تنظیم کنیم ؟ مثلا نام کاربری و پسورد؟
بله؟ مفهوم نبود.


اصلا در cookie معمولا چه اطلاعاتی ذخیره می کنند؟ چون روی سیستم کاربر هستش دیگه کلا منطقی هستش که در login هم از این روش استفاده کنیم و اطلاعات مهمی در cookie ذخیره کنیم؟
خیر اطلاعاتی مثل پسورد خام رو در کوکی سمت کاربر ذخیره نمیکنن. چون به روشهای مختلف ممکنه سرقت بشه.

[alismith]

اما ممکنه موقعی که کاربر برمیگرده، کوکی های مرورگرش رو پاک کرده باشه یا از مرورگر یا سیستم دیگری استفاده میکنه و بنابراین نیاز داره مجددا لاگین کنه.


خوب وقتی که دوباره باید login کنه یعنی اینکه ما cookie رو چک کردیم و میدونیم که پاک شده یا session به دلیل بسته شدن صفحه سایت از بین رفته پس الان فکر نکنم مشکلی باشه چون خلاصه کاربر واقعی هم می تونه برای login اقدام کنه دیگه !


دوست عزیز من می تونم از شما یک خواهشی داشته باشم ؟
به نظر شما برای یک سیستم login باید چه لایه های امنیتی قرار داد و اطلاعات login مثلا در با چه روش هایی و در چه قالبهایی ذخیره بشوند مناسب و منطقی هستش؟
مثلا session که در دیتابیس ذخیره میشه - کوکی - یا حتی استفاده از sha1 و md5
و یک سوال دیگه چه اطلاعاتی باید هش بشوند و چطوری می تونیم از این اطلاعات در بالا بردن امنیت سیستم استفاده کرد؟


با تشکر

[eshpilen]

شرمنده سوالات شما خیلی کلی هستن. بنده وقت ندارم برای توضیحات گسترده و آموزش.
اگر سوالات جزیی و مشکلات عملی در بخشی از برنامه دارید مطرح کنید.

[alismith]

!ok
thanks a lot ;)

[eshpilen]

الان داشتم منبع (https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks) رو نگاه میکردم، دیدم یک پارامتر رندوم رو وارد مقدار تاخیر زمانی کرده. و این نکته ای بود که بهش دقت نکرده بودم.
مثلا این خط از کد مثالش به زبان سی شارپ:
Thread.Sleep(rand.Next(minSeconds, maxSeconds) * 1000);
حالا اینکه مقدار minSeconds و maxSeconds باید در چه حدودی باشه اشاره ای نکرده. منم دنبال همین بودم که ببینم زمان پیشنهادی این منبع چقدر هست.
اما عوضش نکته ای که از قلم انداخته بودم رو دیدم که متغییر بودن زمان تاخیر هست.
دقیقا نمیدونم این زمان متغییر رندوم برای چیه و تا چه حدی مهمه. باید سرفرصت بیشتر روش فکر کنم. بهرحال گفتم فعلا مطلب تاپیک رو از نظر فنی کامل کنم. یعنی اگر ما بخوایم این سیستم رو پیاده سازی کنیم احتمالا باید میزان تاخیر زمانی رو هم بصورت متغییر و رندوم در یک بازه تعیین کنیم. بدیهی هست که هیچ کار سختی هم نیست؛ کد برناممون فقط چند خط و دستور بیشتر میشه.

[joker]

كافيه در محلي كه لاگين صورت ميگيره ، به ازاء هر بار تلاش اشتباه براي يك يوزر يك فيلد كانتر در نظر بگيريد ، بعد از 3 بار اشتباه ، كلا روي اون آيدي با اون آي پي به مدت مثلا 5 دقيقه به هر درخواستي كه از همون آي پي براي اون آيدي اومد پيغام خطا بده نه كپچا ميخواد نه كد رندوم نه....

همين روش الان داره روي ياهو استفاده ميشه. منتها ياهو اومده حال داده ميگه بار 3 به بعد با كد كپچا هم همراه بشه اين اعتبار سنجي

[eshpilen]

این روشها رو میدونم و قبلا روش بحث شده.
ولی فکر میکنم سیستم تاخیری هم در بعضی جاها مناسب باشه، ضمنا بعنوان یه لایهء اضافی امنیت بی ضرر بنظر میرسه.
بهرحال این روش در منبعی که معرفی کردم آمده و عیب هایی رو به روشهایی مشابه اونچه شما میگید نسبت داده که البته بی راه هم نمیگه، ولی ممکنه تنها در بعضی کاربردها مهم باشن. ضمنا نویسندهء مقاله یک MVP هست در زمینه طراحی IIS.
این سایت owasp.org رو هم چند وقت پیش کسی معرفی کرد و بنده هم دیدم منبع خوبی هست و تمام انواع حمله ها و روشهای کنترلی رو که معرفی کرده بود مطالعه کردم.


بعد از 3 بار اشتباه ، كلا روي اون آيدي با اون آي پي به مدت مثلا 5 دقيقه به هر درخواستي كه از همون آي پي براي اون آيدي اومد پيغام خطا بده نه كپچا ميخواد نه كد رندوم نه....بنظرم محدود کردن به IP امنیت کافی نمیده. چون کرکرها برنامه هایی استفاده میکنن که میتونن از IP های زیادی بصورت همزمان استفاده کنن (بوسیلهء پراکسی های عمومی زیادی که هست).


همين روش الان داره روي ياهو استفاده ميشه. منتها ياهو اومده حال داده ميگه بار 3 به بعد با كد كپچا هم همراه بشه اين اعتبار سنجي بله کپچا هم روش خوبیه. مطمئنا باید از کپچا هم استفاده کرد. روش تاخیری برای این نیست که فقط محدود به همون بشید. میشه همزمان چند روش رو ترکیب کرد.