MD5

[arenaw]

دوستان کسی میتونه منو راهنمایی کنه که ام دی فایو چیه و چجوری کار میکنه؟!
من چیزی که از رمز نگاری میدونم اینه که به طور مثال مثال کلمه salam تبدیل به tbmbn میشه با کلیده 1 (یعنی همه حروف +1 )
حالا این چه جوری میخواد هک بشه؟ مثلا من متن هام رو با کلید 912313#@!$#@$2342r3jfd$%R3fs رمز نگاری میکنم، این کلید چجوری میخواد کشف بشه؟ در صورتی که کسی قرار نیست متن رمز نگاری شده من رو توی بانکم ببینه؟ حالا این نمیدونم اسمش چه مدل رمز نگاری ایه و خودم به صورت ابتکاری ازش استقاده میکنم، ولی میخوام بدونم مثلا ام دی فایو چجوری کار میکنه؟

[eshpilen]

MD5 رمزنگاری به اون شکلی که شما میگید نیست. یعنی برگشت پذیر نیست که با همون کلید دوباره بتونی داده های اولیه رو بازیابی کنی.
MD5 الگوریتم هشه.

منتها همهء اینا در حیطهء علم رمزنگاری (Cryptography) طبقه بندی میشن.

ضمنا اون رمزنگاری شما هم که مال عصر حجره! امنیتش از 0 تا 100 شاید 1 باشه!!
درستش اینه که از الگوریتم های مدرن و استاندارد استفاده کنید؛ نه اینکه خودتون بدون هیچ دانش و تخصصی الگوریتم رمزنگاری اختراع کنید.


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

[arenaw]

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

[eshpilen]

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

[arenaw]

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

[eshpilen]

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

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

و تازه این تنها خاصیت مفید سالت رندوم نیست.
مثلا سالت رندوم باعث میشه که کرکرها نتونن از هشهای از قبل محاسبه شده (مثل Rainbow table ها) استفاده کنن.
باعث میشه تشخیص داده نشه که چند اکانت مختلف یک پسورد یکسان دارن.

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

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


و اینکه در کل چجوری امنیت دیتابیس رو بالا ببرم که هکر نتونه حتی اطلاعات معمولی رکوردها رو ببینه
خب اینکه دیگه مبحث دیگه هست. SQL Injection و غیره.
امنیت گسترده و پیچیده است و وقتش نیست که بخوایم همش رو کامل توضیح بدیم.
برای اطلاعات بیشتر باید منابع زیادی رو که هست بخونید. بخصوص منابع انگلیسی.
من خودم بعد چند سال مطالعه هنوزم دارم یکسره مطالعه میکنم.
مثلا چند روزه دارم مقاله های موجود در این صفحه رو میخونم: https://www.owasp.org/index.php/Cheat_Sheets
(حالا جالب اینکه قبلا مطالب این سایت رو خونده بودم، اما اینا ظاهرا تازه اضافه شدن)
غیر از اینکه چند سوال هم در سایتهای خارجی پرسیدم.
قبل از اونم داشتم یکی دوتا کتاب PDF رو برای مدتی مطالعه میکردم.
قبلش هم که حساب کنی شاید مجموعا چند سال کارم همین بوده!
خلاصه تمومی نداره.
بعد از این همه مدت بازم روی یه چیزایی شک میکنم، موارد جدیدی بنظرم میرسه، گهگاه با بعضی نکات برخورد میکنم که قبلا نمیدونستم یا دقت و آگاهی کامل نداشتم، و غیره.

[Veteran]

سالت چیه میشه یک مثال بزنین

[eshpilen]

Salt یک رشتهء رندوم است که به ازای هر پسورد یکیش رو تولید میکنید و قبل از هش کردن اون رو به پسورد اضافه میکنید.
یعنی هش ما مثلا اینطوری تولید میشه:


$hash=hash('sha256', $salt.$password);

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

Salt رو همراه هش در دیتابیس ذخیره میکنیم؛ چون موقع تولید مجدد هش از پسورد کاربر بهش نیاز داریم.

حالا اگر سالت ثابت (خارجیها بهش Pepper میگن) هم داشته باشیم:


$hash=hash('sha256', $pepper.$salt.$password);

ضمنا این سیستم هنوز کامل نیست؛ چون عملیات هش رو چند هزار بار تکرار نکردیم تا Key stretching هم داشته باشیم (بخاطر کند کردن عملیات هش).

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

مال من مثلا اینطوریه:


$hash=hash('sha256', $pepper.$salt.$password, true);

$tmp17=pow(2, $rounds)-1;

while($tmp17--) $hash=hash('sha256', $hash.$password, true);

یعنی پسورد رو هم داخل حلقه در هر دور هش دخالت دادم.
تازه جدیدا توی ویکیپدیا خوندم که بهتره سالت رو هم در هر دور دخالت بدیم!

[Veteran]

Salt رو همراه هش در دیتابیس ذخیره میکنیم؛
با تشکر فراوان.
یعنی توی جدول کاربران علاوه بر فیلد مثلا اسم و رمز یک فیلد سالت هم داشته باشیم که سالت رندوم رو در اونجا ذخیره کنیم ؟

[eshpilen]

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

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

[lordofphp]

به نام خدا
سلام خوبین؟
ببینید همونطور که آقای eshpilen (http://barnamenevis.org/member.php?148005-eshpilen) عزیز گفتند (ایشون تو زمینه امنیت خیلی خوبن ) عمل کنید ولی استفاده از الگوریتم های دیگه یا سنگین اگر احیانا خواستی استفاده کنی حواست به استفاده از منابعش باشه البته شایدمشکلی یش نیاد ولی تو وب سایت های پربازدید و هاست های اشتراکی (البته استاندارد نه این هاست ... (نگم بهتره خودتون میدونید)
البته هاست های اشتراکی هم ریسک پذیره از نظر شخصی من
که اینجا بهتره ترکیبی کار کنید مثلا sha256 و یه الگوریتم دیگه البته sha256 قویه البته برای کار های متوسط در مورد sha512 هم تحقیق کنید به نتایج خوبی میرسید
ولی به طور کلی فصل هشتم (رمزنگاری) کتاب شبکه های کامپیوتری تننبام بخونید قشنگ از پایه توضیح داده
دیتابیس رو حرفه ای طراحی کن مثلا جدول ادمین اسمش نذار ادمین یه اسم دیگه بذار یا تیبل های مشابه برای گول زدن هکر ! سعی کن هکرت ردگیری کنی یا مشغول به کار با قسمت های تقلبی کنی و...
درپناه وراه ایزدمنان پیروز وپایدار باشید
یاحق