فروپاشی امنیت MD5

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

در این منبع نمونهء دو دیتا اومده که هش یکسانی دارن: http://www.mscs.dal.ca/~selinger/md5collision/

اینم یه اسکریپت PHP که برای تست عملیش نوشتم:

<?php



$data1='d131dd02c5e6eec4693d9a0698aff95c 2fcab58712467eab4004583eb8fb7f89 

55ad340609f4b30283e488832571415a 085125e8f7cdc99fd91dbdf280373c5b 

d8823e3156348f5bae6dacd436c919c6 dd53e2b487da03fd02396306d248cda0 

e99f33420f577ee8ce54b67080a80d1e c69821bcb6a8839396f9652b6ff72a70';



$data2='d131dd02c5e6eec4693d9a0698aff95c 2fcab50712467eab4004583eb8fb7f89 

55ad340609f4b30283e4888325f1415a 085125e8f7cdc99fd91dbd7280373c5b 

d8823e3156348f5bae6dacd436c919c6 dd53e23487da03fd02396306d248cda0 

e99f33420f577ee8ce54b67080280d1e c69821bcb6a8839396f965ab6ff72a70';



function convert2binary($str) {

    

    $str=str_replace(array("\n", ' '), '', $str);

    return pack('H*', $str);



}



header('Content-type: text/plain');



echo 'data1 hash: ', md5(convert2binary($data1));

echo "\n";

echo 'data2 hash: ', md5(convert2binary($data2));



?>

همچنین دو فایل اجرایی متفاوت که هش یکسانی دارن: http://www.mscs.dal.ca/~selinger/md5collision/hello.exe و http://www.mscs.dal.ca/~selinger/md5collision/erase.exe

همچنین در این منبع: http://crypto.stackexchange.com/ques...ash-value?rq=1 چند نمونه دیگر از داده های دارای هش یکسان رو آوردن.

دو گواهینامه دیجیتال که امضای یکسانی دارن: http://www.win.tue.nl/~bdeweger/Coll...rtificate1.cer و http://www.win.tue.nl/~bdeweger/Coll...rtificate2.cer

از این دست زیاده. درواقع در حال حاضر میشه براحتی از اینطور چیزها ساخت و روش و الگوریتم و برنامه هاش در دسترس عموم است.

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

خداحافظ md5 :لبخند:

نقل قول:

---

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

---

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

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

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

ولی خوب بعضی جا ها میشه استفاده کرد ولی من هیچ وقت در مسائل امنیتی ازش استفاده نمی کنم. مثلا تابع md5 سرعت اش خوبه برای ساخت یک هش و بر فرض یک هش با تایمر 10 دقیقه ایی مشکلی پیدا نمی کنه و همچنین میشه داخلی ازش استفاده کرد.

نقل قول:

---

نوشته شده توسط abolfazl-z

ولی خوب بعضی جا ها میشه استفاده کرد ولی من هیچ وقت در مسائل امنیتی ازش استفاده نمی کنم. مثلا تابع md5 سرعت اش خوبه برای ساخت یک هش و بر فرض یک هش با تایمر 10 دقیقه ایی مشکلی پیدا نمی کنه و همچنین میشه داخلی ازش استفاده کرد.

---

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

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

دوست عزیز فروپاشی امنیت md5 یعنی شما یک الگوریتمی پیدا کنید که مقدار هش شده را به مقدار اصلیش تبدیل کنه یا سرعت کامپیوتر ها به قدری زیاد بشه که از طریق بروت فورس بتونه یک همچین قابلیتی را فراهم کنه چیزی که شما دارید بیان می کنید در تمام الگوریتم های هش کننده وجود داره و ممکن برای دو مقدار متفوات هش یکسانی تولید بشه !
و در کل بیشتر تئوری است تا عملی برای درک بهتر فرض کنید شما 2 به توان 90 بلاک هش شده داشته باشید احتمال اینکه کلیژن رخ بده حدود 2 به توان -76 است.... به هر حال اگر خیلی نگرانید کلیژن در الگوریتم SHA-512 تقریباً در حد صفر است...

نقل قول:

---

نوشته شده توسط amin1softco

چیزی که شما دارید بیان می کنید در تمام الگوریتم های هش کننده وجود داره و ممکن برای دو مقدار متفوات هش یکسانی تولید بشه !

---

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

نقل قول:

---

و در کل بیشتر تئوری است تا عملی برای درک بهتر فرض کنید شما 2 به توان 90 بلاک هش شده داشته باشید احتمال اینکه کلیژن رخ بده حدود 2 به توان -76 است.... به هر حال اگر خیلی نگرانید کلیژن در الگوریتم SHA-512 تقریباً در حد صفر است...

---

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

نقل قول:

---

نوشته شده توسط amin1softco

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

---

فروپاشی امنیت فقط به این نمیگن!
الگوریتم های هش امنیتی چندین خصیصه دارن، که هرکدام یا چندتا از این خصیصه ها در هر کاربردی اهمیت دارن و زیربنای امنیت هستن.
حالا بحث خیلی تخصصی و ظریف میشه اگر بخوام وارد این جزییات بشم و این خصیصه ها رو نام ببرم و توضیح بدم و کاربردهاشون رو بگم، چون خودمم باید دوباره منابع رو مرور کنم که الان وقت و اولویتش برام وجود نداره.
ولی اسمشون رو براتون میذارم که اگر علاقمند بودید و خواستید خودتون تحقیق کنید:
Pre-image resistance
Second pre-image resistance
Collision resistance
اینا سه خصیصهء حداقلی هستن که هر الگوریتم هش امنیتی باید داشته باشه.

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

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

نقل قول:

---

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

---

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

نقل قول:

---

نوشته شده توسط shahin bahari

crc توان اصلاح خطا ها رو داره

---

تاجاییکه من الان تحقیق کردم، crc عمدتا برای error detection هست و نه error correction.
البته ظاهرا به شکلی و تاحدودی میشه ازش برای error correction هم استفاده کرد، ولی کاراییش در این امر کاملا محدوده. یعنی اینطور بگم که اینطوری نیست که شما یه crc بذارید و بتونید باهاش هر خطایی رو رفع کنید. مثلا یه فایل که چند کیلوبایت هست اونوقت با یک crc که چند بایت بیشتر نیست چه تعدادی از خطاها رو میشه باهاش اصلاح کرد؟!
اگر دنبال قابلیت اصلاح خطای درست و حسابی هستید باید دنبال سیستمهایی گشت که مخصوصا برای همین طراحی شدن، یا این قابلیت هم یکی از اهدافشون بوده. طبیعتا اینطور سیستمها افزونگی متناسب با حجم دیتا رو هم دارن. مثلا فرض کنید 5% حجم خود دیتا رو دارن، نه اینکه یه حجم ثابت و ناچیز باشه. در اون حجم ثابت و ناچیز در مقابل دیتا، طبیعتا نمیشه اطلاعات کافی برای اصلاح خطاهایی که از چند بیت بیشتر هستن رو بدست آورد. معجزه که نیست! اگر میشد دیگه لازم نبود کل یک فایل ذخیره یا منتقل بشه، بجاش یک کد crc رو استفاده میکردن و بقیهء فایل رو از روی همون بدست میاوردن خب! اونوقت میشد اند فشرده سازی!! خطاهایی که اینطور سیستمها میتونن اصلاح کنن خیلی محدوده و بنظرم با حجم دیتا هم رابطهء معکوس داره. یعنی وقتی حجم دیتا خیلی کم باشه، اونوقت میتونن عملا برای چنین کاربردی هم مفید باشن، ولی وقت حجم دیتا زیاد باشه و خطاهای ممکن از چند بیت خیلی بیشتر باشن دیگه کاری ازشون برنمیاد (مثل هش فقط میتونن رخداد خطا رو تشخیص بدن، و نهایت شاید بتونن یه محدوده و شکلی رو برای خطای رخ داده مشخص کنن؛ یعنی مثلا بگه خطا توی محدوده بایت 120 تا 400 بوده، و شاید درمورد تعداد بیت های دچار خطا شده هم بتونه چیزی بگه یا تخمینی بزنه و چندین حالات احتمالی و این حرفها).

چند مطلب در این مورد که نگاهی انداختم:
http://stackoverflow.com/questions/3...ction-with-crc
http://stackoverflow.com/questions/3...587616#8587616
http://stackoverflow.com/questions/9...ection-library

من چقدر یاد این اشپیلن می افتم تا با شما بحث می کنم :کف:
به هر حال من میگم این الگوریتم برای کاربرد های عادی کارایی خودشو داره مگر اینکه طرف عشق رمزنگاری باشه !

نقل قول:

---

ولی مثلا شما برای sha256 بگردید ببینید چنین مطالب و روشها و نمونه هایی پیدا میشه؟

---

شما این مقاله را مطالعه کنید http://eprint.iacr.org/2008/270.pdf تا به فروپاشی sha هم برسید:افسرده: بعدشم این یکی را مطالعه کنید https://eprint.iacr.org/2012/672.pdf

به هر حال امنیتی که این الگوریتم ها فراهم می کنند با تکنولوژی فعلی فراهم شده و اگر از دید احتمالات به قضیه نگاه کنیم وجود تصادم صفر نیست و نزدیک به صفر است شاید در سال 1990 هیچکسی هیچ پیش زمینه ایی نسبت به سال 2015 نداشت و الانم نسبت به سال 2050 یا بعدش نداره پس هر لحظه ممکن تکنولوژی با سرعت و قابلیت بیشتر بیاد و تحقیقات بیشتر باعث عدم اطمینان هر الگور یتمی بشه ...
و اگر یکمی باز تر به این قضایا نگاه کنید اکثراً حملاتی که رخ میده بر اساس پیاده سازی صورت گرفته و زیر ساخت بوده تا اینکه کسی بیاد بخواهد بروت فورس بزنه من اگر اشتپ نکن کنفرانس defcon 17 یک بابایی اومد تمام سرتیفیکیت های SSL سایت ها را زیر سوال برد تنها با اضافه کردن یک کارکتر البته الان پچ شده :چشمک:

نقل قول:

---

نوشته شده توسط amin1softco

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

---

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

نقل قول:

---

شما این مقاله را مطالعه کنید http://eprint.iacr.org/2008/270.pdf تا به فروپاشی sha هم برسید

---

ببین یکسری حملات و ضعفهایی هست که در الگوریتم ها انجام میدن، ولی اینها بصورت تئوریک هست و روی یک شکل ساده و ضعیف شده اون الگوریتم. این هم از همون نوعه! الگوریتم های رمزنگاری و هش معمولا یکسری عملیات داخلی دارن که به یک تعدادی در درون اونا تکرار میشه، پیدا کردن ضعف و حملهء جدی به این الگوریتم ها در این حالت بسیار دشوار بلکه غیرممکنه، بخاطر همین میان و یک مدل ساده شده از اون الگوریتم رو برای تحلیل و پیدا کردن ضعف هدف قرار میدن که از نظر اساس همون روش رو بکار میبره ولی مثلا با کاهش تعداد دورهای درونی الگوریتم فرایند اون رو ساده و امنیتش رو به میزان زیادی تضعیف کردن.
در همین مقاله که گذاشتی همون ابتداش این متن خودش گویاست:
Although these attacks improve upon the existing reduced round SHA-2 attacks, they do
not threaten the security of the full SHA-2 family.
ترجمه: «هرچند این حمله ها نسبت به حمله های با دور کاهش یافته موجود برای sha-2 بهبود یافته اند، اما آنها امنیت خانوادهء کامل sha-2 را تهدید نمیکنند».
پس این ضعف هم درواقع روی الگوریتم ساده شده (تعداد دورهای داخلی کاهش یافته) است و طرف خودش میگه که الگوریتم کامل رو تهدید نمیکنه (البته عبارت full SHA-2 family مقداری مبهم هست ولی من فکر میکنم منظورش توی همون مایه بوده - در این هم که این حمله روی الگوریتم کاهش یافته است شکی ندارم چون الان سرچ کردم در منبع دیگری که این مقاله رو ذکر کرده به همین اشاره شده).

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

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

نقل قول:

---

https://eprint.iacr.org/2012/672.pdf

---

اینم که به همچنین!
همون عنوانش خط اول واضحه: Up to 5 Rounds
یعنی داره میگه تعداد دورها به 5 کاهش داده شده (حالا بعنوان تمرین شما خودت برو تحقیق کن ببین الگوریتم اصلیش چند دور داره).

پس هردوی این موارد که مطرح کردید صرفا تئوریک هستن و روی الگوریتم های اصلی قابل استفاده نیستن. بخاطر همین در حال حاضر sha-2 و sha-3 کاملا امن بحساب میان. البته گفتم که همیشه اینکه در نسخه های ساده شده یک الگوریتم هم ضعف پیدا بشه بهرحال مقداری هشدار دهنده است و ریسک داره، ولی زیاد نیست و قابل قبوله و چون طراحی کردن و سویچ به الگوریتم های جدید کار دشوار و پر هزینه ای است بنابراین این کار رو نمیکنن؛ تازه خود اون الگوریتم های جدید هم ممکنه ضعف های جدی تری درشون پیدا بشه، چون یکی از ضعفهای هر الگوریتم رمزنگاری اینه که جوان باشه و مدت زیادی و توسط عموم و متخصصان زیادی به خوبی تحلیل نشده باشه و محک نخورده باشه و مقاومت نکرده باشه، چون همیشه احتمال خطای انسانی بالاست و بیشتر الگوریتم های رمزنگاری اثبات تئوریک کامل و قاطعی (منظورم به شکل ریاضی وار است) برای امنیت خودشون ندارن و بنابراین باید در عمل هم محک بخورن اگر بطور گسترده ای برای مدت زیادی استفاده شدن و ضعف جدی ای درشون پیدا نشد اونوقت واقعا ارزشمند میشن. ما در حال حاضر چنین الگوریتم هایی داریم؛ بطور مثال AES و RSA. البته حتی این الگوریتم ها هم برنامه برای آینده هست و جایگزین هایی ظاهرا پیشرفته تری براشون طراحی شدن، ولی هنوزم بطور گسترده استفاده میشن و بطور معمول کسی دلیلی برای نگرانی و تعویض اونا با چیز دیگه نداره. در هر فروم تخصصی هم برید و از هر فرد متخصص بپرسید بگید چه الگوریتمی رو برای رمزنگاری استفاده کنم بهتون این الگوریتم ها رو پیشنهاد میکنه (AES برای رمزنگاری متقارن و RSA برای رمزنگاری نامتقارن) و کسی هم ایرادی بهش نمیگیره، چون واقعا مشکل خاصی ندارن. از بین الگوریتم های هش هم من بارها دیدم که SHA-256 رو براحتی توصیه میکنن؛ در حال حاضر دلیلی برای نگرانی درمورد این الگوریتم وجود نداره!

نقل قول:

---

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

---

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

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

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

وقتی ما میگیم از SHA-256 استفاده کنید چون هنوز ضعف و حملهء جدی و خیلی نگران کننده ای دربارش کشف نشده، ولی بهرحال نمیشه تضمین کرد و معلوم نیست شاید تا چند سال دیگه اینطور نباشه! بهرحال راه چاره ای نیست و حداکثر محکم کاری ای که میشه کرد، که البته باید هم کرد (بخصوص در کارهای جدی و حرفه ای)، اینه که از استانداردهای رسمی حال حاضر استفاده بشه. در حال حاضر SHA-256 جزو این استانداردهاست (فکر کنم جزو حداقل و پایین ترین سطح امنیت مورد نیاز، که البته برای کاربردهای متداول من و شما کاملا کافیه - ولی مثلا برای کاربرد در مثلا اسناد حساس دولتی و نظامی و این حرفا استانداردهای بالاتری هم هست).
ضمنا گفتم بازم تکرار میکنم که برای هش پسورد از bcrypt استفاده کنید. حتی SHA-256 یا SHA-512 هم برای هش پسورد مناسب نیست. کاربرد هش پسورد ملاحظات و نیازهایی داره که فقط الگوریتم های مخصوصی که برای اینطور کاربردها طراحی شدن دارن. یکی از این موارد اینه که الگوریتم هش رو عمدا کند و سنگین کردن تا کرکرها نتونن به سادگی تعداد بسیار زیادی ترکیبات پسورد ممکن رو در زمان کوتاهی تست کنن. این بخاطر اینه که بازهء پسوردهایی که اکثریت کاربران استفاده میکنن از بازهء کلیدهای رندوم معمولی خیلی کوچکتره و میشه با brute-force خیلی از این موارد رو کرک کرد.
البته چیزهایی که بنده میگم و توصیه های که میکنم مسلما در سطح حرفه ای و بر اساس استانداردهای علم امنیت و رمزنگاری روز دنیا هستن. حالا برنامه های اکثر ملت در اون حد نیست و حکایت مورچه چیه که کله پاچش چی باشه، خب این ربطی به بنده نداره و چیزی نیست که بخوام و اصلا بتونم درموردش تحلیل و نظر خاصی داشته باشم! مث اینکه ما میگیم شما میخوای موتور یه اتومبیل رو درست کنی باید بر اساس چه استانداردها و حداقل هایی باشه و مثلا یورو4 داشته باشه و این حرفا، حالا کارخونه ها اکثریت اتومبیل های با استاندارد 30 سال پیش درست میکنن و اصلا سطح علم و فناوریشون در اون حد نیست موتورش رو هم درست و حسابی درست کنن با بقیهء قطعات و سیستمهای اتومبیلی که بیرون میدن تناسبی نداره، خب حالا بیایم چی بگیم حالا براشون تحلیل و استاندارد درست کنیم؟! یا اینکه تایید کنیم بگیم اوکی پس مشکلی نداره یورو4 نیازی نیست!! اینو که خودشون هم میتونستن بفهمن و بکنن :لبخند:

ضمنا وقتی میگی هش، تاپیک میزنی درمورد md5، ملت فقط راجع به هش پسورد فکر میکنن! اما کاربرد الگوریتم های هش فقط این مورد نیست و خیلی کاربردهای دیگر هم دارن. جالبی قضیه اینکه اتفاقا در این کاربرد خاص، یعنی هش پسورد، اصولا نیاز به الگوریتم های خاص هش پسورد است و استفاده از الگوریتم های هش عادی مثل md5, sha1, sha-256 و امثالهم اصولی نیست. فعلا تقریبا تنهای کاندیدای موجود در این زمینه bcrypt است. البته چندتا الگوریتم دیگه از این دست هم وجود دارن ولی bcrypt از بقیه یک سر و گردن بالاتره، گرچه مثلا scrypt هم هست که از bcrypt هم پیشرفته تره، ولی چون سابقهء bcrypt رو نداره و به همون گستردگی و مدت استفاده نشده و محک نخورده و تحلیل نشده، بنابراین خیلی ها همون bcrypt رو فعلا انتخاب مناسب یا قابل قبولی میدونن.

این مقاله یکیش مربوط به سال 2008 و یکیش 2012 بوده الان سال 2015 هستیم !
و در حال حاضر پسورد در حال حذف شدن است که برای احراز هویت یک پیامک به گوشی کاربر ارسال می شه و دیگه هش کردن پسورد هم داره از مد می افته زیاد خودتو در گیر نکن
و در ثانی برای کارایی که اکثرا انجام می شه از همون md5 هم استفاده نمی شه نمونش نرم افزار معروف تم ویئر که به 4 تا عدد بسنده کرده که اونم شما بزارید در یک حلقه سریع می تونید بدستش بیارید ! نمونه دیگه وایبر به یک عدد 4 رقمی بسنده کرده و طرف بتونه سایت احراز هویت را پیدا کنه و براش پین تولید کنه می تونه با هر شماره دلخواهی پیام ارسال کنه
پس حتی در کاربرد های عملی خیلی ها سراغ همون md5 هم نمی روند و به یک عدد تصادفی اونم با طول 4 رقم بسنده می کنند که واتس اپ دیگه کلاسش بالا بوده 6 رقمش کرده

این داستان ها فقط برای بانک ها بدرد می خوره و امضا ها و گواهی های دیجیتال که اونا هم دارند از sha استفاده می کنند و کاربرا هم برای اکثرشون 123456 یا شماره موبایل یا کد ملیشون کفایت می کنه در 80% موارد کاربران عادی از همینا استفاده می کنند حالا شما md5 بزن یا sha فرقی نمی کنه نمونه واقعیشم دیتا بیس فیس نما بود که هک شد

و در آخر ما هم موافقیم md5 را کم کم بزارید کنار و از sha یا هر چی که خودتون صلاح می دونید استفاده کنید :چشمک:

نقل قول:

---

نوشته شده توسط amin1softco

و در حال حاضر پسورد در حال حذف شدن است که برای احراز هویت یک پیامک به گوشی کاربر ارسال می شه و دیگه هش کردن پسورد هم داره از مد می افته زیاد خودتو در گیر نکن
و در ثانی برای کارایی که اکثرا انجام می شه از همون md5 هم استفاده نمی شه نمونش نرم افزار معروف تم ویئر که به 4 تا عدد بسنده کرده که اونم شما بزارید در یک حلقه سریع می تونید بدستش بیارید ! نمونه دیگه وایبر به یک عدد 4 رقمی بسنده کرده و طرف بتونه سایت احراز هویت را پیدا کنه و براش پین تولید کنه می تونه با هر شماره دلخواهی پیام ارسال کنه
پس حتی در کاربرد های عملی خیلی ها سراغ همون md5 هم نمی روند و به یک عدد تصادفی اونم با طول 4 رقم بسنده می کنند که واتس اپ دیگه کلاسش بالا بوده 6 رقمش کرده

---

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

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

نقل قول:

---

این داستان ها فقط برای بانک ها بدرد می خوره و امضا ها و گواهی های دیجیتال که اونا هم دارند از sha استفاده می کنند و کاربرا هم برای اکثرشون 123456 یا شماره موبایل یا کد ملیشون کفایت می کنه در 80% موارد کاربران عادی از همینا استفاده می کنند حالا شما md5 بزن یا sha فرقی نمی کنه نمونه واقعیشم دیتا بیس فیس نما بود که هک شد

---

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

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

نقل قول:

---

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

---

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

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

حقیقت امر حوصله بحث کردن با شما را ندارم ولی خوب یک نگاهی به صحبت های مدیران یاهو و قابلیت ویندوز 10 مایکروسافت بندازید بدی نیست و در مورد حرفی که زدم در مورد وایبر لینک زیر کدشم موجوده
https://github.com/timtux/viber-pin-...iber-pin-bf.rb

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

نقل قول:

---

نوشته شده توسط amin1softco

یک نگاهی به صحبت های مدیران یاهو و قابلیت ویندوز 10 مایکروسافت بندازید

---

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

نقل قول:

---

بدی نیست و در مورد حرفی که زدم در مورد وایبر لینک زیر کدشم موجوده
https://github.com/timtux/viber-pin-...iber-pin-bf.rb

---

مطالعه کردم.
اینکه هم از کدش فهمیدم و هم بعدش صفحهء اصلی پروژش رو نگاه کردم خودش هم اشاره کرده که ضعف از طرف برنامه نویسی سمت سرور وایبر هست!
اینا سیستم محافظت دربرابر Brute-force موثری برای این سیستم Pin خودشون نذاشتن.

Four digit, no bruteforce protection, API-axss - A winning concept. Or well, they have "some kind" of bruteforce "protection". After something like ten tries they increment the PIN-code by 1.

I've tried to inform them about this. But they ignore my tweets and mails. They ignoring me results in me ignoring them.

خلاصش داره میگه که سیستم محافظت در برابر bruteforce اصولی ای برای این بخش نداشتن. میگه من باهاشون در این باره تماس گرفتم ولی اونا ایمیل های منو نادیده گرفتن، و نادیده گیری اونا باعث شد که منم اونا رو نادیده بگیرم (و این اکسپلویت رو بنویسم).

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

نقل قول:

---

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

---

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

ضمنا یه چیزی که منم میخواستم اشاره کنم اینکه طول خیلی از کدهای sms هم که میفرستن بیش از حد کمه. بنظر من یک کد عددی چهار رقمی بیش از حد ضعیفه. حتی اگر عمر کوتاهی داشته باشه و فرضا بعد از 3 تلاش اشتباه هم باطل بشه و کد جدیدی تولید بشه (اصلا شما بگو فقط یک تلاش).
این طرف هم که اکسپلویت این زیرسیستم وایبر رو نوشته به چهار رقمی بودن Pin هم اشاره کرده، یعنی بنظرش کد بیش از حد کوتاهی است.
البته ضعف اصلی سیستم Pin وایبر همون محافظت بسیار ضعیف در برابر Brute-force است (نوشته تنها کاری که میکنه اینه که بعد از 10 تلاش، عدد Pin رو یکی اضافه میکنه)، ولی در مرحلهء بعد طول کد هم بهتره بیشتر باشه. چون فرضا اگر یک روبات درست کنیم که بیاد و در بازهء 0000 تا 9999 درخواست ارسال کنه (با شماره های موبایلهای مختلف/رندوم منظورمه)، حتما یکیش بالاخره تصادفا درست از آب درمیاد. این تعداد 10 هزار درخواست تعداد زیادی نیست و شدنیه. حالا باز اگر یه محدودیتی روی IP و تعداد درخواستهای ممکن در بازهء زمانی مشخصی گذاشته باشن این حمله خیلی کندتر و دشوارتر میشه، ولی بنظر من بازم مشکل وجود داره (ممکنه از IP های زیادی بصورت پراکسی استفاده بشه - مثل حمله های DDOS).

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

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

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

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

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

بنده چون تاحالا اینطور سیستمی طراحی و پیاده سازی نکردم حضور ذهن و ایدهء قبلی نداشتم، ولی تا اینجا به این نتایج رسیدم!

نقل قول:

---

نوشته شده توسط amin1softco

و در حال حاضر پسورد در حال حذف شدن است که برای احراز هویت یک پیامک به گوشی کاربر ارسال می شه و دیگه هش کردن پسورد هم داره از مد می افته زیاد خودتو در گیر نکن
و در ثانی برای کارایی که اکثرا انجام می شه از همون md5 هم استفاده نمی شه نمونش نرم افزار معروف تم ویئر که به 4 تا عدد بسنده کرده که اونم شما بزارید در یک حلقه سریع می تونید بدستش بیارید ! نمونه دیگه وایبر به یک عدد 4 رقمی بسنده کرده و طرف بتونه سایت احراز هویت را پیدا کنه و براش پین تولید کنه می تونه با هر شماره دلخواهی پیام ارسال کنه
پس حتی در کاربرد های عملی خیلی ها سراغ همون md5 هم نمی روند و به یک عدد تصادفی اونم با طول 4 رقم بسنده می کنند که واتس اپ دیگه کلاسش بالا بوده 6 رقمش کرده

این داستان ها فقط برای بانک ها بدرد می خوره و امضا ها و گواهی های دیجیتال که اونا هم دارند از sha استفاده می کنند و کاربرا هم برای اکثرشون 123456 یا شماره موبایل یا کد ملیشون کفایت می کنه در 80% موارد کاربران عادی از همینا استفاده می کنند حالا شما md5 بزن یا sha فرقی نمی کنه نمونه واقعیشم دیتا بیس فیس نما بود که هک شد

---

والا همین مورد که خودت ارائه کردی به وضوح نشون میده که سهل انگاری در امنیت کار درستی نیست. مثل این بابا که اومده با این حرکت یعنی آبروی وایبر رو برده! آدم از خودش میپرسه از کجا معلوم لابد جاهای دیگه هم همینطور ضعیف کار کردن و گند زدن که فردا هکرها راحت میتونن از طریق نرم افزارشون بیان توی گوشیم و هرکاری میخوان بکنن. خودشون رو جای من جا بزنن، پیامهای منو بخونن، به دوستانم پیام بفرستن و کلاه برداری و آزار کنن. هرکس بخواد میتونه بره تمام contact های توی گوشی منو دربیاره و اطلاعات تمام بستگان و دوستان و کس کارم رو سرقت کنه!
خیلی بده که یک نرم افزار که اینقدر کاربر و موفقیت و اهمیت پیدا کرده بعدش چنین چیزهایی توش پیدا بشه. اینطوری ممکنه اعتبارش از بین بره و کاربرانش کم بشه و ارزش مالیش هم مسلما میتونه صدمهء شدیدی بخوره. میتونه کلا از میدان موفقیت خودش به در بشه! فکر کن این بابا تازه یک آدم معمولیه و فقط برای تست و نمایش و بعدم بخاطر اینکه بهش توجهی نکردن باوجود اینکه سعی کرده بهشون اطلاع و هشدار بده این کد رو نوشته، اما یک گروه هکری یا از شرکتهای رقیب اگر بخوان میتونن با چندتا از این آسیب پذیری ها، در مقیاس گسترده تری صدمهء جدی به امنیت نرم افزار وارد کنن و کاری کنن همهء کاربران هم مطلع بشن و حتی صدمه از نظر Privacy و امنیت و کاربری به کاربران در سطح گسترده وارد کنن، طوری که اعتماد کاربران سلب بشه و اصلا مجبور بشن اون نرم افزار رو دیگه استفاده نکنن و برن به سوی این همه نرم افزارهای مشابه رقیب که هست.
این مورد خودش یک اثبات واضح هست بر این امر! نه چیزی که شما خلافش به طرز عجیبی نتیجه گیری کردید!
ضمنا گفتم که این کدها هیچوقت جای پسورد رو نمیگیرن. داستان فرق میکنه و این صحبت کلی که شما میفرمایید خیلی مبهم و نامفهومه برای من به شخصه! همهء مسائل رو ریختید توی مخلوط کن و قاطی کردید! مسائلی که اینقدر ربط و یکسانی کاربرد و خواص و شرایط ندارن. هرچیزی به جای خودش. کد Pin یک بار مصرف و sms یک چیزه و پسورد چیز دیگه. البته بهم ارتباطهایی دارن و میتونن مکمل هم باشن یا در مواردی هم جایگزین هم، ولی به هیچ وجه اینطور نیست که یکی بتونه یا معقول و مفید باشه که در همهء شرایط و کاربردها جایگزین دیگری بشه. پسورد هنوز کاربرد گسترده و مهم خودش رو داره و خواهد داشت (حداقل تا میان مدت). بحث نرم افزارهای موبایل جداست چون اینا دستگاههای شخصی هستن و تنها یک نفر ازشون استفاده میکنه و خودشون مثل یک توکن فیزیکی هستن. تازه اون Pin هم گفتم که یک بار مصرفه فقط برای اثبات شماره موبایل و بعدش یک توکن رندوم خیلی قوی تر جایگزین میشه در داخل نرم افزار. اینجا دیگه نیازی به پسورد نیست، چون گوشی یک وسیلهء شخصی و انحصاری مالکش است و انگار یک پسورد قوی خودکار براش تولید و بصورت دائمی درش ذخیره شده، مثل اینکه شما در سایت برنامه نویس لاگین میکنید و گزینهء بیاد سپاری رو میزنید دیگه لازم نیست تا 6 ماه دیگه هم مجدد پسورد رو وارد کنید و بصورت خودکار سیستم شما رو شناسایی میکنه و برای این احراز هویت از پسورد شما هم استفاده نمیشه بلکه یک توکن جداگانه رندوم داره با امنیت حتی به مراتب بیشتر از پسورد و بحث Brute-force روش مطرح نیست.
اما حتی همون Pin هم باوجود اینکه عمر کوتاهی داره و فقط برای یک مرحلهء نگاشت شماره موبایل استفاده میشه و بنظر میرسه اهمیت چندانی نداره، مشاهده میکنید که دچار ضعف هست چون طراحی ضعیف بوده و چون دست کم گرفتن، و عواقبش هم از بین رفتن امنیت و ایجاد راه سوء استفاده برای دیگران میشه. شاید علت اینکه بسیاری از این سیستمها به همین شکل ضعفهای قابل توجهی دارن، جوان تر بودن اینطور سیستمها نسبت به سیستمهای احراز هویت قدیمی و جا افتاده و تجربه شده و محک خورده ای مثل پسورد هست که اشتباهات در مقیاس گسترده تجربه شدن و ضعفها و استانداردهای لازم رو از توش درآوردن و بطور گسترده این مطالب منتشر شده و آموزش داده میشه. حالا وقتی اینطور سیستمها بیشتر اهمیت پیدا کردن، بیشتر شناخته شدن، بیشتر استفاده شدن، هکرها رو به خودشون جذب کردن، کدنویسان بیشتری درشون کار کردن، حمله ها و صدمات بیشتری صورت گرفت، گند کاریها و ماست مالی های برنامه نویسان اونا بیشتر افشا شد، اونوقت مجبور میشن که امنیتش رو بالا ببرن. البته بالا بردن امنیتش هم کار سختی نیست. کافیه همون مواردی که در پست های قبلی گفتم رعایت بشن. یعنی طول Pin بقدر کافی زیاد باشه (بنظرم حداقل 6 رقم)، تعداد تلاشهای ناموفق ممکن زیاد نباشه، بعد از تلاشهای اشتباه هم برای مدت قابل توجهی امکان فعال سازی اون شماره قفل بشه. خلاصه یک سیستم که در برابر Brute-force امنیت کافی بده! البته طول Pin رو هرچی بیشتر کنیم، نیاز به مثلا قفل کردن طولانی هم کمتر میشه. خلاصه جای مانور و پیکربندی بقدر کافی داره. من نمیدونم واقعا چرا این Pin ها رو اکثرا اینقدر کوتاه میگیرن، ولی بهرحال بازم اگر از جهات دیگه اون سیستم ضد Brute-force مناسب در کار باشه تا حد زیادی حمله ها رو هزینه بر و کم بازده میکنه و انگیزهء نفوذگرها و خرابکارها کاهش پیدا میکنه.
کلا فیلد نرم افزارهای موبایل و اینها چون نسبت به نرم افزارهای PC و وب خیلی جوان تر هست و خوب بررسی و کنترل و تجربه نشده و هنوزم بخاطر کاربردهای گسترده و مهم PC، بخش اعظم وقت و انرژی متخصصان امنیت (و همچنین خیلی از هکرها) روی محیط کلاسیک و قدیمی تر صرف میشه، توسعه دهندگان فکر میکنن امنیت توش اهمیت کمتری داره یا هکرها علاقه و مهارت و تمرکز روی این حیطه ندارن، و خلاصه اینطور علل و عوامل که جای تحقیق و تحلیل داره، بنابراین عجیب نیست اگر کارهای ناشیانه و اشتباه و ضعف و نقص بخصوص از نظر امنیت درش زیادتر رخ بده و راحتتر پنهان بمونه؛ حتی توی نرم افزارهای خیلی پرکاربرد و دارای ارزش مالی بالا مثل همین نمونه واضح که مشاهده فرمودید و شکی در این مسئله باقی نمیذاره. ولی وضعیت برای همیشه اینطور نمیمونه و حتی اگر بمونه بازم دلیل نمیشه که این مسئله قابل قبول و عاقلانه و باعث سهل انگاری و الگو قرار دادن باشه!! ربط خاصی به PC و وب هم نداره. امنیت امنیته. همیشه نیاز و مهمه. بیشتر اصولش هم کم و بیش ثابته و حتی توی همون موبایل هم اکثر اصول و روشهایی که تا حالا بوده و هست عینا کاربرد و اهمیت داره. من فکر میکنم کلا توسعه دهندگانی هم که سابقه و تجربه قبلی کافی توسعه نرم افزارهای کلاسیک PC و وب رو دارن خیلی بیشتر بینش و مهارت منجمله در فیلد امنیت دارن تا کسانیکه از ابتدا بدون سابقه و دانش چندانی در برنامه نویسی به سراغ برنامه نویسی موبایل میرن. چون یادگیری و محیط برنامه نویسی موبایل طبیعتا نسبت به PC خیلی محدودتر هست. مثل اینکه میگیم طرف از اول برنامه نویسی رو با ویژوال استودیو شروع کرده و یاد گرفته هیچوقت به پای برنامه نویسانی که متکی و وابسته به این ابزارها نیستن نمیرسه، یادگیری و کار فقط یا عمدتا در حیطهء موبایل هم بنظر من برنامه نویس سطحی و محدود از حداقل بعضی جوانب رو بوجود میاره. خب توی وب هم نگاه کنیم مثلا منابع در زمینهء برنامه نویسی عادی و کلاسیک و PC و وب طبیعتا خیلی بیشتره چون سابقه و برنامه نویسان و فعالیت و منابع خیلی بیشتری داره. برنامه نویس موبایل توی سرچ های خاص خودش و منابع خاص خودش سیر میکنه و زیاد با منابع دیگه مواجه نمیشه و ارتباط برقرار نمیکنه و طبیعتا مطالعه و یادگیری گسترده و عمیقی نداره.

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

نقل قول:

---

نوشته شده توسط freeman99

تاجاییکه من الان تحقیق کردم، crc عمدتا برای error detection هست و نه error correction.
البته ظاهرا به شکلی و تاحدودی میشه ازش برای error correction هم استفاده کرد، ولی کاراییش در این امر کاملا محدوده. یعنی اینطور بگم که اینطوری نیست که شما یه crc بذارید و بتونید باهاش هر خطایی رو رفع کنید. مثلا یه فایل که چند کیلوبایت هست اونوقت با یک crc که چند بایت بیشتر نیست چه تعدادی از خطاها رو میشه باهاش اصلاح کرد؟!
اگر دنبال قابلیت اصلاح خطای درست و حسابی هستید باید دنبال سیستمهایی گشت که مخصوصا برای همین طراحی شدن، یا این قابلیت هم یکی از اهدافشون بوده. طبیعتا اینطور سیستمها افزونگی متناسب با حجم دیتا رو هم دارن. مثلا فرض کنید 5% حجم خود دیتا رو دارن، نه اینکه یه حجم ثابت و ناچیز باشه. در اون حجم ثابت و ناچیز در مقابل دیتا، طبیعتا نمیشه اطلاعات کافی برای اصلاح خطاهایی که از چند بیت بیشتر هستن رو بدست آورد. معجزه که نیست! اگر میشد دیگه لازم نبود کل یک فایل ذخیره یا منتقل بشه، بجاش یک کد crc رو استفاده میکردن و بقیهء فایل رو از روی همون بدست میاوردن خب! اونوقت میشد اند فشرده سازی!! خطاهایی که اینطور سیستمها میتونن اصلاح کنن خیلی محدوده و بنظرم با حجم دیتا هم رابطهء معکوس داره. یعنی وقتی حجم دیتا خیلی کم باشه، اونوقت میتونن عملا برای چنین کاربردی هم مفید باشن، ولی وقت حجم دیتا زیاد باشه و خطاهای ممکن از چند بیت خیلی بیشتر باشن دیگه کاری ازشون برنمیاد (مثل هش فقط میتونن رخداد خطا رو تشخیص بدن، و نهایت شاید بتونن یه محدوده و شکلی رو برای خطای رخ داده مشخص کنن؛ یعنی مثلا بگه خطا توی محدوده بایت 120 تا 400 بوده، و شاید درمورد تعداد بیت های دچار خطا شده هم بتونه چیزی بگه یا تخمینی بزنه و چندین حالات احتمالی و این حرفها).

چند مطلب در این مورد که نگاهی انداختم:
http://stackoverflow.com/questions/3...ction-with-crc
http://stackoverflow.com/questions/3...587616#8587616
http://stackoverflow.com/questions/9...ection-library

---

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

نقل قول:

---

نوشته شده توسط shahin bahari

کلا این همه نسخه مختلف برای crc تا الان روش کار شده که روی اصلاح خطا بیشتر بتونن مانور بدن

---

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

نقل قول:

---

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

---

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

نقل قول:

---

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

---

بله میدونم. منتها بحثی که بنده در این تاپیک کرده بودم دربارهء استفاده از CRC روی فایل یا بهرصورت داده هایی با حجم بیشتر بود که گفتم بجاش از md5 هم میشه استفاده کرد و ضریب تشخیص خطای md5 از CRC هم بیشتره (کلا الگوریتم های هش امنیتی بخاطر دقت و امنیت بالا و طول خروجی بیشتری که دارن این واقعیت درموردشون صدق میکنه). البته شاید برای فایل واقعا اونقدر دقت و ضریب نزدیک 100% تشخیص خطا مهم نباشه، ولی منکه ترجیح میدم بجای CRC از هش استفاده کنم (مگر اینکه محدودیت و مشکل در پرفورمنس وجود داشته باشه - الگوریتم های هش طبیعتا پردازش و منابع سخت افزاری بیشتری نیاز دارن). خب بهرحال CRC بنظرم از الگوریتم های هش (منظورم الگوریتم های هش امنیتی است، چون در معنای عام CRC خودش هم یک نوع الگوریتم هش هم است) خیلی قدیمی تره و شاید به همین دلیل در اینطور کاربردها از هش کمتر استفاده میشه چون CRC قبلا در اینطور کاربردها خوب شناخته و جاگیر و استاندارد شده (البته بنظر میرسه امروزه و برای برنامه نویسان و نرم افزارهای جدیدتر دیگه این قضیه چندان مصداق نداره). مثلا winrar از CRC برای چک کردن سالم بودن فایلهای فشرده استفاده میکنه. همینطور خیلی از نرم افزارهای دیگه. ضمنا winrar یک سیستم و الگوریتم دیگر برای recovery فایلهای خراب هم داره که طبیعتا افزونگی متناسب با حجم دیتا داره. یعنی مثلا 1 درصد حجم دیتا حجم رکورد اطلاعات ریکاوری میشه، و تازه با این حال میگه که با این حجم بطور معمول میشه 6 دهم درصد از حجم فایل آرشیو رو اونم اگر این خرابی بصورت متوالی باشه بازیابی کرد. این متن رو از Help خودش کپی کردم:

a size of the recovery information will be about 1% of the total archive size, usually allowing the recovery of up to 0.6% of the total archive size of continuously damaged data.

نقل قول:

---

خلاصه که crc تو لایه انتقال تعریف میشه و عمدتا توسط خود سخت افزار بررسی میشه ولی هش تو خود برنامه ها!

---

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

نقل قول:

---

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

---

همهء اینا که میگید، منجمله HMAC، SHA-512 و غیره، برای هش پسورد مناسب نیستن. یعنی اگر بخواید واقعا طبق اصول و علم روز عمل کنید و برنامه تون در سطح حرفه ای باشه. وگرنه که بقول شما زیاد فرقی نمیکنه. الگوریتم حرفه ای برای هش پسورد، با فاصلهء زیاد از الگوریتم های دیگر، bcrypt است. البته اگر تونستید و خواستید از scrypt هم میتونید استفاده کنید که حتی از bcrypt هم یک سر و گردن بالاتره از نظر علمی، ولی خب جوان هست و هنوز خوب آزموده و تحلیل نشده و گستردگی ساپورتش هم به اندازهء bcrypt نیست، و بخاطر همین متخصصان هنوزم برای عموم عام bcrypt رو براحتی توصیه میکنن.
یک مشکل الگوریتم های دیگر اینه که میشه براحتی اونا رو در کارت گرافیک یا سخت افزارهای سفارشی (مثل FPGA) به شکل موازی پیاده سازی کرد که با سرعت بسیار زیادی (بسیار بیشتر از سرعت اجرای معمولی روی PC) اجرا بشن و در هر ثانیه میتونن ده ها و صدها میلیون و حتی میلیاردها ترکیب پسورد ممکن رو تست کنن! همیشه در امنیت باید فرض کرد هکر الگوریتم مورد استفاده شما رو میدونه و دانش و امکانات و انگیزه اینطور کارها رو هم داره. وگرنه امنیتتون اصولی و در سطح بالا نخواهد شد!

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

حالا شما میگی آقا برنامه ها و کاربرد و اطلاعات ما در اون حد نیست، من کاری ندارم. دانش و علاقه من در این سطحه و باید در این سطح فعالیت بکنم. مثال همون کارخونه اتومبیل سازی هست که ماشین های زپرتی با استاندارد 30 سال پیش درست میکنه! من کاری به اونا ندارم، من دارم استاندارد اروپایی روز دنیا رو براتون میگم، میگم آقا Euro 4 و Euro 5 اینه، ISO 9999999999999 اینه، موتور سوپرانژکتوری لیزری با سیستم سوپاب آرک سینوسی کتانژانت 45 درجه اینه :بامزه: حالا شما میخوای استفاده کن، ارزشمند بدون، میخوای هم استفاده نکن. ولی بنظر من حیفه واقعا چون اینا که در دسترس همه هستن و هزینه و محدودیتی بابتشون وجود نداره. یخورده اگر زحمت بکشید و دقت کنید شاید بتونید خوب درک و بعدهم استفاده کنید :لبخند: تازه از وجود یکی مثل منم بهتره استفاده کنید، چون شاید دروغ نباشه بگم در کل ایران معلوم نیست تک و توک چند نفر دیگه با اینقدر دانش امنیت و رمزنگاری در بالاترین سطوح علمی روز دنیا وجود داشته باشن. اصلا شاید فقط خودم یک نفر باشم! چون شخصا تاحالا کسی و نشانه ای بر این امر مشاهده نکردم! یکی دو سال من فقط در این زمینه ها داشتم مطالعه و تحقیق میکردم با تمام قوا و توانایی خوندن و درک مطلب قوی ای که در زبان انگلیسی در منابع فنی دارم. کار واقعا سختی بود و باید بگم مطالب در کل بسیار گسترده و حجیم و پیچیده هستند در این باب و نسبت به مفاهیم برنامه نویسی عادی تفاوت زیاد دارن و بحث خیلی علمی و تئوریک و ریاضیات هم توش داره (من خودم تا یه جاهایی پیش رفتم که دیگه ریاضیاتم کم اومد و نتونستم جلوتر برم - هرچی دیدم متخصصان مطرح این رشته اکثریت قریب به اتفاق تحصیلات و مدرک آکادمیک رشتهء ریاضی یا فیزیک دارن). این علوم در کشور ما گویا اصلا ناشناخته هستن و هنوزم حتی تا حد زیادی هستن و رشتهء دانشگاهی که خبر ندارم ولی فکر نمیکنم استاد درست و حسابی هم پیدا بشه یا به تعداد زیاد و کافی باشه. کسی هم که توی این مملکت فکر این چیزا نیست همه دنبال دخل و خرج و معاش و درآمد و پول و ثروت و چیزای دیگه هستن! بخاطر همین من یکی یه استثناء شدم. انگار در کل ایران یک نفر دیگه مثل من و با شرایط من نبوده و نیست و فقط من یکی بودم دنبال این چیزهای خیلی خاص و تقریبا ناشناخته در ایران رفتم و تونستم یک چیزهایی بفهمم و یاد بگیرم و توانایی هایی بدست بیارم. بقول بعضیا هیچکس اینقدر علاف نیست هیچکس اینقدر دیوانه نیست که دنبال چیزهایی بره اینقدر سخت و زمانبر که توی ایران کاربرد چندانی ندارن و پولی ازشون درنمیاد. تازه بازم بیشتر از این هست ولی دیگه بیشتر کسی پیش بره و بتونه در این زمینه بی نقص بشه باید گفت براوو و بنظرم واقعا شاهکار کرده و نابغه است :تشویق:

نقل قول:

---

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

---

دیر وقت هست و حال ندارم تیکه تیکه جواب بدم. البته تمام متن شما رو خوندم.
اگه درمورد انواع CRC یه سرچ کنید میبینید که پریتی همون crc1 هستش و کلا این 2 تا چیز جدا از همی نیستن!
در مورد کاربرد ها و محاسبه crc هم تو درس مخابرات حسابی کار کردم و خوب با این قضیه که کجا باید استفاده کنم و کجاها داره استفاده میشه آشنا هستم.
به طور مستقیم هم با سخت افزار محاسبه ی CRC و هش (MD5-SHA1,2 )کار کردم و آشنا هستم باهاشون. یکم اعتماد داشته باشید و قبول کنید این 2 تا جایگزین هم نمی تونند باشند.
---------------------------------------------
تیکه دوم رو هم خوندم گفتم این رو اضافه کنم!
من کارم طراحی سایت و این داستان ها نیست برای همین در مورد اینکه برای انتقال یه پسورد از چند تا هش استفاده میشه چقدر امن هستو این داستان ها اطلاعی ندارم و کار نکردم. میخواستم بگم که این بحثی که با شما داشتم در مورد کاربرد CRC و هش بود نه اینکه تو کار خاص امنیتشون چطور هست. پس شاید در مورد امنیت حق با شما باشه! شاید نباشه! در مورد چیزی که کار کردم نظر دادم نه کل تاپیک!

نقل قول:

---

نوشته شده توسط shahin bahari

اگه درمورد انواع CRC یه سرچ کنید میبینید که پریتی همون crc1 هستش و کلا این 2 تا چیز جدا از همی نیستن!

---

جان؟ :متعجب:
پریتی هموون CRC است؟!!
A parity bit, or check bit is a bit added to the end of a string of binary code that indicates whether the number of bits in the string with the value one is even or odd. Parity bits are used as the simplest form of error detecting code.
ترجمه: «یک بیت پریتی یا چک بیت بیتی است که به انتهای یک رشته از کد باینری افزوده میشود تا نشان دهد تعداد بیت های دارای مقدار یک در رشته زوج است یا فرد. بیت های پریتی بعنوان ساده ترین شکل تشخیص خطا استفاده میشوند.»
https://en.wikipedia.org/wiki/Parity_bit
به این میگن پریتی. اسمش هم روشه. در دوره های درسی هم چند بار با همین تعریف مطرح شده. شما اگر تعریف دیگری داری با سندش بیار.

اما درمورد CRC:
a type of hash function used to produce a checksum in order to detect errors in data storage or transmission
«یک نوع تابع هش استفاده شده برای تولید یک checksum برای آشکارسازی خطاها در ذخیره سازی یا انتقال داده ها»
https://en.wikipedia.org/wiki/CRC

و اما در مقالهء اصلی CRC به دنبال کلمهء Parity گشتم اینا رو یافتم:

The simplest error-detection system, the parity bit, is in fact a trivial 1-bit CRC: it uses the generator polynomial x + 1 (two terms), and has the name CRC-1.
«ساده ترین سیستم تشخیص خطا، بیت پریتی، درواقع یک CRC بسیار ساده یک بیتی است؛ آن از چند جمله ای تولیدکننده x + 1 استفاده میکند (2 جمله) و نام CRC-1 را دارد»

پس از این جهت حق با شما بود که پریتی هم یک نوع CRC است و بنده الان فهمیدم، اما بهرصورت مقایسهء یک چیزی مثل پریتی با مثلا CRC32 در عمل معنای چندانی نداره چون قدرت CRC32 در تشخیص خطا کجا (مثلا وینرر برای تشخیص خطا در کل یک فایلی که در فایل آرشیو ذخیره شده از CRC32 استفاده میکنه)، و قدرت پریتی که ساده ترین و محدودترین روش آشکارسازی خطاست کجا! زمین تا آسمان تفاوت است. یک بیت کجا و 32 بیت کجا! پریتی چند درصد خطاها رو میتونه تشخیص بده؟ برای چه حجمی از دیتا؟ بعد مقایسه کنید با CRC16,32,64 خب معلومه اصلا قابل مقایسه نیست و کاربردهای اینا کاملا جداست. پریتی بقول خودتون فقط برای بلاک های خیلی کوچک دیتا و جایی که نیازهای تشخیص خطا خیلی محدود هستن و نیاز به تشخیص بیشتر انواع خطاها نیست کاربرد داره. ما نمیتونیم یک فایل یا چند کیلوبایت دیتا رو فقط با یک بیت پریتی مورد حفاظت قرار بدیم! بحث منم درمورد فایل بود، بازم تکرار میکنم.

نقل قول:

---

در مورد کاربرد ها و محاسبه crc هم تو درس مخابرات حسابی کار کردم و خوب با این قضیه که کجا باید استفاده کنم و کجاها داره استفاده میشه آشنا هستم.

---

خب درمورد بحث تشخیص خطا در دیتاهای حجیم و فایل ها اگر اطلاعات و بحثی دارید بفرمایید. من تا اینجا گفتم که از CRC32 در این کاربرد استفاده میشه، خب اینکه روشنه و مستند هست و نمونه هم براتون آوردم، و گفتم که بجاش میشه از md5 هم استفاده کرد و md5 حتی از CRC32 هم دقیقتره (در اینطور کاربردها و در مقایسه با CRC32)، که باز اینم روشنه و مطلب بی پایه و بدون نمونه ای نیست. علتش هم اینه که md5 برای کاربردهای امنیتی ساخته شده و هدفشون این بوده که نه تنها در برابر تغییرات تصادفی دیتا بلکه در برابر تغییرات عمدی و هوشمندانه دیتا که توسط حمله کننده ها انجام میشن هم مقاوم باشه، درحالیکه در اینطور کاربردهای امنیتی CRC به هیچ وجه امن نیست (به منابع مراجعه کنید). ضمن اینکه CRC64 هم که بگیرید، بازم md5 دو برابر اون طول خروجی داره، و این یعنی امکان تصادم دو هش/checksum خیلی کمتره.

نقل قول:

---

به طور مستقیم هم با سخت افزار محاسبه ی CRC و هش (MD5-SHA1,2 )کار کردم و آشنا هستم باهاشون. یکم اعتماد داشته باشید و قبول کنید این 2 تا جایگزین هم نمی تونند باشند.

---

گفتم که. بازم تاکید میکنم در کاربردی که من گفتم (محافظت از فایل/داده های حجیم) md5 میتونه جایگزین CRC32 و CRC64 بشه. هیچ شکی هم در این ندارم، چون بارها در منابع یا نمونه های عملی هم دیدم و از تئوری و نیازها در این زمینه مطلع هستم. بارها در منابع به این دوتا و اشتراکی که در این زمینه در کاربرد دارن اشاره شده و بنده خوندم. از افراد حرفه ای! شک دارید یک تاپیک در stackoverflow بزنم براتون تا مشخص بشه. گرچه فکر کنم حتی اگر سرچ هم کنیم قبلا پرسشها و مطالب کافی در این زمینه در این سایت موجود باشه. بنده میدونم چی میگم دوست عزیز! فکر کردی همینطور اومدم دربارهء چیزی که اطلاعات و صلاحیت ندارم نظر بدم؟ اینکه من گفتم در این کاربرد CRC32 رو میشه با md5 جایگزین کرد اصلا حرف بنده نیست در اصل و در جریان مطالعاتی که دربارهء الگوریتم های هش و مسائل امنیتی داشتم بارها به این مقایسه و نکته ها اشاره شده بود بنده هم از همونجا یادم مونده. البته فقط منابع امنیتی و الگوریتم های هش نبوده و جاهای دیگر هم بارها به وضوح چنین مطالبی رو خوندم، چون مطالعات بنده از فیلد امنیت و رمزنگاری هم خیلی گسترده تر بوده.

یک بار دیگه حرفی رو که بنده در ابتدا زدم مرور میکنیم:

نقل قول:

---

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

---

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

و بقیه چیزی که در ابتدا گفته بودم:

نقل قول:

---

حالا md5 هم میتونه نقش این الگوریتم رو بازی کنه و تازه خیلی هم دقیقتر و مطمئن تره نسبت به CRC در این زمینه.

---

فقط در این بخش بیانم ابهام داشت قبول دارم و اصلاح میکنم! منظور من اگر دقیق بخوام بگم جایگزین کردن CRC32 و CRC64 در کاربرد تشخیص خطا (با ضریب تشخیص بالا) در کل یک فایل بود. اینو گفتم چون بارها نمونه این کاربرد رو دیدم (بطور مثال WinRAR) و در منابع هم بهش اشاره شده و اینم که یک الگوریتم هش امنیتی مثل md5 هم میتونه همین نقش رو در این کاربرد ایفا کنه در منابع متعددی که خوندم بهش اشاره شده بوده.
حالا در این شک و بحثی اگر دارید بفرمایید. وگرنه که دیگه هیچ و با هم مخالفتی نداریم :لبخندساده:

Cryptographic hash functions have many information security applications, notably in digital signatures, message authentication codes (MACs), and other forms of authentication. They can also be used as ordinary hash functions, to index data in hash tables, for fingerprinting, to detect duplicate data or uniquely identify files, and as checksums to detect accidental data corruption.

«توابع هش رمزنگاری تعداد زیادی کاربرد در امنیت اطلاعات دارند، به ویژه در امضاهای دیجیتال، کدهای احراز هویت پیام، و اشکال دیگر احراز هویت. آنها همچنین میتوانند بعنوان توابع هش معمولی برای ایندکس کردن دیتا در hash table ها، برای fingerprint کردن، آشکار سازی داده های تکراری یا شناسایی یکتای فایلها، و بعنوان checksum برای آشکارسازی خرابی تصادفی داده ها استفاده شوند.»

منبع: https://en.wikipedia.org/wiki/Crypto..._hash_function

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

مرسی جالب و مفید بود. برا من که تازگی داشت!


تور کیش

جملات :

ولی دیگه به پایان کار خودش رسیده

md5 رو برای همیشه به سطل آشغال انداخت و فراموشش کرد!

درواقع در حال حاضر میشه براحتی از اینطور چیزها ساخت

این دیتا رو میشه طوری گنجاند که اختلال و مشکلی هم در کار سیستم ایجاد نکنه.

------------ کاملا نادرست هستند ------------

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

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

------------------------------------------------------------------------------------

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

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

ضمنا فرض بر اینکه مقالات خارجی معتبر به این موضوع پرداخته باشند
اونها فقط گفتند که یکتا نیست که درست هم هست یکتا نیست اما ممکنه با تب و تاب گفته باشند بلکه 4 جا مثل اینجا لینک بشوند

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

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

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

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

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

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

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

نقل قول:

---

نوشته شده توسط kb0y667

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

- این تابع قدرت / سرعت / امنیت بسیاربالایی داره ؛
- جعل یا دور زدن ش تقریبا غیرممکنه ؛
- این تابع تاریخ انقضاء نداره و همیشه محبوب خواهد ماند ؛

------------------------------------------------------------------------------------

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

---

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

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

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

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

فقط یک بخش از یک نمونه از این منابع متعدد تخصصی و معتبر و رسمی رو براتون میذارم که فکر نکنید نمیتونم این کار رو بکنم:

Do not use the MD5 algorithm
Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use.

ترجمه: «از الگوریتم md5 استفاده نکنید. توسعه دهندگان نرم افزار، مراجع گواهینامه های دیجیتال، صاحبان وبسایت ها، و کاربران باید از استفاده از md5 به هر شکلی اجتناب کنند. آنطور که تحقیقات قبلی نشان داده است، این الگوریتم باید از نظر رمزنگاری شکسته شده و نامناسب برای استفادهء بیشتر بحساب بیاید».


منبع: http://www.kb.cert.org/vuls/id/836068

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

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

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

کاربر SZsXsZS

شرمنده اگه ناراحت یا عصبانی ت کردم

Vulnerability Note VU#836068 - MD5 vulnerable to collision attacks
سرتیتر همین مقاله نوشته شده :
Overview

Weaknesses in the MD5 algorithm allow for collisions in output. As a result, attackers can generate cryptographic tokens or other data that illegitimately appear to be authentic.

یعنی چی ؟!

یعنی اگه افراد سودجو خودشون رو بکشن
عمه و ننه شون بیاد جلو چشم هاشون
میتونن بعد از 17 سال تلاش
به زور یه md5 پیدا کنند که با هم تطابق داشته باشه
پس
برای تامین امنیت سایتهای بزرگی مثل wikipedia یا گوگل نباید از این الگوریتم استفاده بشه

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

آخه مگه یه نفوذگر چند دفعه فرصت تلاش داره برای حمله؟
وقتی بعد از 3 دفعه IP بلاک بشه چی؟
آخه فرض کن مثلا brutforce حمله کنه ، مگه چندبار در ثانیه میتونه request ارسال کنه؟

نقل قول:

---

نوشته شده توسط kb0y667

Vulnerability Note VU#836068 - MD5 vulnerable to collision attacks
سرتیتر همین مقاله نوشته شده :
Overview

[COLOR=#333333]Weaknesses in the MD5 algorithm allow for collisions in output. As a result, attackers can generate cryptographic tokens or other data that illegitimately appear to be authentic.

یعنی چی ؟!

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

---

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

نقل قول:

---

آخه مگه یه نفوذگر چند دفعه فرصت تلاش داره برای حمله؟
وقتی بعد از 3 دفعه IP بلاک بشه چی؟
آخه فرض کن مثلا brutforce حمله کنه ، مگه چندبار در ثانیه میتونه request ارسال کنه؟

---

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

سلام
مقدار collision rate برای md5 حدود 2 بتوان منهای 64 هست و واقعا عدد کمیه
اما من با نظر حمیدرضا بیشتر موافقم.
این الگوریتم برای کارهای دم دستی خوبه اما برای موارد امنیتی اصلا مناسب نیست

حتی برای این الگوریتم سال 2006 یک سری collision generator تولید شده!!!
برای md4 در هر 1 ثانیه و برای md5 در هر 10 دقیقه میشه یک collision جدید کشف کرد... (با cpu اینتل core i7 تست کردم)
ضمیمه ها رو ببینید

سال 2008 نسخه جدید یعنی md6 برای رفع نواقص نسخه قبلی معرفی شده