آیا چند بار کد گذاری پسورد (hash-md5 ) تاثیری داره؟

[MRmoon]

آِا چند بار پسوردمون رو کدگذاری کنیم تاثیر مثبتی داره رو هک نشدنش؟

[omidabedi]

شما فقط یکبار پسوردتو هش کنی کافیه اینجوری فقط حجم کوئری هاتو زیاد میکنی.
کاره اضافیه

[MMSHFE]

دوست عزیز چرا راهنمایی اشتباه میکنید؟ به حجم کوئری چه ارتباطی داره؟ هش چندباره توی PHP انجام میشه. بعلاوه این یک مسئله امنیتی هست که چند مزیت داره:
1- چون چندبار هش انجام میشه، درنتیجه سرعت تولید هش نهایی کاهش پیدا میکنه و لذا، حملاتی مثل Bruteforce با مشکل کند شدن سرعت چک کردن هر رمز مواجه میشن که در خیلی از موارد این نوع حمله رو خنثی میکنه یا اینقدر تأخیر میندازه که بالأخره Firewall یا خودتون متوجه حمله بشین.
2- بخاطر هش چندباره، احتمال پیدا شدن هش نهایی توی جدول هش سایتهایی که به MD5 Decrypter معروفن خیلی پایین میاد.
3- چون عملیات چک کردن رمز و هش کردن فقط یکبار موقع لاگین و یکبار موقع رجیستر انجام میشه، آنچنان تأثیری در افت سرعت سایت نداره.

[eshpilen]

اصلا در علم رمزنگاری یه چیزی داریم به اسم key stretching (http://en.wikipedia.org/wiki/Key_stretching) که یک کاربردش هش کردن پسورده (کاربرد دیگرش هم مشتق کردن کلیدهای رمزنگاری از پسوردهاست).
الگوریتم های مخصوص هش پسورد مثل bcrypt (http://en.wikipedia.org/wiki/Bcrypt)و scrypt (http://en.wikipedia.org/wiki/Scrypt) هم دارای key stretching هستند (بعلاوهء تمهیدات امنیتی دیگر).

ولی اینکه میگید چندبار هش رو تکرار کنیم، key stretching نمیشه (هرچند تاحدی میتونه از جهات دیگه برای امنیت مفید باشه)، چون تعداد تکرار برای key stretching ای که تاثیر مهمی داشته باشه باید بقدر کافی زیاد باشه (حداقل چند هزار بار).
ضمنا در الگوریتم key stretching یکسری جزییات رعایت بشن خیلی بهتره، که میتونید مثال و توضیحاتش (http://en.wikipedia.org/wiki/Key_stretching#Hash_based_key_stretching) رو در همون مقالهء ویکیپدیا ببینید.

[omidabedi]

دوست عزیز چرا راهنمایی اشتباه میکنید؟ به حجم کوئری چه ارتباطی داره؟ هش چندباره توی PHP انجام میشه. بعلاوه این یک مسئله امنیتی هست که چند مزیت داره:
1- چون چندبار هش انجام میشه، درنتیجه سرعت تولید هش نهایی کاهش پیدا میکنه و لذا، حملاتی مثل Bruteforce با مشکل کند شدن سرعت چک کردن هر رمز مواجه میشن که در خیلی از موارد این نوع حمله رو خنثی میکنه یا اینقدر تأخیر میندازه که بالأخره Firewall یا خودتون متوجه حمله بشین.
2- بخاطر هش چندباره، احتمال پیدا شدن هش نهایی توی جدول هش سایتهایی که به MD5 Decrypter معروفن خیلی پایین میاد.
3- چون عملیات چک کردن رمز و هش کردن فقط یکبار موقع لاگین و یکبار موقع رجیستر انجام میشه، آنچنان تأثیری در افت سرعت سایت نداره.

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

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

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

از طرفی بیایم یه فرض کنیم که اقا به سایت ما حمله شده چگونه (نمیدونم اسمشو چی بزارم ولی مثل DDOS یکی از زیر شاخه هاشه) اینجوری که بیان درخواست هش 500 کد رو همزمان توسط هکرها (از طریق خود فرمی که ثبت نام میکنه مثلا) به سرور ارسال کنن.ایا سرور دووم میاره ؟؟؟ (میدونم میگید برای این مشکل هم راه هست) اما چرا با یک کار اشتباه بیایم اینجوری کل سایت رو به فنا بدیم.

"مثبت اندیشان هواپیما میسازند و منفی نگران چتر نجات"

[omidabedi]

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

[omidabedi]

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

"مثبت اندیشان هواپیما میسازند و منفی نگران چتر نجات"

البته بگم فقط یکی از دلایلش میتونه این باشه یکی دیگه از دلایلشم جلوگیری از sql injection شاید باشه
نگید نگفتم بریزید سرم :دی

[rezaonline.net]

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

در مورد اون مساله هم ، شما بهتره در مورد حملات به سایت کمی تحقیق کنید .
راستی تا حالا اسم کرک کردن پسورد رو شنیدید؟

[omidabedi]

اووف !

راستی تا حالا اسم کرک کردن پسورد رو شنیدید؟

http://www.md5this.com/

[omidabedi]

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


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

[omidabedi]

در مورد اون مساله هم ، شما بهتره در مورد حملات به سایت کمی تحقیق کنید .


شما که تحقیق کردید میشه نتیجه ی تحقیقتونو بگید تا ما هم یاد بگیریم؟

[rezaonline.net]

سرچ کنید توی انجمن آقای eshpilen مفصلا در مورد این مسائل تاپیک دارند .

راستی نحوه پاسخدهی به تاپیکها هم جالبه .
یه خط رو میخونید بعد جواب میدید .
یاد مفسر پی اچ پی می افتم:بامزه:

[omidabedi]

:ddd
چشم حتما

[MMSHFE]

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

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

از طرفی بیایم یه فرض کنیم که اقا به سایت ما حمله شده چگونه (نمیدونم اسمشو چی بزارم ولی مثل DDOS یکی از زیر شاخه هاشه) اینجوری که بیان درخواست هش 500 کد رو همزمان توسط هکرها (از طریق خود فرمی که ثبت نام میکنه مثلا) به سرور ارسال کنن.ایا سرور دووم میاره ؟؟؟ (میدونم میگید برای این مشکل هم راه هست) اما چرا با یک کار اشتباه بیایم اینجوری کل سایت رو به فنا بدیم.
دوست گرامی، 4000 بار هش MD5 پشت سر هم حداکثر چند هزارم ثانیه زمان میبره. 500 درخواست همزمان که سهله، 5000 درخواست همزمان هم حداکثر 10-20 ثانیه زمان CPU سرور رو میگیره. این چیزها برای سرورها مشکلی ایجاد نمیکنه.
یک چیز دیگه اینکه اره خب می ارزه برای پسورد ادمین یا کاربرایی با سطح دسترسی بالا از اینگونه روش استفاده کنی.

ولی اگر یک پسورد ایمن وارد کنیم درصد هک شدنش خیلی ضعیفه.
یا حتی مثلا این کار بهتره که بیایم به صورت دستی به اول پسورد هش شده چند کاراکتر اضاف کنیم که دیگر هیچ دیتابیس پسورد MD5 قادر به هک کردنش نیست و سرعتت هم بالا میره
این درسته ولی شما نمیتونید (و درست هم نیست) که همه کاربران رو مجبور کنید رمزی مثل !%$#sdjfkwl$#MDAWawd%#*(& انتخاب کنند! تازه با تمام این اوصاف، درصورت هک شدن یا لو رفتن دیتابیس، تمام رمزها بصورت خام در اختیار هکر خواهد بود درحالی که اگه رمزگذاری شده باشه، پیداکردن رمز خام ازطریق دیتابیس هم عملاً ممکن نخواهد بود.

البته بگم فقط یکی از دلایلش میتونه این باشه یکی دیگه از دلایلشم جلوگیری از sql injection شاید باشه
نگید نگفتم بریزید سرم :دی
این مسئله به SQL Injection ربطی نداره. جلوگیری از SQL Injection با روشهایی مثل mysql_real_escape_string و بررسی magic_quotes_gpc و... امکان پذیره و اصولاً اینقدر ساده است که ارتباطی به تعداد کاراکترهای رمز کاربر نداشته باشه. اینکه گوگل میگه حداقل اینقدر و حداکثر اینقدر (حداکثر ندیدم براش)، بخاطر امنیت بیشتره تا با حدس زدن و روشهایی مثل BruteForce نشه راحت رمز رو پیدا کرد.
موفق باشید.

[mehdi.mousavi]

سلام.
فقط خواستم این موضوع رو متذکر بشم که الگوریتم MD5 منقضی شده و نباید از اون استفاده کرد.
متاسفانه هنوز که هنوزه، افراد از این الگوریتم برای Hash کردن اطلاعات استفاده می کنن. MD4/MD5، SHA1 و ...
سالهاست که منقضی شده و نباید از اونها استفاده کرد. البته استفاده یا عدم استفاده از این الگوریتم ها، به نوع کاربرد
و میزان ریسک پذیری کاری که انجام می دید ارتباط داره، اما بعنوان قانونی کلی، امروزه نباید از الگوریتم های یاد شده
استفاده کرد.

من قبلا در این تاپیک (http://barnamenevis.org/showthread.php?311403-%D8%A7%D9%84%DA%AF%D9%88%D8%B1%DB%8C%D8%AA%D9%85-%D9%87%D8%A7%DB%8C-%D8%BA%DB%8C%D8%B1-%D9%82%D8%A7%D8%A8%D9%84-%D8%A8%D8%A7%D8%B2%DA%AF%D8%B4%D8%AA) مفصلا در مورد این موضوع صحبت کرده ام.

موفق باشید.

[omidabedi]

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


"ندانستن عیب است نه سوال کردن"

[omidabedi]

این مسئله به SQL Injection ربطی نداره. جلوگیری از SQL Injection با روشهایی مثل mysql_real_escape_string و بررسی magic_quotes_gpc و... امکان پذیره و اصولاً اینقدر ساده است که ارتباطی به تعداد کاراکترهای رمز کاربر

اون توابع که مثلا اسلش رو حذف میکنه یا به چیز دیگه تبدیل میکنه درست اما از این نظر گفتم که کمتر کسی میاد رمز بالای 10 کارکتر رو انتخاب کنه اما یک کوئری معمولی بیشتر میشه.

[MMSHFE]

یک چیز دیگه
اینجور که اقای MMSHFE (اسمتون رو نمیدونم ببخشید) گفتید لازم نیست حداکثر طول یک فیلد دریافت رمز عبور رو مشخص کنیم و با توجه به اینکه پسورد قبل از اینکه به دیتابیس برسه باید هش بشه
اگر فردی اومد مثلا 2000 کاراکتر گذاشت تو فیلد اونموقع به مشکل بر نمیخوریم؟
"ندانستن عیب است نه سوال کردن"
هیچ فرقی نمیکنه. شما چه 1 کارکتر بدین، چه 2000 کارکتر، هش تولید شده 32 کارکتری خواهد بود.

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

[omidabedi]

نه. کار به تعداد کاراکتر هش شده ندارم منظورم از لحاظ حملات این چنینی هست.

[eshpilen]

نه. کار به تعداد کاراکتر هش شده ندارم منظورم از لحاظ حملات این چنینی هست.
حداکثر طول پسورد رو 100 یا 200 کاراکتر بذار.
در این حد هیچ مشکلی نداره.
من با خیلی بیشتر از این هم بنچمارک کردم و مشکلی نداشت (از نظر زمان هش شدن).


از طرفی بیایم یه فرض کنیم که اقا به سایت ما حمله شده چگونه (نمیدونم اسمشو چی بزارم ولی مثل DDOS یکی از زیر شاخه هاشه) اینجوری که بیان درخواست هش 500 کد رو همزمان توسط هکرها (از طریق خود فرمی که ثبت نام میکنه مثلا) به سرور ارسال کنن.ایا سرور دووم میاره ؟؟؟ (میدونم میگید برای این مشکل هم راه هست) اما چرا با یک کار اشتباه بیایم اینجوری کل سایت رو به فنا بدیم.
استفاده از متدهایی مثل key stretching ممکنه سایت رو در برابر حمله های DOS آسیب پذیرتر کنه.
ولی این مسئله محدود به key stretching نمیشه و بطور کلی هرچی سایت مکانیزم های امنیتی بیشتر و حتی امکانات و منطق و الگوریتم کاملتر داشته باشه کم و بیش پیش میاد.
امنیت کامل که بدون هزینه نمیشه.
کلا حمله های DOS مبحث دشواری برای جلوگیری هستن؛ چون شما باید چیزهای دیگر منجمله امنیت در زمینه های دیگر رو فدا کنید تا به خیال خودتون مقاومت در برابر DOS رو بالا ببرید که تازه اونم تضمینی نداره؛ هکر هم میتونه با افزایش منابع خودش، این مقدار مقاومت رو خنثی کنه.
حالا باید تصمیم بگیرید که یا حداکثر مقاومت در برابر DOS/DDOS و یا جنبه های دیگر امنیت و کمال منطق و الگوریتم و امکانات.
بنظر من که عاقلانه اینه که اصلا بیخیال DOS/DDOS بشیم و دست خودمون رو در برنامه نویسی نبندیم. چون بهرصورت باید از چیزهای دیگه بابتش بزنیم که بنظر من اهمیت اون چیزهای دیگه کمتر نیست. ضمنا DOS/DDOS رو من خطرناک ترین حمله ها نمیدونم، چون در این حمله ها نفوذی صورت نمیگیره و فقط دسترسی به سایت قطع/مختل میشه، و همزمان هکر هم داره منابع احتمالا محدود و ارزشمند خودش رو به این کار اختصاص میده.
درکل هم فکر میکنم آمار حمله های DOS/DDOS خیلی کمتر از این همه حمله های دیگر باشه. در DOS/DDOS هکر چیز زیادی بدست نمیاره، و مدام هم داره منابع خودش رو استفاده میکنه.
حالا شما بخوای بیای بخاطر یخورده مقاومت بیشتر در برابر DOS/DDOS از خیلی چیزهای دیگه بزنی، و بعد نهایت سالی چند بار مدت محدودی بهت حمله DOS/DDOS بشه، بنظرم زیاد عاقلانه نیست.
فکر میکنم حمله های DOS/DDOS بیشتر درمورد سایتهای خاصی با اهداف خاصی انجام میشن که ارزشش رو داشته باشن.
ضمنا تاجاییکه میدونم، برای این حملات راه حلهای خارجی (خارج از برنامهء ما و PHP) وجود دارن که فکر میکنم راه حلهای موثر و اصولی اونا باشن. یعنی فکر نمیکنم حل این حملات در سطح اپلیکیشن چندان اصولی و موثر و بهینه باشه.