توجه!
آخرین نسخهء این پروژه را از آخرین پست بنده در این تاپیک که دارای فایل ضمیمه میباشد دانلود کنید.
نسخهء ضمیمه شده به این پست نسخهء اولیه/قدیمی میباشد.
-----------------------------------
میتونید این پروژه رو از فایل ضمیمهء این پست دانلود کنید.
ویرایش: این پروژه در github هم وارد شد: https://github.com/ferchang/reg8log
چند ماه بود داشتم روی این پروژه شخصی کار میکردم.
این یک سیستم رجیستر و لاگین است که سعی کردم از نظر امکانات و امنیت درحد قابل توجهی باشه.
البته بیس این پروژه یک پروژهء مشابه خیلی قدیمی تر بود که چند سال پیش ارائه کرده بودم، اما تغییرات و افزوده ها بسیار زیاد هستن و این یک پروژهء خیلی کامل تر و امن تر از اون قبلی است.
===================
این پروژه تحت مجوز نرم افزار آزاد GPL نسخهء 2 یا بالاتر ارائه میشود.
===================
البته این پروژه هنوز در مراحل آزمایشی است و بنابراین معلوم نیست چقدر و چه نوع باگهایی ممکنه از توش دربیاد. هنوز نسخهء فارسی اون رو هم درست نکردم و این نسخه انگلیسی هست که برای بررسی و فیدبک و گزارش باگ و هرگونه پیشنهاد و انتقاد و ایده ای منتشرش میکنم، چون مراحل تست و توسعهء انفرادی تا همینجا بصورت بهینه پیش رفته و بعد از این بهتره پروژه عمومی مطرح بشه تا کار بیهوده و دوباره کاری صورت نگیره.
البته اینکه میگم انگلیسی منظور این نیست که نشه با زبان فارسی ازش استفاده کرد. فقط منظورم اینه که تمام نوشته ها و پیامهاش به زبان انگلیسی هستن.
===================
دربارهء پرفورمنس این برنامه هیچ ادعایی نمیکنم و قولی نمیدم. این یه پروژهء شخصی بوده و خواستم تمرکز و وقت و انرژی خودم رو روی کامل و دقیق بودن الگوریتم و امنیتش بذارم و در ضمن امکانات کافی داشته باشه. اساسا اون رو برای سایتهای کوچک و معمولی که تعداد کاربر و ترافیک خیلی زیادی ندارن درنظر گرفتم (*). خواستم فرق و برتری این پروژه با بقیه پروژه ها در مسائل امنیتی و کمال و دقت منطقش باشه و بیشتر منابع خودم رو به این پارامترها اختصاص دادم.
بهرحال پیاده سازی امنیت و منطق کامل و دقیق هزینه داره و حجم و پیچیدگی بیشتر کد که موجب کاهش پرفورمنس میشه. اما اینکه این هزینه دقیقا چقدره و این پروه تا چه مقیاسی قابل استفاده است نمیدونم؛ باید در عمل تجربه بشه.
البته بنده بهینه سازیهایی رو که بنظرم واقعا درشت و مهم بودن و پیاده سازی اونها کار و پیچیدگی زیادی نداشت سعی کردم انجام بدم، ولی احتمالا بازم میشه و شاید در نهایت از نظر عملی لازم باشه بهینه سازیهای دیگری که ممکنه شامل مقداری تغییرات در طراحی دیتابیس و بعضی زیرسیستم ها هم باشه انجام بشن. بهرحال این اولین کار نسبتا گستردهء بنده است و هنوز باید آزمایش و بررسی بشه.
بعضی چیزها شاید بنظرتون عجیب بیاد، مثلا اینکه چرا از یک رشتهء رندوم، بجای فیلد عددی auto_increment، برای uid استفاده شده (که افرادی بهم گفتن از نظر پرفورمنس اصلا جالب نیست). علتش توجه بالا به امنیت بوده و جلوگیری از نشت هرگونه اطلاعات و اتفاقات و سوء استفاده های آینده در زمینهء امنیت (توضیحش حالا بماند که از حوصلهء این توضیحات کلی خارج است). ولی بهرحال اگر در عمل لازم باشه میشه این قبیل چیزها رو تغییر داد یا مواردی رو که میخوایم به دیتابیس و بقیهء برنامه اضافه کنیم.
بنده کلا از این روش و توصیهء حداقل بعضی از برنامه نویسان حرفه ای استفاده میکنم که وقت و انرژی خودم رو روی بهینه سازیهای جزیی صرف نکرده و بخاطر بهینه سازیهای جزیی کد رو بیخودی حجیمتر و پیچیده تر نمیکنم، مگر اینکه در عمل مشکل پرفورمنس جدی دیده بشه و این کار لازم باشه. بنظر بنده این روش صحیح و بهینه است. یعنی برای هرچیزی باید در عمل مشکل و نیاز وجود داشته باشه که قاعدتا باید دیده بشه.
تازه بهینه سازیهای درشت رو هم اگر پیاده سازی اونها خیلی مشکل نباشه یا خوانایی کد رو خیلی کاهش ندن انجام میدم، وگرنه باید در عمل نیاز بهش اثبات بشه تا پیاده سازی کنم.
*: اینکه گفتم این پروژه برای سایتهای کوچک طراحی شده به این معنی نیست که روی یک هاست درپیت ارزان با فضای کم هم مناسب باشه (اول میخواستم بر روی ارزانترین هاستها هم کاملا قابل استفاده باشه، ولی بعد متوجه شدم یک برنامهء حرفه ای با امکانات و امنیت بالا رو نمیشه با چنین شرایطی طراحی کرد یا رسیدن به این هدف میتونه خیلی دشوار باشه که ارزش هزینش رو نداره و بهتره بجاش هاست قوی تری تهیه بشه). دیتابیس این برنامه میتونه حجم قابل توجهی داشته باشه و اگر فضای هاست خیلی کم باشه (مثلا 50 مگابایت) احتمالا با تعداد چند هزار کاربر تمام فضای آزاد هاست میتونه پر بشه، یا ممکنه هکرها از این ضعف برای حملهء خاصی سوء استفاده کرده و با پر کردن فضای هاست (مثلا با تعداد زیادی ثبت نام جدید) موجب مشکل بشن.
===================
طریقهء نصب برنامه:
- یک دیتابیس بنام reg8log رو خودتون باید شخصا ایجاد کنید.
- نام کاربری و پسورد اتصال به MySQL رو در فایل info_dbms.php وارد و سیو کنید.
- بعد وقتی صفحات برنامه رو باز کنید خودش تشخیص میده که جدولها ایجاد نشدن و لینک صفحهء نصب رو در اختیارتون قرار میده.
- وارد صفحهء نصب که شدید اول باید یک عدد رندوم رو که تولید شده از اونجا کپی کرده و در فایل setup.txt واقع در پوشهء setup درج و سیو کنید. این مرحله بخاطر اینه تا ثابت بشه شما مالک حقیقی سایت هستید و به هاست دسترسی دارید. البته این روش رو بچه ها در فروم iranphp.org مطرح کردن که ظاهرا یک برنامهء شناخته شده ای از این روش برای احراز هویت مالک سایت استفاده میکنه.
- در مرحلهء بعد باید پسورد و ایمیل اکانت ادمین رو تعیین کنید.
- اکانت ادمین برای کارهای مدیریتی این برنامه استفاده میشه. کارهایی مثل تایید یا حذف اکانت های معلق، Ban کردن و Unban کردن.
نام کاربری ادمین ثابته (Admin) و ادمین با استفاده از نام کاربریش شناسایی میشه.
- بعد از سابمیت فرم مشخصات ادمین، برنامهء نصب تمام جدولها رو با خوندن از فایلهای sql موجود در پوشهء sql (واقع در پوشهء setup) بصورت خودکار ایجاد میکنه و یکسری متغییرهای اولیهء سایت رو هم تولید و در جدول های مربوطه درج میکنه و دست آخر اکانت ادمین رو هم به دیتابیس سیستم اضافه میکنه.
===================
از ایرادهای احتمالی این برنامه میتونم به استفاده از Table برای Layout اشاره کنم.
بهرحال این اولین کار عملی بنده بعد از سالها بوده و اون زمان قدیمتر بحث استانداردهای طراحی و عدم استفاده از جدول برای Layout به اندازهء الان گسترده و جدی نبود. منم فعلا وقت نداشتم روی روشهای استاندارد امروزی در بخش پیاده سازی اینترفیس HTML بیشتر تحقیق و کار کنم، و تمام وقت و انرژی محدود خودم رو به اهداف اصلی مورد نظر این پروژه، که بحث امنیت و منطق و الگوریتم و امکانات اون بود، اختصاص دادم. ضمنا پروژه بازمتن هست و هرکس خواست میتونه تغییرش بده و اشکالاتش رو برطرف کنه. این یه پروژهء اولیه و آزمایشی است که البته سعی شده نسبت به کارهای دیگر، در کل امنیت بالاتری رو با استفاده از علم و تحلیل و طراحی تخصصی امنیت و رمزنگاری و روشهای اصولی پیشرفته و استاندارد، داشته باشه (هرچند هنوزم حداقل یکی دوتا سیستم امنیتی قابل توجه هست که در این پروژه پیاده سازی نکردم و شاید بعدا این کار انجام شد).
یک ایراد دیگری که بازم به دلایل مشابهی میتونم برای این پروژه درنظر بگیرم اینه که احتمالا متدهای استاندارد دیزاین برنامه نویسی رو درش رعایت نکردم یا بصورت کامل رعایت نکردم. مثلا نمیدونم آیا میشه اثری از متد MVC در این پروژه دید یا نه و تا چه حد. بنده شخصا با توجه به نیاز عملی، بخاطر حجم و پیچیدگی روز افزون کدهای این برنامه، از روش تقسیم و تفکیک کدها و عملیات به بخشهای مجزا و ذخیره هر قطعه کد و تابع در فایل مجزا استفاده کردم که این روش خوب جواب داد و مشکل حجم و ناخوانایی کد رو تاحد قابل تحملی کاهش داد.
احتمالا باید کدهای این برنامه رو ترکیبی از روش شیء گرا، فانکشنال، و غیره دونست چون درش هم از کلاس و اشیاء و هم از تابع و غیره استفاده شده.
===================
اگر خواستید از جدول اکانتهای کاربری این برنامه نسخهء پشتیبان تهیه کنید، باید توجه کنید که هش پسورد کاربران که در دیتابیس برنامه ذخیره شده، به اطلاعات جدول site_vars و نیز مقدار متغییر pepper در فایل کانفیگ info_crypto.php هم بستگی داره. بنابراین باید حداقل از این دو مورد هم نسخهء پشتیبان تهیه و درصورت لزوم برگردان کنید تا بعد از برگردان کردن اطلاعات، کاربران بتونن به اکانتهای خودشون لاگین کنن.
===================
این برنامه در این محیط توسعه داده و تست شده:
سیستم عامل: ویندوز XP SP3
مرورگر: FF 10 و IE 7
EasyPHP 5.3.1.0 که شامل MySQL 5.1.43 و PHP 5.3.2 و Apache 2.2.14 میشه.
این برنامه روی PHP 4 کار نمیکنه، و حتی روی نسخه های بیش از حد پایین سری 5 هم کار نمیکنه، اما فکر میکنم نسخه هایی از سری 5 که الان روی بیشتر هاستها نصب هستن برای اجرای برنامه کافی باشه.
ضمنا خواستم این پروژه رو در محیط GNU/Linux هم تست کنم، اما خودم یک نسخهء خیلی قدیمی از لینوکس رو دارم (فدورا 5) که برنامه روش درست کار نکرد. سرفرصت اگر تونستم یک نسخهء جدیدتر لینوکس رو تهیه و نصب میکنم تا بتونم سازگاری این برنامه رو در محیط لینوکس هم تست و اگر اشکالی داشت درستش کنم.
===================
-----------------------------------------------------------
متغییرهای پیکربندی در فایل کانفیگ info_register.php
-----------------------------------------------------------
با تنظیم متغییر ajax_check_username میشه مشخص کرد که سیستم چک کردن ایجکسی نام کاربری انتخاب شده در بخش ثبت نام فعال باشه یا غیرفعال.
این متغییر علاوه بر ایجکس فرم ثبت نام، بر روی یکسری تمهیدات امنیتی سیستم هم تاثیر غیرمستقیم میذاره (در جهت جلوگیری از افشای نامهای کاربری کاربران سیستم) و رفتار سیستم رو در این راستا تغییر میده که حالا توضیحش بماند چون از حوصلهء این مختصر خارج است.
امکان ثبت نام سیستم رو میشه با متغییر registeration_enabled فعال یا غیرفعال کرد (مثلا یک وقتی اگر خواستید کاربران بیشتری یا در زمان خاصی نتونن در سیستم ثبت نام کنن).
متغییر password_refill تعیین میکنه که در بخش ثبت نام اگر اطلاعات ثبت نام مشکلی داشت و فرم به کاربر برگردانده شد، آیا پسورد کاربر هم مجددا در فیلد پسورد بصورت خودکار پر بشه تا کاربر بعد از رفع موارد اشکال نیازی به تایپ مجدد پسورد (اونم دوبار) نداشته باشه، یا خیر.
این پسورد بصورت خودکار پر شده که از سمت سرور به کلاینت برگشت داده شده بصورت رمز شده با استفاده از الگوریتم AES128 به سمت کاربر برگردانده میشه که کلید رمزنگاری یک کلید محرمانه در سمت سرور است که موقع نصب دیتابیس بصورت خودکار و رندوم تولید میشه. بنابراین هیچکس در سمت کلاینت یا در بین مسیر نمیتونه این رشته رو رمزگشایی کنه و پسورد کاربر رو دربیاره. فقط خود سرور میتونه این رشته رو رمزگشایی و استفاده کنه.
ضمنا موقعی که کاربر برای اولین بار پسورد رو ارسال میکنه، این پسورد قبل از ارسال، در سمت کلاینت با SHA256 و به همراه یک سالت یکتا (اما غیرمحرمانه) که موقع نصب دیتابیس برنامه بصورت خودکار ایجاد شده هش میشه و بنابراین چیزی که در مسیر از PC کلاینت تا سرور منتقل میشه پسورد خام نیست بلکه یک هش است که اگر پسورد کاربر ضعیف نباشه کسی قادر نیست حتی با Sniff کردن ارتباطات، اصل پسورد کاربر رو ازش بدست بیاره (اما باید توجه داشته باشید که با سرقت چنین اطلاعاتی میتونن بجای کاربر لاگین کنن - بحث کشف اصل پسورد چیز دیگری است که اهمیت خودش رو داره).
این هش شدن پسورد قبل از ارسال، در تمام فرمهای برنامه که فیلد پسورد دارن انجام میشه (مثلا فیلدهای پسورد واقع در بخش تغییر پسورد)، و فقط منحصر به بخش ثبت نام نیست.
مقدار متغییر email_verification_needed مشخص میکنه که آیا برای قبول ثبت نام کاربران نیاز به تایید صحت ایمیل اونها با استفاده از ارسال ایمیل محتوی لینک فعال سازی هست یا خیر. اگر به این کار نیاز باشه، اکانت کاربر تا وقتی ایمیل تایید نشده معلق باقی میمونه.
کاربر باید تا زمان مشخص شده توسط متغییر email_verification_time اقدام به باز کردن لینک تایید ایمیل خودش بکنه، وگرنه اکانت معلق منقضی میشه.
متغییر admin_confirmation_needed مشخص میکنه که آیا برای نهایی شدن ثبت نام کاربران نیاز به تایید توسط ادمین هست یا خیر. برای تایید ادمین هم زمان معینی میشه تعیین کرد که با متغییر admin_confirmation_time مشخص میشه و اگر تا اون زمان ادمین اکانتی رو تایید نکنه اکانت معلق منقضی میشه.
متغییر login_upon_register مشخص میکنه که درصورت ثبت نام نهایی کاربر آیا کاربر بصورت خودکار لاگین بشه یا خیر (البته این لاگین خودکار تا مدت زمان باز بودن مرورگر وجود داره).
موقعی که نیاز به ایمیل فعال سازی یا تایید ادمین نیست و کاربر ثبت نام میکنه، بلافاصله لاگین هم میشه، چون اکانت مستقیما بعنوان یک اکانت فعال و نهایی در دیتابیس و جدول اصلی اکانتها ثبت میشه.
موقعی که نیاز به ایمیل فعال سازی است اما نیاز به تایید ادمین نیست و کاربر لینک ایمیل فعال سازی رو اجرا میکنه و اکانتش تایید نهایی میشه، بازم بصورت خودکار لاگین میشه.
متغییر max_activation_emails حداکثر تعداد ایمیل های فعال سازی رو که برای یک اکانت معلق میتونه ارسال بشه مشخص میکنه (کاربر ممکنه به هر علتی، تقاضای ارسال مجدد لینک فعال سازی رو بکنه، ولی ما برای جلوگیری از بعضی سوء استفاده ها و آزارها با استفاده از این سیستم، میتونیم تعداد ایمیل های قابل ارسال رو محدود کنیم).
متغییر can_notify_user_about_admin_action مشخص میکنه که درصورت تایید یا حذف یک اکانت معلق توسط ادمین، آیا یک ایمیل که تصمیم ادمین رو اطلاع میده به کاربر مربوطه ارسال بشه یا خیر.
البته کاربران موقع ثبت نام میتونن با برداشتن تیک یک چک باکس در فرم ثبت نام مشخص کنن که نمیخوان چنین ایمیلی براشون ارسال بشه (بخاطر همین اسم این متغییر با can_notify شروع میشه و نه با notify).
-----------------------------------------------------------
متغییرهای پیکربندی در فایل کانفیگ info_lockdown.php
-----------------------------------------------------------
lockdown_period مدت زمانی رو که تعداد خاصی تلاش لاگین موفق در اون بازهء زمانی اجازه داده شده مشخص میکنه.
مقدار lockdown_threshold مشخص میکنه که بعد از چند بار تلاش لاگین ناموفق، در زمان تعیین شده توسط مقدار متغییر lockdown_period، اکانت باید قفل بشه.
نکتهء مهم: مقدار این متغییر نباید از 10 بیشتر باشه، وگرنه سیستم قفل اکانت عمل نمیکنه.
مقدار captcha_threshold مشخص میکنه که بعد از چه تعدادی تلاش لاگین ناموفق برای هر اکانت خاص در مدت تعیین شده توسط lockdown_period، در دفعات بعدی برای لاگین کردن به اون اکانت نیاز به پاس کردن کپچا هم هست. این ویژگی میتونه از قفل شدن بی مورد اکانت توسط روبات های کرکر که اغلب قابلیت کرک کپچا رو ندارن، یا بعضی افراد فضول، جلوگیری کنه (این ایده رو با تست رفتار سیستم لاگین یاهو یاد گرفتم).
نکتهء مهم: مقدار این متغییر نباید از 10 بیشتر باشه، وگرنه عمل نمیکنه.
lockdown_bypass_system_enabled مشخص میکنه که اگر اکانتی قفل شد صاحب اون اکانت میتونه تقاضای ارسال یک لینک مخصوص به ایمیلش رو بکنه که با استفاده از اون لینک بتونه بدون محدودیت به اکانت قفل شده لاگین کنه، یا خیر.
max_lockdown_bypass_emails حداکثر تعداد ایمیل های قابل ارسال توسط سیستم دور زدن قفل اکانت رو مشخص میکنه.
-----------------------------------------------------------
متغییرهای پیکربندی در فایل کانفیگ info_register_fields.php
-----------------------------------------------------------
این فایل کانفیگ حاوی الگو و محدودیت های وضع شده بر روی فیلدهای ثبت نام است. مثلا اینکه حداکثر و حداقل طول نام کاربری چی باشه و از چه کاراکترهایی تشکیل شده باشه و غیره.
راستی نام کاربری درحال حاضر میتونه فقط از حروف انگلیسی و فارسی و اعداد و فاصله های تکی در بین کاراکترها تشکیل شده باشه (شاید لازم باشه بعدا الگوی نام کاربری رو آزادتر کنیم).
ضمنا تنظیمات این متغییرها فقط در بخش ثبت نام موثر نیستن، بلکه در سراسر پروژه هرکجا که نیاز باشه استفاده میشن. مثلا فرمت پسورد که در این فایل تعیین میشه نه تنها در بخش ثبت نام اعمال میشه، بلکه در بخش تعیین پسورد جدید برای اکانت هم اعمال میشه. همینطور فرمت ایمیل در بخش تغییر ایمیل اکانت هم چک میشه.
راستی حداقل طول نام کاربری رو 1 قرار دادم (بخاطر راحتی تست) و احتمالا باید به عدد بیشتری تغییر داده بشه.
-----------------------------------------------------------
متغییرهای پیکربندی در فایل کانفیگ info_password_change_or_reset.php
-----------------------------------------------------------
max_password_reset_emails حداکثر تعداد ایمیل های قابل ارسال سیستم ریست پسورد (ایمیل محتوی لینک لازم برای ریست کردن پسورد درصورت فراموش کردن کلمهء عبور) رو مشخص میکنه (این محدودیت تعداد در یک بازهء زمانی تعریف شده توسط password_reset_period است).
password_reset_period مدت زمانی که لینک ارسال شده در ایمیل ریست پسورد اعتبار داره رو مشخص میکنه.
change_autologin_key_upon_new_password مشخص میکنه که با ریست/تغییر پسورد آیا مقدار کلید لاگین خودکار کاربر در دیتابیس عوض بشه (و در نتیجه هکر محترم احتمالی از سیستم شوت بشه بیرون!) یا خیر. واضحه که توصیهء اکید امنیتی فعال بودن این گزینه است، چون احتمال اینکه تغییر پسورد بخاطر ترس و احتمال سرقت پسورد قبلی بوده باشه کم نیست.
-----------------------------------------------------------
متغییرهای پیکربندی در فایل کانفیگ info_dbms.php
-----------------------------------------------------------
نام کاربری و رمز عبور دیتابیس و نام دیتابیس برنامه در این فایل تعیین میشه.
موقع نصب برنامه اول نیاز دارید تا نام کاربری و رمزعبور MySQL رو در این فایل ست کنید.
-----------------------------------------------------------
متغییرهای پیکربندی در فایل کانفیگ info_identify.php
-----------------------------------------------------------
یکسری اطلاعات مورد استفاده برای کارکرد داخلی برنامه، مربوط به ساختارهای احراز هویت کاربران، در این فایل قرار دارن.
از جمله متغییرهایی در این فایل که کاربران عادی ممکنه نیاز به تغییر اونها داشته باشن:
متغییر long_age که طول عمر کوکی لاگین خودکار رو در حالت لاگین بادوام مشخص میکنه. مثلا اگر میخواید کاربر بتونه حداکثر به مدت 6 ماه نیاز به لاگین دستی نداشته باشه میتونید مقدار این متغییر رو (بر حسب ثانیه) 6 ماه تعیین کنید.
متغییر change_autologin_key_upon_login میتونه سه مقدار بگیره.
حالت اول (0) اینه که درصورت لاگین دستی یا بازدید مجدد یک کاربری که از قبل لاگین هست، کلید لاگین اون کاربر در دیتابیس عوض نمیشه.
حالت دوم (1) اینه که درصورت لاگین دستی، کلید لاگین کاربر در دیتابیس عوض میشه، و بنابراین سیستمهای دیگری که کاربر از قبل روی اونا لاگین بوده از لاگین خارج میشن (ولی نه سیستمی که کاربر الان توش لاگین کرده). این گزینه میتونه باعث افزایش امنیت بشه. هم از نظر احتمال فراموش کردن لاگ آوت روی سیستمهایی که کاربر در جاهای دیگری قبلا استفاده کرده بوده و هم از نظر محدود کردن زمان دسترسی هکری که به هر نحوی تونسته کوکی/کلید لاگین کاربر رو بدست بیاره.
طبیعتا با این کانفیگ، کاربر نمیتونه همزمان روی دو سیستم لاگین بمونه.
حالت سوم (2) اینه که نه تنها در هر بار لاگین دستی، بلکه در هر بار بازدید مجدد، یعنی هر درخواست و Page view توسط کاربر، کلید لاگین عوض میشه. این بالاترین امنیت رو میده و برای جاها و مواردی که به امنیت حداکثری نیاز دارن توصیه میشه، ولی در عین حال بخاطر اینکه در این حالت هر Page view هر کاربر موجب یک عملیات Write در دیتابیس میشه، این گزینه رو بصورت پیشفرض فعال نکردم.
-----------------------------------------------------------
متغییرهای پیکربندی در فایل کانفیگ info_crypto.php
-----------------------------------------------------------
secure_hash_rounds تعداد دورهای هش امنیتی رو مشخص میکنه. یعنی تعداد دورهایی که برای Key stretching موقع تبدیل پسورد کاربر به هش برای ذخیره در دیتابیس، عملیات هش تکرار میشه. مقدار پیشفرض 16 است. توجه کنید که تعداد دورهای واقعی هش از 2 به توان این عدد حاصل میشه (یعنی 2 به توان 16 و غیره).
مقدار متغییر pepper یک رشتهء رندوم 22 کاراکتری متشکل از اعداد و حروف بزرگ و کوچک انگلیسی است که موقع نصب برنامه، و حتما قبل از اجرای بخش نصب دیتابیس برنامه، میتونید بصورت دستی Set کنید تا به این شکل امنیت بازهم بالاتر بره.
این رشته در بخشهای مختلفی از سیستم استفاده میشه و مزیت چندجانبه داره، ولی در اصل در ابتدا فقط بعنوان سالت ثابت موجود در فایل (و نه دیتابیس) برای شرکت در فرایند تولید هش از پسورد کاربران درنظر گرفته شده بود. الان این متغییر مثلا در جریان تولید اعداد رندوم امن هم بعنوان یک منبع آنتروپی اولیه استفاده میشه، و در رمزگذاری هم بعنوان بخشی از کلید ترکیبی استفاده میشه.
البته بنده سیستم رو طوری طراحی کردم که حتی اگر مقدار این متغییر از مقدار پیشفرض تغییر داده نشه، امنیت بازهم بالا باشه، یعنی برای برقراری امنیت به انجام این کار توسط کاربر اتکا نکردم، اما با انجام این کار امنیت طبیعتا بالاتر میره.
مقدار متغییر encrypt_session_files_contents مشخص میکنه که آیا محتویات فایلهای سشن برنامه که در سمت سرور ذخیره میشن رمز بشن یا خیر.
این سیستم رمزگذاری طوری طراحی شده که اگر فعال باشه باعث میشه: 1- کسی قادر به خواندن اطلاعات داخل فایلهای سشن کاربران نیست 2- کسی نمیتونه حتی بصورت کورکورانه این اطلاعات رو دستکاری کنه (اگر دستکاری صورت بگیره، بخاطر وجود HMAC حتما Detect شده و اطلاعات داخل فایل سشن کلا دور انداخته میشه) 3- یک ویژگی جالبی که توسط این سیستم که ابتدا چنین کاربردی رو هدف نداشت ایجاد شد، اینه که حتی اگر هکر Session id کاربران رو از طریق سمت سرور سرقت کنه، قادر نخواهد بود خودش رو بجای اونا جا بزنه، چون اطلاعات داخل فایلهای سشن نه تنها با یک کلید محرمانه ثابت برای کل سایت که موقع نصب برنامه بصورت خودکار تولید شده رمز میشن (با الگوریتم AES128)، بلکه یک کلید رندوم که به ازای هر جلسه تولید میشه و در قالب یک کوکی در کلاینت تا مدت باز بودن مرورگر ذخیره شده هم در تولید کلید ترکیبی مورد استفاده در این رمزگذاری نقش داره. در نتیجه فقط داشتن Session id برای استفاده از سشن دیگران کافی نیست.
البته باید توجه داشت که اگر نفوذگر دسترسی نوشتنی به فایلهای سشن ما داشته باشه بنابراین میتونه یک حملهء DOS رو اجرا کنه (خارج کردن سایت از حالت سرویس دهی به کاربران با تخریب مداوم فایلهای سشن)؛ این سیستم فقط جلوی سرقت اطلاعات و جعل هویت رو میگیره.
بهرحال گذشته از اینها شما میتونید با تعیین مقدار متغییر save_path در فایل info_identify.php دایرکتوری محل ذخیرهء سشن های برنامه رو تعیین و از بقیهء برنامه ها و سایتهای روی سرور جدا کنید تا احتمال دسترسی غیرمجاز به سشن های شما خیلی کمتر بشه.
نکته: البته موقع نصب اولیهء برنامه چون هنوز دیتابیس نصب نشده و کلیدهای سایت ایجاد نشدن، محتویات سشن رمزگذاری نمیشه.
ضمنا برنامهء ما درحال حاضر از سشن استفادهء امنیتی مهمی نمیکنه (لاگین خودکار فقط با استفاده از کوکی و دیتابیس انجام میشه) که بخوایم نگران سرقت سشن کاربران باشیم، اما بهرحال این یک مقدار امنیت بیشتر و لایهء اضافه و اطمینان برای آینده و امکان ذخیرهء اطلاعات مهمتری در سشن هست و کلا سیستمی که میتونه در موارد دیگری هم بدرد بخوره.
مقدار store_request_entropy_probability که عددی بین 0 و 1 است (البته نباید خود صفر باشه) مشخص میکنه که با چه احتمالی آنتروپی موجود در درخواستهای کاربران در دیتابیس ذخیره بشه. این آنتروپی برای اطمینان بیشتر از تولید اعداد رندوم امن و غیرقابل پیشبینی استفاده میشه. تولید اعداد رندوم امن در این برنامه و بطور کلی در وب واقعا مهمه، و توابعی مثل mt_rand و اکثر روشهای دیگری که برنامه نویسان خودشون برای این منظور ابداع میکنن از نظر اصول علم رمزنگاری امنیت کافی ندارن (در بعضی موارد نتیجه میتونه پایین بودن شدید امنیت باشه).
ضمنا این برنامه علاوه بر استفاده از آنتروپی درخواستها، از یک تابع تولید اعداد رندوم خیلی قویتر از توابع و روشهای عادی استفاده میکنه که این تابع درصورت در دسترس بودن منابع تولید اعداد رندوم امن تر در سیستم (مثل /dev/urandom)، از اونها استفاده میکنه.
مقدار پیشفرض این متغییر 1 است که یعنی آنتروپی تمام درخواستها همیشه ذخیره بشه، ولی اگر کاهش کارایی بخاطر بار زیاد عملیات دیتابیس مشاهده شد، میشه مقدارش رو کم کرد و مثلا روی 0.5 یا کمتر گذاشت که بطور مثال این مقدار 0.5 یعنی شانس ذخیرهء آنتروپی در هر درخواست 50% است.
البته متغییر دیگری بنام store_request_entropy_probability2 که در ابتدای بعضی صفحات اصلی تعریف شده، مقدار این متغییر رو Override میکنه، و این بخاطر ارزش بالای آنتروپی بعضی صفحات مثل صفحهء ثبت نام است که میخوایم حتما از این آنتروپی حداکثر استفادهء مفید بشه.
ضمنا حتی اگر آنتروپی یک درخواست ذخیره نشه، ولی در تولید اعداد رندوم همون درخواست شرکت میکنه و بنابراین امنیت کاربران رو بالاتر میبره (ولی امنیت خود برنامه در برابر کاربران/هکرها مسئلهء جداگانه ایست).
-----------------------------------------------------------
متغییرهای پیکربندی در فایل کانفیگ info_cleanup.php
-----------------------------------------------------------
cleanup_probability عددی بزرگتر از صفر و کوچکتر یا مساوی یک است که مشخص میکند با چه احتمالی سیستم پاکسازی دیتابیس بخشهای مختلف برنامه، در هر عملیات درج اجرا میشه. بطور مثال اگر مقدار این متغییر 0.1 باشه، بطور متوسط در هر ده بار که اکانتهای معلق در دیتابیس ذخیره میشن کوئری های پاکسازی هم اجرا میشن تا رکوردهایی رو که تاریخ انقضای اونها گذشته از دیتابیس حذف کنن. همینطور برای اجرای فرایند پاکسازی بقیهء رکوردهای موقتی در جداول دیگری مثل جدول ریست پسورد و غیره، از این متغییر استفاده میشه.
max_nonexistent_users_records مشخص میکنه که حداکثر تا چه تعداد رکورد برای اسامی کاربری ای که واقعا در سیستم وجود ندارن در دیتابیس قابل درج است.
در این مورد باید توضیح بدم که، اگر بخش ثبت نام سیستم رو غیرفعال کرده باشیم یا چک کردن ایجکسی نام کاربری در فرم ثبت نام غیرفعال باشه، وقتی کسی اقدام به لاگین با یک نام کاربری ناموجود در سیستم میکنه، سیستم با اون نام کاربری مثل نامهای کاربری که واقعا در سیستم ثبت شدن رفتار میکنه تا هکر نتونه از رفتار و پیامهای سیستم (مثل قفل شدن یا نشدن یک اکانت بعد از تعدادی تلاش برای لاگین) متوجه بشه که آیا یک نام کاربری خاص در بین کاربران واقعی سیستم وجود دارد یا خیر.
برای این وانمود کردن، سیستم نیاز داره که بطور مثال اطلاعات مربوط به درخواستهای لاگین ناموفق با نامهای کاربری ناموجود در سیستم رو هم بصورت موقتی در دیتابیس ذخیره کنه، اما اگر تعداد چنین رکوردهایی رو در دیتابیس محدود نکنیم، میتونه موجب حجیم شدن بیش از حد دیتابیس بر اثر حمله هایی که برای سوء استفاده از این ضعف صورت میگیرن بشه و فضای آزاد هاست رو هم تاحداکثر پر کنه. بنابراین ما میتونیم حداکثر تعداد رکوردهای مربوط به نامهای کاربری ناموجود رو با این متغییر تعیین کنیم تا اگر تعداد این رکوردها از این تعداد بیشتر شد، یک تعدادی از قدیمی ترین چنین رکوردهایی موقع اجرای پاکسازی دیتابیس حذف بشن تا فضای متوسط اشغال شده توسط این رکوردها از مقدار مشخصی تجاوز نکنه. توجه کنید که ممکنه مقدار پیشفرض این متغییر بیش از فضای مجاز هاست شما باشه و در این صورت باید تغییرش بدید. البته تا وقتی امکان چک کردن نامهای کاربری با استفاده از ایجکس فرم ثبت نام وجود داره، این سیستم عمل نمیکنه، چون وقتی هرکس میتونه وجود یک نام کاربری در سیستم رو با استفاده از ایجکس فرم ثبت نام براحتی چک کنه نیازی به این کارها نیست.
-----------------------------------------------------------
متغییرهای پیکربندی در فایل common.php
-----------------------------------------------------------
این فایل فقط یک فایل کانفیگ نیست و در ابتدای هر صفحهء اصلی برنامه اینکلود میشه، اما دوتا متغییر کانفیگ هم درش هست:
مقدار true برای متغییر کانفیگ debug_mode برای تست و باگیابی برنامه بکار میره و در این حالت مثلا تمام پیامهای هشدار و خطا نمایش داده میشن؛ همچنین موقعی که ایمیل فعال سازی یا ریست پسورد و غیره ارسال میشن، اگر این متغییر true باشه لینک مورد نظر در صفحه echo میشه تا بدون نیاز به داشتن سرور ارسال ایمیل و چک کردن ایمیل بتونید لینک ارسالی رو ببینید و بقیهء مراحل رو با استفاده از کپی و پیست کردن اون در نوار آدرس مرورگر تست کنید. بنابراین برای کاربرد واقعی و عمومی، مقدار این متغییر حتما باید false باشه.
این متغییر درحال حاضر بصورت پیشفرض روشنه تا دیگران بتونن برنامه رو تست کنن و پیام خطا و باگ هایی که در برنامه هستند کشف بشن.
با تعیین متغییر db_installed به مقدار true میتونید برای برنامه مشخص کنید که جدول ها و اطلاعات دیتابیس قبلا نصب شدن. به این شکل دیگه برنامه خودش با اجرای یک کوئری آزمایشی اقدام به تشخیص نصب بودن دیتابیس نمیکنه. این متغییر رو فقط برای افزایش پرفورمنس برنامه (درصورت لزوم) قرار دادم، وگرنه بدون ست کردن این متغییر هم برنامه به خوبی کار میکنه.
پاسخ با نقل قول