کمک در مورد بستن آی پی در صورت درخواست بیش از حد

[sairon123]

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



if(isset($_COOKIE['login-'.$ip]))
{
$val = intval($_COOKIE['login-'.$ip]);
$val++;
$cookie_name = 'login-'.$ip;
$cookie_time = time()+3600;
setcookie($cookie_name,$val,$cookie_time);
}
else
{
$cookie_name = 'login-'.$ip;
$cookie_value = '1';
$cookie_time = time()+3600;
setcookie($cookie_name,$cookie_value,$cookie_time) ;
}



که اگه کاربر درخواست اشتباه داد یه کوکی ایجاد بشه

حالا تو قسمت بالا این کد رو گذاشتم




if(isset($_COOKIE['login-'.$ip]))
{
$val = intval($_COOKIE['login-'.$ip]);
if($val>3)
{
$check = $val;
}
}

if($check>3)
{
echo 'ip شما بسته شده است....';
}




اگه درخواست اشتباه بیشتر از 3 بار باشه ، ای پی رو می بنده ، حالا این کد تو لوکال اجرا میشه و مشکلی نداره ولی تو هاست اصلا کار نمیکنه
میشه راهنمایی کنید مشکل کجاست ؟

[ravand]

از سشن استفاده کن

[sairon123]

میشه بیشتر توضیح بدین ؟
به سیشن عدد بدم و هر دفه یکی اضافه کنم ؟

[-سیّد-]

استفاده از cookie هیچ ضمانتی برای جلوگیری از سوء استفاده ایجاد نمی‌کنه.
یعنی چی؟ یعنی این که وقتی شما یه کوکی set می‌کنی، این به صورت یه HTTP header به مرورگر کاربر فرستاده می‌شه و مرورگر اون رو ذخیره می‌کنه و توی درخواست بعدی برای شما می‌فرسته. در این حالت مشکلی نیست و همه چیز سر جاش به نظر می‌رسه!
اما کسی که بخواد از سیستم سوء استفاده کنه، می‌تونه به راحتی کوکی رو دور بزنه. چطوری؟ همونطور که گفتم، مقدار کوکی توسط مرورگر به سرور فرستاده می‌شه، یعنی یه مقداریه که client برای سرور می‌فرسته. خوب کاربر به سادگی می‌تونه این مقدار رو عوض کنه و همیشه برای شما ۱ بفرسته و در نتیجه هیچ وقت ip اش بلاک نمی‌شه!

نتیجه‌گیری اخلاقی: کوکی فقط یک راهه برای این که بتونید به خوبی و خوشی با کاربر خوب با همدیگه زندگی مسالمت‌آمیز داشته باشید! و نمی‌شه ازش برای دفع خطرات(!) کاربران خطرناک استفاده کرد!

اگه در همین حد برای شما کفایت می‌کنه که یه کاربر معمولی که بلد نیست مقدار کوکی رو دستکاری کنه، بعد از ۳ بار اشتباه وارد کردن رمز عبور بلاک بشه، می‌تونید از همین روش استفاده کنید. ولی اگه امنیتش براتون مهمه که جلوی هر سوء استفاده‌ای رو (حتی توسط کاربر حرفه‌ای که بلده مقدار کوکی رو عوض کنه) بگیرید، باید از روش‌های دیگه‌ای استفاده کنید.

لطفاً بفرمایید که کدوم یک از حالت‌های بالا در مورد کد شما صدق می‌کنه، تا اگه لازمه در مورد اون توضیح بیشتری بدم.


از سشن استفاده کن
استفاده از session هم مشکلی که گفتم رو حل نمی‌کنه. درسته که داده‌ی session سمت سرور ذخیره می‌شه، ولی برای این که درخواست یه کاربر به session متناظرش map بشه، باید یه session id از سمت کاربر برای سرور فرستاده بشه که به همون روشی که در مورد کوکی گفتم، کاربر حرفه‌ای می‌تونه به راحتی session رو هم دور بزنه.

[sairon123]

ممنون سید جان ، واسه لاگین پنل مدیریت میخواستم
ممنون میشم راهنمایی کنید ؟

[ravand]

استفاده از session هم مشکلی که گفتم رو حل نمی‌کنه. درسته که داده‌ی session سمت سرور ذخیره می‌شه، ولی برای این که درخواست یه کاربر به session متناظرش map بشه، باید یه session id از سمت کاربر برای سرور فرستاده بشه که به همون روشی که در مورد کوکی گفتم، کاربر حرفه‌ای می‌تونه به راحتی session رو هم دور بزنه.

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

[sairon123]

یعنی بهترین راه همون کپچا هست ؟

نظر شما در مورد قفل صفحه چیه ؟ از طریق هاست ، صفحه لاگین رو قفل کنم و تا پسورد رو نزد اصلا کاری نمیشه کرد

ایا این روش امنیت رو تضمین میکنه ؟

[j_naroogha@yahoo.com]

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

[sairon123]

دوستان دیگه نظر ندارن ؟

[freeman99]

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



if(isset($_COOKIE['login-'.$ip]))
{
$val = intval($_COOKIE['login-'.$ip]);
$val++;
$cookie_name = 'login-'.$ip;
$cookie_time = time()+3600;
setcookie($cookie_name,$val,$cookie_time);
}
else
{
$cookie_name = 'login-'.$ip;
$cookie_value = '1';
$cookie_time = time()+3600;
setcookie($cookie_name,$cookie_value,$cookie_time) ;
}



که اگه کاربر درخواست اشتباه داد یه کوکی ایجاد بشه

حالا تو قسمت بالا این کد رو گذاشتم




if(isset($_COOKIE['login-'.$ip]))
{
$val = intval($_COOKIE['login-'.$ip]);
if($val>3)
{
$check = $val;
}
}

if($check>3)
{
echo 'ip شما بسته شده است....';
}




اگه درخواست اشتباه بیشتر از 3 بار باشه ، ای پی رو می بنده ، حالا این کد تو لوکال اجرا میشه و مشکلی نداره ولی تو هاست اصلا کار نمیکنه
میشه راهنمایی کنید مشکل کجاست ؟


حالا این کد تو لوکال اجرا میشه و مشکلی نداره ولی تو هاست اصلا کار نمیکنه
یعنی مشکلش فقط همین بود؟ :لبخند:

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

البته این روشها که با یدونه کوکی و چندتا پیام الکی وانمود کنیم که سیستم هوشمند و حرفه ای و امنی ساختیم واسه گول مالیدن سر کارفرما/مشتری خوبه :لبخند:

[sairon123]

دوست عزیز
1- این پروژه ماله خودمه نه کارفرما ، واسه تمرینه خودمه
2- من که ادعایی نداشتم و ندارم از اینکه این کد خیلی شاخه یا میتونه جلوی امنیت رو بگیره و امنیت رو تضمین میکنه

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

حالا که لطف کردی پیام دادی ، حداقل آخرش یه روش یا راه حل مناسب هم میدادی بد نمیشد و به کسی هم برنمیخورد

[freeman99]

منم نگفتم شما میگی کدت شاخه. واضحه که کار یه مبتدیه. منم نخواستم شما رو مسخره یا توبیخ کنم، فقط خوشمزه صحبت کردم :چشمک:

حالا که اینو گفتی باید بگم این روحیه تحقیق و انتقادپذیری که داری خیلی خوبه و اگر تلاش کنی در آینده میتونی خوب پیشرفت کنی.


حالا که لطف کردی پیام دادی ، حداقل آخرش یه روش یا راه حل مناسب هم میدادی بد نمیشد و به کسی هم برنمیخورد

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

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

[freeman99]

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

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

[sairon123]

اقای اشپیلن ، من چند ماهه وارد برنامه نویسی شدم ، هنوز خیلی کار داره تا حرفه ای شم

من این رو برای حملات brute force می خواستم ، تا جایی که من میدونم و خوندم ، میشه از کد کپچا و یا قفل صفحه از طریق هاست جلوی این حمله رو گرفت ،

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

وقتی داشتم میگشتم یه جا خوندم که برای این که اگه طرف مقابل کوکی رو پاک کرد مشکلی پیش نیاد ، یه فایل ایجاد بشه ، مثلا وقتی کاربر 3 بار رمز و اشتباه وارد کرد ، یه فایل برای طرف ایجاد بشه
و ای پی طرف تو اون فایل ذخیره بشه و از اون طریق ای پی طرف رو ببندیم ، آیا این روش هم مشکل داره ؟؟

بعد حالا یه سوالی ذهنم رو مشغول کرده بود ، حالا که فرصت پیش اومد میپرسم ، خوشجال میشم جواب بدین

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

یه سوال دیگه هم دارم :لبخند:

ایا استفاده از این $_SERVER['HTTP_REFERER'] به امنیت کمک میکنه ؟ اگه مستقیم وارد سایت شد ارور بده

ببخشید که سوال زیاد شد :لبخند:

[sairon123]

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

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

به نظر من انتقاد و بحث هرچه قدر هم تند و خشن باشه باز ارزش داره ، چون آدم تو بحث مشکلات کارشو بفهمه و اون ها رو برطرف کنه خیلی بهتره تا اینکه وارد بازار کار بشه و تو اونجا به مشکل بخوره و
ابروش بره

[freeman99]

وقتی داشتم میگشتم یه جا خوندم که برای این که اگه طرف مقابل کوکی رو پاک کرد مشکلی پیش نیاد ، یه فایل ایجاد بشه ، مثلا وقتی کاربر 3 بار رمز و اشتباه وارد کرد ، یه فایل برای طرف ایجاد بشه
خب اون دو بار قبلی رو از کجا میفهمه؟ توی کوکی باشه که نمیشه چون میشه کوکی رو پاک کرد.


و ای پی طرف تو اون فایل ذخیره بشه و از اون طریق ای پی طرف رو ببندیم ، آیا این روش هم مشکل داره ؟؟
IP رو زرتی نمیبندن، چون IP که فقط مال یه نفر نیست لزوما. اونم با 3 تا تلاش ناموفق!
ولی میشه بعد از چند بار کپچا گرفت.
ما دو نوع قفل داریم. قفل IP و قفل اکانت. قفل اکانت یعنی اگر به یک اکانت در بازهء زمانی مشخصی بیش از تعداد بار مشخصی لاگین ناموفق شده بود اون اکانت برای مدتی قفل میشه و نمیشه بهش لاگین کرد. قفل IP یعنی اگر در بازهء زمانی مشخصی بیش از تعداد بار مشخصی تلاش لاگین ناموفق داشتیم (حالا فرقی نمیکنه به هر اکانت یا اکانتهایی باشه یا اصلا نام کاربری وارد شده در سیستم هم وجود نداشته باشه)، امکان اون IP برای مدتی قفل بشه. البته گفتم که قفل کردن IP میتونه دردسرساز باشه و معمولا باید موقت باشه یا اصلا قفل نکنیم و فقط کپچا بذارید. البته قفل کردن اکانت هم دردسرهای خودش رو داره یک فردی ممکنه عمدا بیاد و اکانتهای ملت رو قفل کنه اینطوری. ولی هرکدام از اینا ممکنه یجاهایی هم مفید یا لازم باشن بصورت موقتی هم که شده. اینه که بنظر من باید در برنامه این امکانات وجود داشته باشن ولی براحتی قابل فعال کردن و غیرفعال کردن در قسمت کانفیگ/تنظیمات برنامه باشن. ضمنا پارامترهای اونا هم باید قابل تنظیم باشه. مثلا تعیین کنیم بعد از چه تعدادی تلاش لاگین ناموفق کپچا بخواد، بعد از چند تا کلا قفل بشه. گزینهء کپچا و قفل هم جداگانه قابل تنظیم و فعال و غیرفعال کردن باشن. خلاصه باید آخر انعطاف و امکان کانفیگ باشه. بخاطر همین پیچیدگی و حجمش زیاد میشه. حتی من یه سیستمی گذاشتم که درصورتی که اکانت کسی قفل شده بود بتونه از طریق ارسال لینک خاصی به ایمیل، لاگین کنه. این سیستم هم باید قابل فعال و غیرفعال کردن باشه. بعد تازه من برای تمام اینا کانفیگ های اکانت ادمین و کاربران عادی رو کاملا جداگانه گذاشتم؛ یعنی هرکدام رو میشه جداگانه کانفیگ و فعال و غیرفعال کرد. تازه بازهم بیش از این، یه آپشن دیگه هم گذاشتم که خود کاربران بتونن تعیین کنن که از اکانتشون با کدام سیستمها (قفل اکانت و/یا IP) محافظت بشه یا نشه. البته دادن این اختیار به کاربران هم قابل فعال سازی و غیرفعال سازیه.
میتونید یه نگاهی به متغییرهای کانفیگ پروژهء بنده در این باب بکنید: https://github.com/ferchang/reg8log/blob/dev/include/config/config_brute_force_protection.php

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


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


اگه صفحه لاگین رو محدود کنم که فقط کاربر بتونه با ای پی ایران وارد بشه ، به امنیت کمک میکنه ؟
اینم یه ایده ای هست، ولی بنظر من بیش از حد محدودکننده است. حالا اگر کسی از خارج ایران خواست از سیستم استفاده کنه باید چکار کنه، اگر به هر علتی از V*P*N یا فیلترشکنی چیزی استفاده میکرد، و غیره. تازه این آیپی ها میتونن متغییر باشن و باید مدام چک و آپدیت بشن. بنظر من به محدودیت و دردسرش نمی ارزه. بهرحال راه اصولی نمیشه و شما باید اون سیستمهای دیگر رو هم پیاده سازی کنید، و اگر اونا رو پیاده سازی کنید نیاز و اهمیت اینطور ترفندها خیلی کمتر میشه که در نتیجه اون موقع دیگه فکر نمیکنم توجیه چندانی داشته باشه. البته این سیستم رو هم اگر بشه بصورت آپشنال و قابل کانفیگ در برنامه گذاشت که بد نیست شاید خوب هم باشه. اصلا من خودم به فکر افتادم شاید یه همچین آپشنی هم در پروژه خودم بنوعی بذارم (یا حداقل بتونم یه لیست سیاه و سفیدی چیزی از IP های خاص بهش بدم).


ایا استفاده از این $_SERVER['HTTP_REFERER'] به امنیت کمک میکنه ؟ اگه مستقیم وارد سایت شد ارور بده
اینم قابل جعله. بنابراین چندان اهمیت نداره. شما اگر سیستمهای دیگر رو پیاده کرده باشید، نیاز و اهمیت اینطور ترفندها خیلی کمتر میشه. هرچند درموارد خاص یا درمورد برنامه های زپرتی که صرف نمیکنه اون همه بند و بساط گسترده رو پیاده سازی کنیم شاید بتونه مفید باشه.
دقت کنید بعضی چیزها ترفند هستن، بعضی چیزهای دیگه راههای کم و بیش اصولی، بعضی چیزها موردی هستن، بعضی چیزها کلی، بعضی چیزها موقتی، بعضی چیزها کم و بیش دائمی. ... بستگی داره چه کسی بخواد چه برنامه ای در چه سطحی درست کنه و چقدر بخواد روش مایه بذاره. طبیعتا اگر بخوایم سیستم بی نقصی داشته باشیم اول باید روشهای پایه و اصولی رو پیاده سازی کنیم، بعد اگر لازم دیدیم میتونیم ترفندهای خاص یا امکانات موردی تر رو هم توش بذاریم. همهء اینا هم البته که باید قابل کانفیگ پارامتری کامل باشه که با شرایط مختلف که بعضا غیرقابل پیشبینی هستن بشه تطبیق داد و درصورت نیاز فعال و غیرفعال کرد.

[m.esmaeilzadeh]

اگر شما ip رو بلاک کنی دردسر میشه !
چون الان اینترنت ها اشتراکی هست و با یک ip چندین نفر آنلاین شدن ...
اگر اون username مشخص رو بلاک کنی بهتره ....
مثل یاهو مثلا !!!

[-سیّد-]

سلام مجدد
با عرض پوزش که به خواب زمستانی فرو رفته بودم و فرصت نکردم زودتر جواب بدم! :)

نشون دادن کپچا مسئله‌ی شما رو حل نمی‌کنه. اصلاً نشون دادن کپچا یه جایگزین برای مسدود کردن IP هست، نه جایگزینی برای استفاده از کوکی. یعنی اینجا دو تا مسئله داریم:
۱. چطوری تشخیص بدیم یکی داره کرم می‌ریزه؟
۲. حالا که فهمیدیم یکی داره کرم می‌ریزه، چی کار کنیم؟
نشون دادن کپچا جوابی هست برای سؤال ۲، نه برای سؤال ۱. ان‌قلتی که من اوردم برای جواب شما به سؤال یک بود (که استفاده از کوکی بود، یا سشن، یا هر داده‌ای که به client وابسته باشه مثل REFERER).

حالا راه حل سؤال یک چیه؟ اینه که شما اول باید راهی برای تشخیص کاربرا از همدیگه داشته باشی. فعلاً فرض رو بر استفاده از IP برای این منظور می‌ذاریم (چون همونطور که @freeman99 گفتن، این راه کامل نیست و ممکنه چند نفر که پشت NAT هستن از یه IP استفاده کنن. از طرف دیگه کسی که بخواد اذیت کنه احتمالاً می‌تونه IP اش رو عوض کنه). حالا با این فرض، چطوری تشخیص بدیم یه نفر داره اذیت می‌کنه؟ تنها راهش اینه که شما دیتای مربوط به «وضعیت اذیت» کاربرا رو سمت سرور ذخیره کنی! :) می‌شه هم بهش گفت aziatness! :))
یعنی به هیچ وجه به دیتاهایی که سمت client ذخیره می‌شن (یعنی کوکی) اعتنا نکنید.
بنابراین باید از یه چیزی مثل پایگاه داده استفاده کنید (که @freeman99 بهش اشاره کردن). البته راه‌های دیگه‌ای هم هست. مثلاً یکیش استفاده از shared memory هست که سرعتش بسیار بیش از پایگاه داده هست، ولی اولاً کار باهاش سخت‌تره، ثانیاً مدیریتش سخت‌تره، ثالثاً داده‌ی ذخیره شده توش volatile هست، یعنی اگه سیستم reboot بشه همه‌اش می‌پره! ولی performance اش به علت استفاده از RAM به جای دیسک، به مراتب بیشتر از پایگاه داده هست.

خلاصه: اگه خییییلی حوصله دارید و performance خیییلی براتون اهمیت داره، از shared memory استفاده کنید. وگرنه بزن توی پایگاه داده شرش کنده شه! :)

البته یه راه حلی هم به ذهنم رسید که خودم تا به حال ازش استفاده نکردم، ولی شاید بشه این کارو هم کرد:
شاید بشه از session به صورتی استفاده کرد که هر session به یه IP وصل بشه. یعنی یه جورایی session ID رو دستکاری کنیم که بر مبنای IP باشه. اون وقت نیازی به استفاده از پایگاه داده نیست. یه مزیت بزرگی که این کار نسبت به پایگاه داده داره، اینه که داده‌های session به صورت خودکار موقت هستن و سیستم خودش هندل می‌کنه. ولی اگه توی پایگاه داده ذخیره کنید، باید خودتون مدیریت کنید که داده‌های قدیمی مربوط به این مسئله رو که توی پایگاه داده هستن به صورت دوره‌ای پاک کنید. البته اگه قرار نیست از IP های مختلف در سراسر جهان(!) به سیستم شما درخواست بیاد، خیلی لازم نیست نگران این مسئله باشید!

اما سؤال دو: قطعاً نشون دادن کپچا راه حل تمیزتری از بلاک کردن IP هست! ولی از اون طرف یه کم سخت‌تر هست.

کلاً یه روش دیگه هم وجود داره: استفاده از ماژول mod_security آپاچی. این روش تر و تمیزترین روش هست، ولی یه جورایی سخت‌ترینشون هم هست!
یه مثال:
http://snippets.aktagon.com/snippets/563-brute-force-authentication-protection-with-modsecurity
کلاً یه کم کار با mod_security سخته! باید ببینید براتون ارزش داره سمتش برید یا نه.

[freeman99]

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


یه مزیت بزرگی که این کار نسبت به پایگاه داده داره، اینه که داده‌های session به صورت خودکار موقت هستن و سیستم خودش هندل می‌کنه. ولی اگه توی پایگاه داده ذخیره کنید، باید خودتون مدیریت کنید که داده‌های قدیمی مربوط به این مسئله رو که توی پایگاه داده هستن به صورت دوره‌ای پاک کنید.
فکر کنم این مسئله رو بیش از حد بزرگ فرض کردی.
من توی سیستم خودم به این صورت کار کردم که هر رکورد جدیدی میاد توی جدولهای مربوطه درج بشه، یک کدی هم اجرا میشه که بصورت رندوم مثلا از هر 100 درخواست یک بار عمل میکنه و میاد رکوردهای اکسپایر شده رو از جدول حذف میکنه. نیازی به استفاده از cron jobs هم نیست. البته اگر ترافیک و حجم جدول و اینا جایی خیلی زیاد باشه شاید این روش مناسب نباشه چون ممکنه حذف کردن رکوردهای قدیمی زمان زیادی طول بکشه و این زمان کاربر رو اذیت کنه. برای سیستمها کوچک و مقیاس و ترافیک پایین ولی من هیچ اشکالی درش نمیبینم و در عین سادگی کاملا کاراست و برنامه رو هم مستقل و نصبش رو راحت میکنه (نیاز به تنظیمات دستی cron jobs و این حرفا نداره).

[MMSHFE]

میتونید فرضاً چنین کاری انجام بدین: توی اسکریپتتون، اگه زمان درخواست اسکریپت، فرضاً دقیقه های 0، 5، 10، ... 55 بود (یا بازه های دلخواه دیگه خودتون)، بیاین 10 تا (یا هر تعداد دلخواه دیگه) از رکوردهای Expire شده رو حذف کنید. اینطوری، نیاز به Cron Jobs و... نیست و درنتیجه تا وقتی که چیزی درخواست نشده باشه از سرور، کاری هم بطور خودکار کاری انجام نمیده. ازطرفی چون محدوده کاری که انجام میشه توی اون بازه، زیاد نیست، مشکلی ازنظر سرعت هم پیش نمیاد. با تنظیم بازه زمانی و تعداد رکوردها، میتونید سرعت رو برحسب میزان درخواستها و حجم داده های Expire شده توی سیستمتون، Balance کنید.

[-سیّد-]

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

البته به نظرم هنوز هم می‌شه روی این ایده کار کرد. اون مسئله‌ی randomness که شما مطرح می‌کنید، برای کلیت session هست. من منظورم اینجا یه session مخصوص این کار بود. یعنی شما یه session موقت داشته باشید مخصوص این کار، و برای کارهای معمولی برنامه از یه session دیگه استفاده کنید.
در واقع session ای که من می‌گم، هیچ ارتباطی به کوکی پیدا نمی‌کنه و فقط به IP وابسته هست.

شاید پس فردا رفتم پیاده‌سازیش کردم روشم یه paper دادم! :))



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


میتونید فرضاً چنین کاری انجام بدین: توی اسکریپتتون، اگه زمان درخواست اسکریپت، فرضاً دقیقه های 0، 5، 10، ... 55 بود (یا بازه های دلخواه دیگه خودتون)، بیاین 10 تا (یا هر تعداد دلخواه دیگه) از رکوردهای Expire شده رو حذف کنید. اینطوری، نیاز به Cron Jobs و... نیست و درنتیجه تا وقتی که چیزی درخواست نشده باشه از سرور، کاری هم بطور خودکار کاری انجام نمیده. ازطرفی چون محدوده کاری که انجام میشه توی اون بازه، زیاد نیست، مشکلی ازنظر سرعت هم پیش نمیاد. با تنظیم بازه زمانی و تعداد رکوردها، میتونید سرعت رو برحسب میزان درخواستها و حجم داده های Expire شده توی سیستمتون، Balance کنید.

بله موافقم من قضیه رو زیادی جهانی دیدم! :)
درسته برای کار در سطح معمول همین روش‌ها جواب می‌ده.

در مورد این که تعداد رکوردهای پاک شده زیاد نشه که درخواست کاربر الکی طول نکشه، می‌شه ایده‌های دیگه زد. مثلاً توی یه thread دیگه این کار انجام بشه که main thread جواب رو به کاربر برگردونه (البته شاید به راحتی نشه توی هر محیطی این کارو کرد و نیاز به تنظیمات خاص داشته باشه).

البته cron job خیلی هم چیز ناراحتی نیست ها! :) ولی قبول دارم که تا جایی که بشه پیچوند و کار رو از طریق اسکریپت انجام داد، آدم خودشو درگیر cronjob نکنه به نفعشه. بالاخره یه لایه overhead کمتر می‌شه (حداقل توی administration برنامه).

[freeman99]

نمیشه.
نه، میشه میشه!! :D
میتونیم مثلا به این شکل عمل کنیم:

$sess_id=sha256(SECRET_KEY.IP)
البته کلیت ایده رو گفتم. باید بیشتر روش کار بشه.
ولی بهرصورت این سشن به ازای هر IP بنظر من بازم چیز جالبی نیست. حداقل اگر میشد واسه سشن معمولی هم ازش استفاده کرد یه چیزی، ولی چون چند کاربر ممکنه یک IP داشته باشن نمیشه.

[freeman99]

میتونید فرضاً چنین کاری انجام بدین: توی اسکریپتتون، اگه زمان درخواست اسکریپت، فرضاً دقیقه های 0، 5، 10، ... 55 بود (یا بازه های دلخواه دیگه خودتون)
بنظرم زیاد روش خوبی نیست. چون دلیل نداره حتما زمان درخواستها منظم و بصورت متعادل توزیع شده باشه. شاید درخواست های زیادی در فواصل زمانی بین این زمانها بیان و در خود این زمانها برای مدتی اصلا درخواستی نداشته باشیم یا خیلی کمتر باشه. یا بعکس فرض کنید در این زمانها درخواستهای زیادی وارد بشن ولی در بقیهء زمانها درخواستهای خیلی کمتری باشه.
اون روش رندوم بنظر من بهتر کار میکنه چون بر اساس تعداد درخواستهای واقعی هست و تحت تاثیر توزیع زمانی اونا واقع نمیشه.


بیاین 10 تا (یا هر تعداد دلخواه دیگه) از رکوردهای Expire شده رو حذف کنید.
حالا چرا ده تا؟ خب یبارکی میایم همش رو حذف میکنیم دیگه. یه کوئری delete ساده هست که حتی اگر حجم جدولش زیاد باشه زمان زیادی نباید ببره بخصوص که بر اساس فیلدی هست که ایندکس داره.


اینطوری، نیاز به Cron Jobs و... نیست و درنتیجه تا وقتی که چیزی درخواست نشده باشه از سرور، کاری هم بطور خودکار کاری انجام نمیده. ازطرفی چون محدوده کاری که انجام میشه توی اون بازه، زیاد نیست، مشکلی ازنظر سرعت هم پیش نمیاد. با تنظیم بازه زمانی و تعداد رکوردها، میتونید سرعت رو برحسب میزان درخواستها و حجم داده های Expire شده توی سیستمتون، Balance کنید.
فکر کنم overkill کردی مهندس :D

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

[MMSHFE]

حالا چرا ده تا؟ خب یبارکی میایم همش رو حذف میکنیم دیگه. یه کوئری delete ساده هست که حتی اگر حجم جدولش زیاد باشه زمان زیادی نباید ببره بخصوص که بر اساس فیلدی هست که ایندکس داره.

من سناریوی کلی رو گفتم نه صرفاً توی همین قضیه IP و...
محدود کردن حجم رکوردهای مورد پردازش در هر درخواست، بخصوص وقتی خودش رو نشون میده که از Relationها و قید ON DELETE CASCADE استفاده شده باشه و حذف یک رکورد اینطرف، مستلزم حذف تمام رکوردهای وابسته در جداول دیگه باشه. اینجور جاها بهتره یکمرتبه دیتابیس رو شخم نزنیم.

[sairon123]

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

در مورد ماژول های امنیتی mod_evasive و modSecurity هم گشتم ، خیلی عالی بودن ، از پشتیبانی هاستینگ هم سوال کردم ، گفتن که این ماژولها فعال هستن رو سرور

اقای حمیدرضا کدهای شما رو هم دیدم ، خیلی خوب بود ، الیته تعداد صفحاتش هم خیلی زیاد بود :لبخند:، دانلود کردم و سعی میکنم کدها رو بخونم و بتونم یاد بگیرم ، از روش های شما استفاده کنم ، با تشکر فراروان دوست عزیز

[freeman99]

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

[abolfazl-z]

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

دوست عزیز اتفاقا این اخلاق اش است :لبخند: منم اول اومده بودم در مورد regexp یک تاپیک زدیم کلی هم بحث شد اون موقع هم بار علمی مان کم بود این اشپیلن هم با این پتکی که همیشه دستش بود میزد تو سر ما. :قهقهه:

البته آقای شهرکی اون موقع گفتن که چیزی تو دلش نیست(واقعا هم نیست)

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


بگذریم.


IP رو زرتی نمیبندن، چون IP که فقط مال یه نفر نیست لزوما. اونم با 3 تا تلاش ناموفق!

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

از نظر من تشخیص از PHP باشه بلاک کردن از جای بالاتر.

[freeman99]

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

خیلی حالتها میتونه وجود داشته باشه. فکر نمیکنم احتمالش فقط چند درصد باشه!
من قبلا مطالب در این زمینه زیاد خوندم مثلا چند جا اشاره شده بود بعضی ISP ها برای مشترکین خودشون از IP های معدودی استفاده میکنن. یعنی یک IP ممکنه بین تعداد قابل توجهی مشترک همزمان Share باشه. حالا کدوم ISP ها، کدوم کشورها، چرا، آمارش چقدره، این بحث و تحقیق خودش رو میطلبه.
حالا بحث شبکه های LAN و امثالهم هم که به کنار. یعنی توی خیلی از سازمانها، موسسات، دانشگاهها و غیره، یک یا چند IP معدود بین همه بصورت همزمان اشتراکی هست.
ضمنا بجز بلاک شدن تصادفی کاربران دیگر، یک مبحث دیگه در این ارتباط اینه که هکر بیاد و عمدا اونطور IP هایی رو که میدونه کاربران دیگری هم ازش استفاده میکنن شناسایی و بلاک کنه (البته این به شرطی هست که خودش هم دسترسی به اون IP داشته باشه یا بتونه یجوری سیستم رو گول بزنه اگر بحث امنیتیش در این زمینه ضعیف باشه) و میتونه این کار رو ادامه بده تا یک IP عملا بیشتر اوقات و برای مدت طولانی از دسترسی منع بشه. این یکی از انواع حمله های DOS محسوب میشه.

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

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

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

[abolfazl-z]

حتی در بازه های زمانی کوتاه و بدون قطع اتصال و خاموش و روشن کردن مودم

واسه یکی از دوستانم همینطوریه


خیلی حالتها میتونه وجود داشته باشه. فکر نمیکنم احتمالش فقط چند درصد باشه!

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

خوب با این اوصاف باید فکری دیگری کرد.

خوب یک راهش که واضح است کد امنیتی است.

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

[sairon123]

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

به نظر شما این روش چه مشکلاتی رو ممکنه به وجود بیاره ؟


آیا روشی هست که مثلا بتونیم یکتایی کاربر رو تشخیص بدیم ؟ مثلا از مرورگر و سیستم طرف مقابل ؟

یه مطلب هم خوندم که نوشته بود تا حدودی امکان داره ، اینجا نوشته تا 94 درصد ، اگه درست باشه که خیلی از مشکلات حل میشه

http://www.geekfarsi.com/%D8%A2%DB%8C%D8%A7-%D8%A7%D9%85%DA%A9%D8%A7%D9%86-%D8%B4%D9%86%D8%A7%D8%B3%D8%A7%DB%8C%DB%8C-%DB%8C%DA%A9-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-%D8%A8%D9%87-%D8%B5%D9%88%D8%B1%D8%AA-%DB%8C%DA%A9%D8%AA%D8%A7/304

[freeman99]

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