نوشته اصلی از سوی
sonixax
نه Md5 سوراخ نیست !
چرا هست.
در نت سرچ کنی کلی منبع واسه این هست.
حالا من از ویکیپدیا شروع میکنیم، اگر میگی اعتبار نداره بازم میتونی سرچ کنی یا رفرنس های ذکر شده در همون مقاله رو بررسی کنی: MD5 - WiKi
ابتدای مقاله همون دست راست نگاه کن ببین چی نوشته:
A 2013 attack by Xie Tao, Fanbao Liu, and Dengguo Feng breaks MD5 collision resistance in 218 time. This attack runs in less than a second on a regular computer.
ترجمه: «یک حمله در سال 2013 توسط Xie Tao، Fanbao Liu، و Dengguo Feng مقاومت دربرابر تصادم MD5 را در زمان 2 به توان 18 میشکند. این حمله در کمتر از یک ثانیه روی یک رایانهء معمولی اجرا میشود».
بوسیلهء همین ضعف چند سال قبل تونستن یک گواهینامهء دیجیتال جعلی درست کنن. هر روز هم سوراخش رو گشادتر کردن!!
بخاطر همین دیگه از md5 در گواهینامه های دیجیتال استفاده نمیشه (نباید بشه - حالا شاید بعضی موارد به هر علتی رعایت نشه).
یکی از خواصی که الگوریتم های هش مورد استفاده در رمزنگاری باید داشته باشد، بهش Collision resistance میگن. میگم یکی از خواص، نه تمام خاصیت! داستان داره واسه خودش.
البته اینم بگم که علت اینکه از md5 در هش کردن پسورد نباید استفاده بشه در اصل بخاطر این قضیهء شکسته شدن Collision resistance در اون نیست و بخاطر مسائل دیگری هست. یکیش بخاطر اینه که MD5 برای سرعت اجرای بالا در سخت افزار و نرم افزار طراحی شده و برای کاربردهایی مثل هش طراحی نشده. الگوریتم های هشی هستن (مثل BCRYPT و SCRYPT) که مخصوص هش کردن پسورد ساخته شدن و عمدا طوری طراحی شدن که سرعت و مصرف منابع برای اجرای اونا در سخت افزار/نرم افزار خیلی کمتر و بیشتر باشه؛ به این شکل کرک این هشها خیلی دشوارتر و پرهزینه تر و زمانبرتر میشه.
ولی بنظر بنده بطور کلی چون md5 شکسته شده هست، بهتره احتیاط بشه و در کاربردهای دیگری هم که اون سوراخ شدگی خاص درشون تاثیر نداره استفاده نشه، چون بهرصورت یک چیزی که یک ضعف و سوراخی توش درآمد احتمالش نسبت به بقیهء الگوریتم ها باید بیشتر فرض بشه که ممکنه در آیندهء نزدیک درش سوراخ ها و ضعفهای دیگری هم بطور مستقل یا وابسته به اون ضعف اولیه، کشف بشن. البته این استنباط منطقی بنده هست!
بطور کلی بعضی کاربردها هست (مثل هش و HMAC) که این قضیهء سوراخ شدگی md5 در خصیصهء Collision resistance روشون تاثیری نداره، ولی بطور کلی بازم بهتره حداقل به مرور و در موارد شدنی، استفاده از این الگوریتم کنار گذاشته بشه و به الگوریتم های جدیدتر سویچ بشه.
البته وقتی طرف تونسته به بانک اطلاعتی شما نفوذ کنه پس میتونه مقدار سالت شما رو هم استخراج کنه . برای همین من هیچ وقت سالت رو روی دیتابیس ذخیره نمیکنم یا از سالت ثابت استفاده نمیکنم . یعنی همیشه سالت باید رندوم باشه .
البته دو نوع سالت داریم:
1- یکی سالت رندوم به ازای هر هش؛ سالت هر هشی فقط با همون هش بکار میره.
2- یکی دیگر یک سالت ثابت به ازای کل برنامه/دیتابیس که در فرایند هش تمام پسوردها دخالت داده میشه؛ به این نوع سالت بقولی pepper هم گفته میشه.
ما برای راحتی، از این به بعد به نوع اول با اسم salt اشاره میکنیم و به نوع دوم با اسم pepper.
salt هیچ نیازی نیست که جدای از هش نهایی ذخیره بشه.
اما pepper باید در جای جداگانه و ترجیحا امن تری ذخیره بشه.
از دید متخصصان امر salt ضروری است، اما pepper چندان ضروری نیست (اما اگر بتونید و داشته باشید و جای امن تری ذخیرش کنید خوبه خب).
سالتها رو در پوشه ای یک لول پشت شاخه روت به صورت فایلهای مجزا قرار بدید.
salt نیازی نیست در جای جداگانه ای از هش ها ذخیره بشه.
دلیلش رو هم نفهمیدی بگو برات بگم.
اما pepper رو خب میشه در چنین جاهایی ذخیره کرد، ولی بنظر منکه زیاد هم صرف نمیکنه که اینقدر بخوایم بپیچونیم. من pepper رو در source برنامه میذارم. اینطوری نصب خودکار برنامه و مسائل کانفیگ (مثل پرمیشن ها و بعضی محدودیت ها در دسترسی به دایرکتوری ها که ممکنه در بعضی سرورها/کانفیگ ها وجود داشته باشن) هم ساده تر و بدون مشکل میشه.
در برخی جاها که حفاظت از اطلاعات خیلی مهمه یک سرور دیگه با IP جداگانه درنظر گرفته میشه و سالتها روی اون ذخیره میشند. دسترسی تمام IP ها به جز IP سروری که اسکریپت روش اجرا میشه به سرور ریموت بسته میشه . طبیعی هست که این روش هزینه اش هم بیشتره . حتا ممکنه که بخشی از سالت روی یک ریموت سرور و بخش دیگرش روی یک ریموت سرور دیگه باشه یا اصلن بیش از یک سالت روی بیش از یک ریموت سرور باشه.
مثلا کدوم جاها؟
بعدش چنین چیزی توسط متخصصان واقعی امنیت و رمزنگاری طراحی و پیاده سازی شده؟
متخصصان امنیت درست و حسابی کم هستن، و تخصص رمزنگاری درست و حسابی هم که واقعا کمه.
برنامه نویسان معمولی که هیچ، ولی خیلی افراد خیلی بخوان حرفه ای فکر کنن فکر میکنن مثلا هکرها این نقش رو دارن، اما هکرها هم فقط یک بخش و یک گوشه ای از این دانش و مهارت ها رو دارن و در خیلی زمینه های دیگه تقریبا هیچ اطلاعات درست و حسابی ندارن و نمیتونن سیستمهای اصولی و علمی طراحی و پیاده سازی کنن.
این چیزی که گفتی، اولا گفتم که سالت معمولی (رندوم و به ازای هر هش) رو نیازی نیست در جای دیگری نگهداری کنیم. هرجا هش رو میذارید سالت رو هم ذخیره کنید. اصلا در بعضی توابع مخصوص هش پسورد، سالت هم در درون رشتهء خروجی بصورت یکپارچه تعبیه شده و کل این خروجی رو میتونید در یک فیلد در دیتابیس ذخیره کنید.
اگر هم بحث سالت ثابت یا همون pepper هست، خب این فقط یکی به ازای تمام برنامه و هش ها هست. و این یکی رو میشه چنین ترفندهایی روش شد، ولی فکر نمیکنم از نظر دردسر و افزایش پیچیدگی و احتمال خرابی و اختلال در بخشهای مختلف یک سیستم چند بخشی به این شکل که تضمین ثبات و اطمینان به قابلیت دسترسی برنامه رو پایین میاره و پرفورمنس رو هم کاهش میده، صرف بکنه. حداقل بعضی از متخصصان، خود pepper رو هم چندان ضروری نمیدونن، چه برسه به اینکه بخاطر حفاظت ازش بخوایم این همه سیستم رو پیچیده کنیم و هزینه و ریسک های دیگری رو درش وارد کنیم و به پارامترهای مهم دیگر در برنامه ها و سیستمها و سایتها خدشه وارد کنیم.
من دیده ام که برخی از برنامه نویسان حتا خود هش رو هم روی یک سرور دیگه نگهداری میکنند .
تا جای ممکن بهتره که دسترسی فیزیکی به هیچ کدام از سرورها وجود نداشته باشه و حتا بهتره سرورها در یک پایگاه واحد نباشند - که البته این دیگه از نکات برنامه نویسی نیست
کدوم برنامه نویسان؟
آدمهایی که سرخود و بدون دانش تخصص و صلاحیت علمی، سیستمهای امنیتی و رمزنگاری از خودشون طراحی و پیاده سازی میکنن کم نیستن. درمقابل متخصصان واقعی و ذیصلاح خیلی کم هستند.
بطور معمول اگر از الگوریتم های هش مخصوص و اصولی با رعایت تمام اصول علمی استفاده بشه، امنیت درحد خوبی است که برای بیشتر برنامه ها کافی بنظر میاد. یعنی صرف نمیکنه بخواید بخاطر محافظت از یک هش که گرچه مهم اما در نهایت تنها بخشی از مسائل و پارامترهای امنیتی یک سیستم است، این همه پیچیدگی و دردسر و هزینه و ریسک های دیگر ایجاد کنید. اصلا پیچیدگی و افزایش موجودیت های درگیر خودش یکی از دشمنان امنیت است و کار تامین امنیت رو دشوارتر و پر ریسک تر میکنه.
اگر الگوریتم و روش هش شما بی نقص باشه، امنیت هش ها نسبتا بالاست و پسوردهایی که درپیت نبوده باشن میشه گفت امکان کرکشون تقریبا از بین میره (هزینه/زمانش اینقدر زیاده که از دید کرکرها صرف نمیکنه یا اصلا کرکش عملا ممکن نیست). اما پسوردهای درپیت و متداول طبیعتا امنیت چندانی ندارن.
دست آخر بهتره از یکی روشهای یک یا 2 در اسکریپتتون بهره ببرید چون هر هشی با صرف زمان کافی و سخت افزار مناسب قابل هک شدن هست.
خیر هر هشی قابل کرک نیست.
بستگی به میزان قوی بودن پسوردش داره+امنیت افزوده ای که روشهای پیشرفته و علمی هش کردن اضافه میکنن.
و البته این امنیت در خیلی موارد بصورت تقریبی قابل محاسبه و اطمینان کافی هم هست.
میتونیم آنتروپی پسورد رو محاسبه کنیم (بر حسب بیت)، بعد مثلا چند بیت امنیت افزوده هم با استفاده از key stretching در الگوریتم هش بدست آمده، با هم جمع میکنیم، و تازه این تنها سد و هزینه برای کرک کردن نیست و موارد دیگری هم در عمل وجود دارن اغلب، ولی ما دیگه بدترین شرایط رو درنظر گرفتیم.
این مسئلهء آنتروپی هم در رمزنگاری به همین شکل کار میکنه. مثلا چرا نمیتونن رمزگذاری 128 بیتی AES رو کرک کنن؟ چون کرکش اونقدری مصرف انرژی و زمان میبره که عملا غیرممکنه (حالا بگذریم از منابع سخت افزاری مورد نیازش). تازه 128 یک Margin امنیتی زیادی هم داره و مثلا شاید حتی 90 بیت هم کافی باشه. در واقع در منابعی که بنده مطالعه کردم به 80 بیت هم بعنوان حداقل قابل قبول اشاره شده (برای پسورد).
پاسخ با گفت‌آورد