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

[saeed-71]

سلام.
کسی کلاس لاگین امن و پیشرفته داره؟

[asonline]

تو سایت olomrayaneh.net هست می تونید از اونجا بگیرید

[masiha68]

تو سایت olomrayaneh.net هست می تونید از اونجا بگیرید

مطمئنی توی سایت علوم پایه کلاس پی اچ پی پیدا میشه:متعجب:

[eshpilen]

کلاس لاگین امن و پیشرفته؟
تا تعریف شما از امن و پیشرفته چی باشه!!
اون تعریفی که توی ذهن منه، عمرا با یک کلاس و دو کلاس ممکن نیست.
یک سیستم رجیستر و لاگین امن و پیشرفته، خودش یک سیستم و پروژهء نسبتا بزرگ و پیچیده است؛ یک زیرسیستم از سیستمهای بزرگتر، نه چیزی درحد یک کلاس!
مثلا سیستم رجیستر و لاگین بنده (http://www.hamidreza-mz.tk/files/reg8log-v1.8.zip) رو مشاهده کردید تاحالا؟
حجم و پیچیدگی کدش و تعداد جدولهاش واقعا زیاد شد.
تازه الان چند نکته و ایدهء بیشتر هم بنظرم رسیده که ممکنه بعدا بهش اضافه کنم.
هنوزم نمیتونم بگم اونقدری که واقعا باید آخر امنیت و حرفه ایه، ولی بنظرم یکی از پیشرفته ترین و امن ترین و منعطف ترین سیستمهای موجود باشه (صرفنظر از اینکه احتمالا باید فکری برای راحت کردن استفاده ازش در برنامه های مستقل بشه).
فقط از نظر پرفورمنس ممکنه سنگین باشه طبیعتا. ولی بهرحال من درنظر نداشتم این پروژه رو برای ترافیک های بالا طراحی کنم.

[eshpilen]

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

[masiha68]

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

[eshpilen]

شما این کلاس رو چن روزه نوشتین ؟؟
یادم نیست. معمولا زمان رو دقت و اندازه گیری نمیکنم (چون کار شخصی و با وقت آزاد کافی است).
ولی از روی ردهایی که توی اینترنت جا گذاشتم فکر کنم بتونم بفهمم!


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

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

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

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


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

[navid3d_69]

من سیستم لاگین شما رو چندین بار دانلود کردم ولی چون داکیومنت خوبی نداشت هر دفعه بعد از باز کردن چندتا فایلش بستم و دیگه بازش نکردم شاید اگر داکیومنت بهتری داشت می تونست خیلی کمک کنه

[masiha68]

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

[eshpilen]

من سیستم لاگین شما رو چندین بار دانلود کردم ولی چون داکیومنت خوبی نداشت هر دفعه بعد از باز کردن چندتا فایلش بستم و دیگه بازش نکردم شاید اگر داکیومنت بهتری داشت می تونست خیلی کمک کنه
اینترفیسش که ترجمهء فارسی هم داره.
از نظر کانفیگ هم تمام متغیرهای کانفیگ مهم کامنت گذاری خوبی شدن؛ منتها به زبان انگلیسی.
نام گذاری متغییرها و فایلها و غیره هم که فکر میکنم تاحد خوبی self-document باشه.
دیگه وقت و اولویتی نداشتم بیش از این روی داکیومنت وقت بذارم.
اگر درمورد خاصی سوال داری میتونی بپرسی وقت داشتم میگم.

[eshpilen]

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


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


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

بهرحال چنین پروژه ای اگر بخواد واقعا کامل و امن و منعطف باشه، یه چیزی هست شبیه یه پروژهء CMS (حالا یه مقدار کوچکتر).
شما دربارهء ساختن یک CMS میپرسید که چه کلاسهایی میخواد؟
فکر نمیکنم زیاد سوال روشن و مفیدی باشه!

[masiha68]

اگه ادم یه طرح کلی در مورد کلاس ها داشته باهش بهتر می تونه جلو بره ... مثل یه فیلم می ونه که می دونی کجاش قراه چی اتفاق بیفته ولی اگه بدون طرح قبلی و با ازمون محک جلو بری یهو وسط کار میبنی که یه جایی اول کار یه چیزی رو اشتباه قرار دادی و مجبور می شه بری از اول اونو درست کنی که هم حوصله ات تموم مشه و هم خسته کننده ست
فک کنم با این کلاس ها بشه این سیستم رو راه انداخت
sign up : برای ثبت کاربر شامل (نام کاربری،پسورد ، ایمیل ، نام و نام خانوادگی ، اطلاعات لازمه (مثل ای پی کاربر زمان ثبت نام .... )
db : واسه برقراری ارتباط با دیتابیس
useraction : بدست اودن یه سری اطلاعات مثل ای پی و اسکیپ کردن داده ها ، بررسی صحت ایمیل و ...
sing in : برای ورود و دادن پرمیشن های لازم و ساخت کوکی یا سشن ها ....
و یه قسمتی هم برای ادمین که بتونه کاربرهای ثبت شده رو ببینه و سطح کاربرهای رو طراحی کنه که اونم میشه بخشی از سایت و فکرکنم باید از سیستم ریجستری جدا باشه

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

[eshpilen]

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

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

[masiha68]

در مورد هش که فک کنم md5 n رسما لو رفته ولی اگه از md5 و sha1 و یه سالت قوی استفاده کنی فک نکنم کسی بتونه پسورد رو برگردونه
در مورد تغییر پسورد هم فک کنم باید از طریق ایمیل تغییر پسورد تایید بشه ... در کل فک کنم اگه بخوای یه سطح امنیتی خیلی زیاد در حد فیس بوک بذاری این چیزایی که شما گفتن لازم بشه وگرنه توی پروژه های کوچیک و حداقل در سطح ایران کسی به اینا نیاز نداره چون هم هکر به اون صورت نداریم و هم اینکه خیلی از سایت ها ارزش هک کردن ندارن
شما چطوره سیستمت رو به صورت انلاین بذاری و از بقیه بخوای دورش بزنن یا هکش کنن ( هستن کسایی که این کارو می کنن) تا ببینید در چه حدیه
ممنون به خاطر اطلاعاتی که در اختیارم گذاشتی ... خیلی جالب و مفید بود

[eshpilen]

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


در مورد تغییر پسورد هم فک کنم باید از طریق ایمیل تغییر پسورد تایید بشه ...کلی و مبهم گفتی.
توضیح دقیق بده.
دقیقا چه الگوریتم و روشی برای جلوگیری از Brute-force دارید؟


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


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

[eshpilen]

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

[eshpilen]

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

[masiha68]

کلی و مبهم گفتی.
توضیح دقیق بده.
دقیقا چه الگوریتم و روشی برای جلوگیری از Brute-force دارید؟
ایده ی کلی اینه وقتی یکی خواست ایمیل یا پسورد رو تغییر بده یه ایمیل به ایمیل کاربر ارسال بشه که پسورد شما تغییر کرد و یه کد تایید هم بهش بده که اون کد هم می تونه با یه سیستم کد گذاری و دیکد (این روش توی c# وجود داره ولی نمی دونم توی php هست یا نه یعنی یه عبارت رو هش کرد و بعد برگردوند ) تغییر داد که نشه جعلش کرد ... این روش توی جیمیل الان استفاده میشه



طور مثال از اول خواستم از اینکه هکر بتونه براحتی تست کنه که چه نامهای کاربری یا ایمیل هایی در سیستم ثبت شدن جلوگیری کنم (اکثرا 100% نمیشه جلوگیری کرد اما باید تاحد ممکن سختش کرد که طرف نتونه ایکی ثانیه و همچنین با برنامه های خودکار این کار رو انجام بده).
فک کنم کلیپچا رو واسه همین ساختن دیگه :d ... یه کوکی هم تعیرف می کنیم که اگه کاربر ده بار بیشتر اطلاعات رو وارد کرد اون قسمت سایت رو براش ببنده (مثلا به مدت یک روز) توی سی پنل الان از این روش استفاده میشه ... البته قفل کردن اکانت هم ایده ی خوبیه ولی نمی دونم چرا یه هرک باید بیاد و اکانتی رو که وجود نداره پسوردش رو تست کنه ؟؟!؟ مگه اینکه واسه لو نرفتن اکانت های نا موجود باشه

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

[eshpilen]

ایده ی کلی اینه وقتی یکی خواست ایمیل یا پسورد رو تغییر بده یه ایمیل به ایمیل کاربر ارسال بشه که پسورد شما تغییر کرد و یه کد تایید هم بهش بده که اون کد هم می تونه با یه سیستم کد گذاری و دیکد (این روش توی C#‎‎ وجود داره ولی نمی دونم توی php هست یا نه یعنی یه عبارت رو هش کرد و بعد برگردوند ) تغییر داد که نشه جعلش کرد ... این روش توی جیمیل الان استفاده میشه
مثل اینکه متوجه نشدی من چی میگم.
این که شما میگی از Brute-force پسورد کاربر جلوگیری نمیکنه.
یعنی هکر میتونه مثلا چند پسوردی رو که حدس میزنه تست کنه، یا با یک برنامهء خودکار تعداد خیلی بیشتری پسورد رو تست کنه، تا کشف کنه پسورد کاربر چی بوده.
حالا در این بین ایمیل به کاربر ارسال بشه یا نشه، بهرحال از Brute-force و کشف پسورد جلوگیری نمیکنه.
حواست باشه که موقع تعیین پسورد جدید، پسورد فعلی باید وارد بشه! حالا اگر پسورد فعلی غلط وارد بشه، خب سیستم میگه دیگه، اگر درست باشه هم که پسورد با موفقیت تغییر داده میشه و یک پیامی چیزی به کاربر میده که پسورد عوض شد.


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


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


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


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

[eshpilen]

که اگه کاربر ده بار بیشتر اطلاعات رو وارد کرد اون قسمت سایت رو براش ببنده (مثلا به مدت یک روز) چطوری ببنده؟ بر اساس IP؟ یا بر اساس نام کاربری؟
طرف که لزوما کاربر سایت و لاگین نیست.
بستن IP هم همه جا و همه وقت موثر یا درست نیست.
مثلا همین بستن IP میتونه برای حمله های DOS استفاده بشه روی IP های اشتراکی. یعنی طرف عمدا کاری میکنه که اون IP بلاک بشه و بقیهء کاربران بی گناه سایت که از همون IP استفاده میکنن از دسترسی محروم بشن.
بعد بستن IP درمقابل حمله هایی که از تعداد زیادی IP استفاده میکنن (مثلا بوسلیهء پراکسی و Bot net) تاثیر کافی نداره.

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

[masiha68]

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

100% امنیت نمیشه، اما الان ابزار و اطلاعات برای همین حد امنیت دست یافتنی هم که وجود داره در بیشتر سیستمها رعایت نمیشه.
حالا ما گفتیم سعی کنیم یدونه درست کنیم. بده مگه؟
بد !؟ بد که نیست خیلی هم خوبه. هم خودتون رو محک زدین :) و هم یه کار خیری کردین و هم اینکه زکات علمتون رو پرداخت کردین

[eshpilen]

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

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

[eshpilen]

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

انصافا اینقدر کانفیگ و انعطاف پیکربندی که توی این پروژه گذاشتم ندیدم و نشنیدم در هیچ برنامهء مشابهی وجود داشته باشه.

[H:Shojaei]

جناب eshpilen (http://barnamenevis.org/member.php?148005-eshpilen) واقعا ممنون اصلا من يكي كه كلا ديدم با اين مطالب شما عوض شد درباره ي امنيت البته در اون حد نيستم كه بخوام اينا رو انجام بدم ولي در كارهاي آينده همين مطالب اين تاپيك يه مرجع خوب ميشه كه نكاتي كه گفتيد رو انجام خواهم داد.
و يه چيزو تو صحبت هاتون من متوجه نشدم چند بار هم خودنم ولي بازم نفهميدم اگه ميشه لطف كنيد يه مختصر توضيح بديد (البته هر چند ماشالله شما زير 10 خط پست نميزنيد :چشمک:):

یک سیستم رمزنگاری برای انتقال پسورد از کلاینت تا سرور هم گذاشتم که در مواردی که هش پسورد به سرور میره و دوباره به کلاینت برمیگرده استفاده میشه

[eshpilen]

خب یه روش و احتیاط امنیتی حداقلی که بعضی سیستمها بکار میبرن اینه که پسوردهای کاربر رو قبل از ارسال هش میکنن تا پسورد بصورت Plain text ارسال نشه. چون میدونید که پروتکل HTTP این امکان رو به کسانی در جاهایی که به کانال ارتباطی دسترسی داشته باشن میده که تمام اطلاعات رو بخونن!

پس ما پسوردها رو قبل از ارسال، در سمت کلاینت هش میکنیم (بوسیلهء جاوااسکریپت).
این حداقل کاریه که میتونیم برای امنیت پسوردهای کاربران بکنیم.
یعنی حداقل اصل پسورد به این راحتی دست کسی نیفته.

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

اما این پسورد هش شده هم اگر بدست هکر بیفته، دو کار باهاش میتونه بکنه، یکی اینکه اگر بقدر کافی وارد باشه میتونه بجای کاربر لاگین بشه بدون اینکه اصل پسورد کاربر رو بدونه و وارد کنه، که از این مورد ما بطور معمول نمیتونیم درصورت سرقت این اطلاعات جلوگیری کنیم، و یک کار دیگری که با این هش میتونه انجام بده اینه که با استفاده از روشهای Brute-force تست کنه ببینه پسورد اصلی چی بوده، یعنی مثلا حدس میزنه پسورد کاربر mammad-xx بوده، که xx یه شمارهء دو رقمی هست، اونوقت میتونه از mammad-00 شروع کنه و اون رو هش کنه و ببینه با هش سرقت شده یکسان هست یا نه، و همینطور تا mammad-99 ادامه بده.
البته این فقط یه مثال بود. خواستم بگم که Brute-force کردن یعنی چی. وگرنه در عمل میشه پسوردهای خیلی بیشتری رو با روشهای خودکار هم تست کرد.

فقط درصورتی پسورد کاربر به روش Brute-force کشف نمیشه که پسورد بقدر کافی قوی ای بوده باشه تا هکر نتونه حدس هم بزنه و برنامه های خودکار و دیکشنری ها و غیره هم نتونن از پسش بربیان.

این تا اینجا.

حالا بگید فهمیدید یا نه و بقیش باشه برای فردا اینا :لبخند:


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

[masiha68]

هش با استفاده زا جاوا اسکریپت ؟؟!؟! فقط یه مشکل اینکه هش رو انجام دادیم و فرستادیم پس توی سرور هم یه بار دیگه هش کردیم (2 بار هش ) ... واسه لاگین هم باید همین کار بکنیم . یعنی اینکه یه بار از جاوا هش کنیم و یا بار با php
و اینکه کدهای جاوا توی ویو سورس دیده میشن و امنیتی ندارن .. پس قضیه زود لو میره !!!! البته فک کنم
راستی مگه جاوا اسکریپت هم هش می کنه

[eshpilen]

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


و اینکه کدهای جاوا توی ویو سورس دیده میشن و امنیتی ندارن...این کار هش کردن سمت کلاینت فقط یک تمهید امنیتی حداقلی هست که میتونه از دسترسی هکرهایی که فقط کانال ارتباطی رو میخونن و قادر به دخالت مستقیم در ارتباطات بین کلاینت و سرور نیستن (به اصطلاح Passive adversaries)، به اصل پسورد جلوگیری کنه.


پس قضیه زود لو میره !!!! البته فک کنمچی لو میره؟
اینکه پسوردها رو سمت کلاینت هش میکنیم؟
از اول هم قصدمون پنهان کردن این قضیه نبوده.
صرفا اینکه یک Passive adversary این رو بدونه، قادرش نمیکنه که اصل پسورد رو بدست بیاره.


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