آنچه درمورد ایجاد محدودیت بر اساس IP باید بدانید!

[eshpilen]

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

1) ممکنه همزمان بیش از یک نفر از یک IP استفاده کنن.
- بطور مثال در یک LAN یا اینترانت که همهء Node ها از یک اتصال اینترنت مشترک استفاده میکنن (یک سناریوی کاملا استاندارد و متداول)
- بطور مثال وقتی عده ای از یک پراکسی سرور استفاده میکنن (که میتونه تصادفا پیش بیاد یا بخاطر سیستم خاصی باشه).
- بطور مثال موقعی که از نرم افزارهای فیلترشکن، VPN، و Anonymizer و اینها استفاده میشه بازهم امکان استفادهء همزمان چند نفر از هر IP وجود داره.

2) یک نفر میتونه براحتی و سرعت کافی IP خودش رو عوض کنه.
- بطور مثال با دیسکانکت کردن و کانکت کردن مجدد مودم (هردوی دایالاپ و ADSL).
- بطور مثال میتونه از سایتهای پراکسی یا پراکسی سرور استفاده کنه.
- بطور مثال میتونه از فیلترشکن، VPN و Anonymizer استفاده کنه. خیلی از این نرم افزارها در هر بار اجرا یا کانکت مجدد شدن به شبکهء خودشون یک IP متفاوت دارن، و بعضی از اونا ممکنه حتی هر درخواست در یک نشست رو هم با IP متفاوتی ارسال کنن.

3) امکان استفاده از تعداد زیاد یا بسیار زیادی IP هم وجود داره.
- بطور مثال موقعی که حمله از طریق botnet انجام بشه، تعداد IP هایی که میتونن استفاده بشن (حتی بصورت همزمان) میتونه سر به فلک بزنه. قابل توجه هست که بدونید botnet های مختلفی که وجود دارن دارای از 10 هزار تا 30 میلیون bot هستند! (به جدول انتهای مقالهء ویکیپدیا (http://en.wikipedia.org/wiki/Botnet) مراجعه کنید).
- بطور مثال نرم افزارهایی وجود دارن که از لیست بزرگی از پراکسی سرورها برای ارسال درخواست ها استفاده میکنن و قادر هستن درخواستها رو بصورت خودکار با سرعت بالا از IP های متفاوتی ارسال کنن.

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

در خیلی موارد ما اصلا نیازی نداریم هیچ کار خاصی به IP داشته باشیم.
بطور مثال میشه یک اکانت رو بعد از چند بار تلاش ناموفق قفل کرد. برای این کار با IP کاری نداریم و نباید داشته باشیم. بطور مثال یاهو در لاگین ایمیل خودش که عملا تست کردم اینطور عمل میکنه:
- تا چند بار لاگین ناموفق برای یک اکانت اجازه داده میشه.
- بعد از چند بار اشتباه، برای دفعات بعدی کپچا گرفته میشه.
- بعد از چند بار اشتباه باوجود کپچا، اکانت قفل میشه.
البته در قفل مرحلهء اول امکان ورود با استفاده از پاسخ به سوالهای امنیتی وجود داره، اما در بخش سوالات امنیتی هم الگوریتم بالا بکار رفته و سرانجام بعد از تعداد کافی اشتباه، امکان استفاده از سوالات امنیتی هم قفل شده و اکانت بطور کلی برای 12 ساعت قفل میشه.

البته این داستان برای هر اکانت بود. ممکنه یاهو محدودیتی هم روی درخواستهای ارسال شده از هر IP که تلاش میکنه به اکانتهای زیادی وارد بشه داشته باشه. این چیزی هست که تست نکردم و اطلاع ندارم.

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

حداقل همیشه موارد بالا رو که گفتم مدنظر داشته باشید.

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

[eshpilen]

در مورد آیپی اینکه این مورد باعث ظلم به بقیه کاربرهای استفاده کننده از آیپی مشترک میشه درسته. اما یک سری از حملات منجر به این بلاک شدن آیپی میشه. مثلا حملات ddos تنها چیزی که ما داریم ip هست و یا سرویس هایی مثل fail2ban هم آیپی رو بلاک می کنن

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


البته من در مورد بلاک کردن کاربر به این روش هم مخالفم. چون میشه یک نوع از حملات هم این باشه که فقط هدفش قفل کردن اکانت کاربر باشه. قفل حساب کاربر هم نباید اینقدر راحت اتفاق بیافته من با یکی لج می کنم و میام اطلاعات اشتباه میدم تا حساب بسته بشه و جلوی ورود کاربر رو بگیرم و مثلا برای ۱۲ ساعت قفل میشه دوباره بعد از ۱۲ ساعت میام و دوباره تلاش ناموفق تا حساب قفل میشه. باید تدبیر دیگه ای هم باشه که طرف صاحب حساب بتونه حداقل بدون محدودیت زمانی حسابش رو حداقل برای آيپی خودش یا نشست خودش باز کنهخب این رو که من در سیستم خودم با ارسال یک لینک lockdown bypass به ایمیل کاربر چاره کردم. یعنی کاربر میاد میبینه اکانتش قفل شده اما یه گزینه هست که باهاش میره به فرمی که ایمیلش رو وارد میکنه و یک لینک مخصوص بهش ایمیل میشه که بعد با اون میتونه بصورت نامحدود در مدتی که اکانت قفل هست لاگین کنه.
البته این ایده اصلش مال دیگران بوده و من اختراع نکردم.


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

[eshpilen]

یه توضیح دیگه برای کاملتر شدن مطالب قبلی باید بگم.
هر محدودیت و سیستمی رو هرجایی نمیذارن.
البته اگر گذاشتی و سایدافکت نداشت باز مشکل زیادی پیش نمیاد، ولی در خیلی موارد هم اینطور نیست.
یه جایی شما یه کلید رندوم درست میکنی که تعداد حالاتش برابر 2 به توان 128 هست. اینجا اصلا نیازی به محدودیتی نیست، چون عمرا کسی روی لوکال هم نمیتونه چنین چیزی رو Brute-force کنه، چه برسه از طریق اینترنت.
یعنی محاسبات ریاضی و احتمالات نقش دارن.
بعکس یه چیزی مثل اکانت کاربر رو با 6 بار تلاش ناموفق قفل میکنیم.
یا یک IP رو که روی اکانتهای زیادی تلاش میکنه.
چون پسورد کاربران خیلی خیلی ضعیف تر از یک کلید 128 بیتی رندوم هست و با Brute-force سبک یا حدس هم ممکنه کشف بشه.

البته ممکنه دلایل دیگری هم برای ایجاد محدودیت روی درخواستها وجود داشته باشه. من از این دید که به ذهن خودم میرسید گفتم. چون فکر میکنم خیلی ها شاید اینا رو ندونن و محاسبه نکنن. شخصا چون در زمینهء رمزنگاری مطالعه زیاد داشتم میدونم حداقل چه تعداد حالتهای ممکنی باید باشه تا نشه Brute-force کرد.
یک بار پیشنهاد یک salt رو دادم که طولش چقدر باشه و از چه کاراکترهایی تشکیل شده باشه، یکی از دوستان قدیمی که اتفاقا در زمینهء هک و کشف باگهای امنیتی هم وارد بود و سابقه ای داشت ازم ایراد گرفت و یک طور دیگش پیشنهاد داد، ولی با یک محاسبهء ساده بهش نشون دادم که مال من درواقع تعداد حالتهای خیلی بیشتری از مال خودش داره و کاملا هم امنه.
حالا چه تعداد افرادی واقعا مشخصات یک salt مناسب رو حساب میکنن؟ هرکس از راه میرسه همینطوری چنتا کاراکتر رندوم ردیف میکنه یا از روی دیگران کپی میکنه. هیچ محاسبه و اطلاعات موثقی ندارن در این مورد.
البته salt من دیگه آخرین حدش بود که خواستم هیچ شکی در امنیتش نباشه - اندازهء یه هش md5 حالت داشت :D
یعنی همون 2 به توان 128. خب در این مورد چون هزینهء خاصی نداره اشکالی هم نداره اگر بیش از حد نیاز هم گرفتی. به ازای هر اکانت چند بایت بیشتر ذخیره کردن که امروزه روز هزینه ای نیست. عوضش از امنیتش در حال و آینده تاجاییکه میشه مطمئن خواهی بود.

البته همین که تابع رندومی که ازش استفاده میکنی تا چه حد امنیت داره خودش یه بحث دیگه هست.
مثلا آیا mt_rand برای تمام کاربردها امنیت کافی داره؟
یکسری الگوریتم و توابع مخصوص تولید اعداد تصادفی هستن که بهشون بقدر کافی میشه اتکا کرد. یعنی مخصوص کاربردهای رمزنگاری/امنیتی هستن.
من همهء این مسائل رو مدنظر دارم.
مثلا در لیست To Do یه مواردی برای قویتر کردن و اطمینان از کیفیت رشته های رندومی که برنامه تولید و بعنوان کلید و غیره استفاده میکنم دارم.

[pejman_view]

سلام

من یک سایت دارم که استفاده از چند اکانت در یک شبکه داخلی طبق ضوابطی ممنوع است- اما نمی توانم بگم که این شبکه واقعاً شبکه LAN است یا پراکسی چون برای پراکسی مشکلی نداریم طبق قوانین اما برای LAN چرا.
حالا جالبی قضیه اینه از تمامی کشورها مخاطب سایتم هم هستند.

من خیلی از شرایط را در نظر گرفتم :
1- سایت رجوع دهنده
2- آی پی کشوری که قبلاً لاگین می کرده و حالا لاگین می کنه
3- ریزولوشن مانیتور
4- سیستم عامل
اما بازهم به اطلاعات دقیق نمی رسم خیلی این مبحث شناسایی افراد در اینترنت پیچیده و مشکل است.

با آرزوی موفقیت.

[ravand]

شما اين همه حرف زدي ميتونستي حرف هات رو خلاصه تر هم بگي. يكي از مباحثي كه در افزايش بازديد از سايت هست اينه كه كسي كه در سايت مطلب مي نويسه حرف هاش رو خلاصه تر بگه. :لبخند:
بگذريم من فقط يه نكته ميخواستم بگم اينكه با رئيس سايت الفورآي چت مي كردم بهم گفت 20 روش وجود داره كه بشه آي پي افراد رو بدست آورد!
يه بحثي هم هست به نام آي پي واقعي. در اين مورد تحقيق كنيد ما رو هم خبر كنيد خدا خيرتون بده.
همين . :لبخند:

[eshpilen]

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

[mbf5923]

نظر دوستان در مورد بن کردن کاربر با MAC ADDRESS که همیشه یکتا هست چیه؟اینجوری فقط همون کاربر دسترسیش قطع میشه و بقیه دسترسی دارن

[eshpilen]

یه وبسایت معمولی MAC ADDRESS کاربر رو از کجا بیاره؟ :متعجب:
این کار از طریق وب و مرورگر بدون پلاگین یا اکتیوایکسی چیزی ممکن نیست تاجاییکه میدونم.
در ضمن مجبور کردن کاربران به این قضیه هم اصلا جالب نیست و خلاف Privacy و امنیت اونهاست.
بنظرم بهتره اینطور رویه ها رو باب نکنیم.

[ravand]

نظر دوستان در مورد بن کردن کاربر با MAC ADDRESS که همیشه یکتا هست چیه؟اینجوری فقط همون کاربر دسترسیش قطع میشه و بقیه دسترسی دارن


اگه شما راهي رو بلدي كه بشه مك آدرس كاربر رو گرفت به ما هم ياد بده. من خودم يه راهي رو براي پيدا كردن مك آدرس پيدا كردم ولي فقط توي خود سيستمم كار ميكرد و روي سايت كار نميكرد. از هر كي پرسيدم گفت فقط توي لوكال كار ميكنه.

[eshpilen]

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

[mbf5923]

این رو ببینید:
http://www.qualitycodes.com/tutorial.php?articleid=19&title=MAC-Address-Using-WMI-on-Internet-Explorer
البته eshpilen درست میگه و باید ACTIVEX نصب بشه من هم حرفی غیر از این نزدم!
اما راه دیگه ای هم هست باید توی جزوه هام بگردم ببینم پیداش میکنم
به این ترتیب بود که:
شما وقتی میخواین آدرسی رو بازدید کنید همونطور که میدونید درخواست شما مراحلی رو طی میکنه مثل ارسال ب ISP ، تبدیل به DNS ، دستیابی به سرور و ...
خوب حالا چطور صفحه HTML برای شما ارسال میشه؟
یکی از الگوریتم ها اگه اشتباه نکنم میگفت مک درخواست دهنده رو از روتر بردار و به همون ریسپونس کن
پس شاید بشه همون رو از روتر گرفت
تست میکنم خبر میدم

[eshpilen]

اون اسکریپت ActiveX جالب بود ولی...
- فقط روی IE کار میکنه.
- از کاربر برای اجرا سوال میکنه و میگه ممکنه خطرناک باشه.
- این کارها از نظر امنیتی درست نیست چون یک اکتیوایکس میتونه روی سیستم کاربر همه کار بکنه (سرقت اطلاعات، خراب کردن فایلها، دسترسی به هر مکان و فایل دلخواه روی هارد، خلاصه هرچیزی). پس بهتره کاربران رو به اینطور رویه ها مجبور نکنید مگر در شرایط خاص کاربرد خاص کاربران خاص و جایی که واقعا مجبور باشید و توجیه منطقی و تخصصی براش وجود داشته باشه، نه بخاطر تفکر و طراحی غلط و تنبلی خودتون در طراحی یک سیستم جایگزین اصولی.
- این کد روی مرورگر کاربرانی که از سیستم عاملهای دیگه مثل لینوکس استفاده میکنن قابل استفاده نیست (چون IE و اکتیوایکس اونجا تقریبا معنا و وجود نداره).
- در نهایت هم شما دارید اطلاعاتی رو از سمت کلاینت اونم با اسکریپت میگیرید و همهء اینطور اطلاعات که از سمت کلاینت میان حالا سخت‌تر یا آسان تر بسته به مورد، کاملا قابل جعل هستن. یعنی نمیتونید به این اتکا کنید که اطلاعاتی که از سمت کلاینت دریافت کردید واقعیت داره و جعلی نیست. پس اینهمه زحمت و هزینه برای چی؟!
- لطفا یک فناوری و سیستم عامل انحصاری و مرورگر انحصاری رو هم بر دنیای آزاد حاکم نکنید و به آزادی و تنوع و غنای رایانه و اینترنت و برنامه نویسی صدمه نزنید.
- استفاده از ActiveX مدتهاست که در وب تقریبا منسوخ شده (البته به گمانم یکسری کاربردهای خیلی محدود هنوز وجود دارن - مثل آنتی ویروس آنلاین). این عدم استفاده طبیعتا به دلایلی هست که تا اینجا گفتیم.


یکی از الگوریتم ها اگه اشتباه نکنم میگفت مک درخواست دهنده رو از روتر بردار و به همون ریسپونس کن
پس شاید بشه همون رو از روتر گرفتجان؟!!
مک کاربر سایت رو از روتر بگیری؟
کدام روتر؟
یعنی MAC کاربر همینطور وارد اینترنت میشه؟
اگر هم چنین چیزی خوندی یحتمل درمورد محیط LAN و اینترانت بوده.

[mbf5923]

مک کاربر سایت رو از روتر بگیری؟
کدام روتر؟
برای Lan به سادگی میشه اینکار رو انجام داد
نه تا اونجا که یادمه در اینترنت بود ولی دقیق یادم نیست چی بود شاید OSPF نمیدونم باید ببینم

[eshpilen]

منظورت Open Shortest Path First هست؟
یحتمل منظور MAC خود روترها و رایانه هایی بوده که دیتای اینترنت رو عبور میدن.
منطقی نیست که MAC کاربر وارد اینترنت جهانی بشه. اگر اینطور بود تاحالا همه خبردار بودن و ازش استفاده میکردن.

[alismith]

سلام دوستان

امیدوارم حال همتون خوب باشه :لبخندساده:

آقای eshpilen باز زحمت کشیدن و تحقیقات و مطالعات شخصیشون پیرامون وب رو با ما به اشتراک گذاشتن :لبخندساده:

در رابطه با مسدود کردن IP گفتید و بعد ارسال ایمیل به کاربر و روش کار وب سایت Yahoo

من یک روشی به ذهنم رسید که گفتم خدمت شما و دوستان برنامه نویس و تحلیلگر سیستم های امنیتی عرض کنم (انصافا هم در این زمینه اطلاعات جامع ای دارید دوست عزیز)

من نظرم این هستش :

- کاربر برای دسترسی به حساب کاربری تلاش میکنه (ناموفق)
- دوباره این کار رو انجام میده (ناموفق)
- باز این کار رو انجام میده با کپچا (ناموفق)
- آخرین فرصت برای دسترسی به حساب کاربری با کپچا (ناموفق)

اعمال محدودیت در دسترسی به این حساب کاربری

- کاربر حق login کردن به حساب کاربری خودش نداره
- درصورت درخواست login اگر کلمه عبور درست بود با تایید Email یک لینک دسترسی به Account برای کاربر ارسال میشه
- هنوز کاری به IP کاربر نداریم، اما از بعد ارسال Email، کاربر بعد از درخواست login، بدون انکه کلمه عبور بررسی بشه، با در نظر گرفتن نام کاربری که در لیست کاربران محدود شده است، یک پیغام برای کاربر نمایش داده میشود، با این مضمون که شما حق دسترسی به این حساب کاربری را ندارید
- در اینجا یعنی بعد از ارسال Email حاوی لینک دسترسی، تعداد دفعات درخواست کاربر برای ورود به سایت از طریق فرم login اصلی در یک بازه زمانی خاص به مدتی مشخص کنترل میشه
- کاربر اصلی برای ورود به سایت از اون لینک استفاده می کنه و مدت زمانش بستگی به مدتی داره که حساب مسدود هست و نمی تونه از فرم login استفاده کنه
- این مدت زمان طبق یکسری پارامتر که توسعه دهنده برنامه مد نظر داره مشخص میشه، برای مثال تعداد درخواست ناموفق دسترسی به حساب کاربری بعد از ارسال Email، اینطوری بگم وقتی Email ارسال شد، کاربر اصلی میدونه که حسابش مسدود هستش، پس اون درخواست ها به وسیله شخص دیگری انجام میشه، برای مثال اگر تعداد درخواست ها به 3درخواست در یک روز رسید و این کنترل در طول 1هفته اعمال شد و سیستم بررسی کرد که تعداد درخواست ها به حد خطر یا تحدید نرسیدند، حساب کاربری موقتا فعال میشه.

در رابطه با Email که حاوی لینک دسترسی است :

لینک میتونه کاربر رو به صفحه ای منتقل کنه که در اونجا دو چیز بررسی بشه :

1- Token
2- Password

رمز یا نشانه می تونه رشته یکتا و کد شده ای که از ترکیب (نام کاربری + رشته رندوم با طول رندوم + کلمه عبور کد شده) استفاده میکنه باشه، دراین صورت که کاربری که این کد رو داره تا پسورد صحیح رو وارد نکنه نتونه تو سایت login کنه، برای امنیت بشتر هم میشه اول Token ارسالی رو چک کرد و اگر مجاز بود فرم login رو به کاربر نشون داد تا سیستم اجازه درخواست login به کاربر رو بده و اگر وجود نداشت فقط یک پیغام خطا چاپ کنه

مزایا این روش :

- جلوگیری از ارسال درخواست login توسط هکر بعد از ارسال Email، فقط با چک کردن نام کاربری در فهرست کاربران محدود شده و وضعیت Email دسترسی به Account
- مدیریت درخواست های ورود به سایت نام کاربری مسدود شده، از طریق ایجاد دو روش برای ورود به سایت و شناسایی هکر(فقط تشخیص هکر یا کاربر مزاحم بودن)
- کاهش درخواست های login ناموفق با ایجاد روش دوم برای ورود به سایت و از آن مهم تر بررسی Token ارسالی قبل از نمایش فرم login به کاربر، برای احراز هویت آن
- در این روش نه حساب کاربری کاربر قفل میشه و نه به هکر اجازه درخواست های مداوم برای login ناموفق داده میشه

این روش اگه خیلی هم خوب نباشه، حداقل اگه با دوستاتون لج کردید دیگه به اونا لطمه ای وارد نمیشه:چشمک:

در رابطه با Token و استفاده از اون لینک نا مفهوم برای انسان هم، شاید بشه از cookie استفاده کرد، البته اگر از لحاظ امنیتی و سرقت اطلاعات مانع ای نداشته باشه و به این شرط که کاربر از سیستم خودش همیشه login کنه، در غیر این صورت استفاده از اون لینک الزامی میشه!

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


موفق باشید

[eshpilen]

سیستمی که خودم پیاده کردم اینطوریه:

- 3 بار تلاش لاگین ناموفق
- 3 بار دیگه هم همراه با کپچا
- اکانت برای مدت X قفل میشه (من زمان پیشفرض رو 12 ساعت گذاشتم).

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

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

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

بعدا هم که زمان X تموم شد و اکانت کاربر باز شد اون لینک دسترسی از کار میفته (رکورد و کلید مربوطه رو از دیتابیس حذف میکنیم). بنابراین هر لینک دسترسی فقط برای مدت زمان قفل اکانت قابل استفاده هست.

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