سوال: استفاده از md5 [بایگانی]

MMSHFE

پنج شنبه 29 دی 1390, 13:52 عصر

eshpilen

پنج شنبه 29 دی 1390, 15:00 عصر

آقای MMSHFE (http://barnamenevis.org/member.php?55504-MMSHFE) روشی که شما پیشنهاد میدید اگر از نظر اصولی و علم رمزنگاری بخوایم درنظر بگیریم دچار ضعف هست.
چون استفاده از یک Salt مناسب برای تامین امنیت لازمه.
خصوصیات Salt مناسب هم اینه که باید رندوم و به ازای هر پسورد متفاوت باشه. البته تعداد حالتهای ممکن اون هم طبیعتا نباید خیلی کم باشه (یعنی مثلا بیش از حد کوتاه نباشه).
البته شما از رشتهء دلخواهی مثل www.mysite.com استفاده کردید، اما چون این رشته برای تمام پسوردها ثابت هست نمیتونه جای یک سالت مناسب رو بگیره. این رشته فقط نقش چیزی رو داره که اصطلاحا بهش server secret گفته میشه (البته فکر میکنم یک اصطلاح غیررسمی باشه) و بعضی ها برای امنیت بیشتر اضافه میکنن (که البته اگر هکر بهش دسترسی پیدا کنه فایده ای نداره).
بنابراین برای اصولی بودن روش شما، باید یک سالت رندوم هم به فرایند اضافه بشه.
باید به ازای هر اکانت/پسورد، یک سالت رندوم وجود داشته باشه.

MMSHFE

پنج شنبه 29 دی 1390, 17:28 عصر

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

eshpilen

پنج شنبه 29 دی 1390, 18:34 عصر

درسته ولی اولاً سالت رندوم مشکلات خاص خودش رو داره
چه مشکلاتی؟!

و کلاً اگه اون رو نادیده بگیریم (مثلاً از رشته نهایی با علم به اینکه کجا قرار گرفته، حذف کنیم و بعد اعتبارسنجی کنیم) روش خیلی خوبی هست وگرنه قابل استفاده نیست.
Salt رو نادیده بگیریم؟ یعنی سالت نداشته باشیم؟
بدون سالت روش خوبی میشه؟!

Reza1607

پنج شنبه 29 دی 1390, 18:54 عصر

سلام از اين روش استفاده مي كنم
اول ميام رشته رو md5 مي كنم بعد رشته هش شده رو مثلا از كاراكتر 10 تا 15 رو دوباره هش مي كنم
به نظرتون اين روش امنيت داره يا نه؟

MMSHFE

پنج شنبه 29 دی 1390, 18:58 عصر

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

H:Shojaei

پنج شنبه 29 دی 1390, 19:19 عصر

من یه ایده به ذهنم رسیده شاید هم به درد نخوره ولی شما هم یه نظر بدید که چطوری هستش
اول رشته رو رمز گذاری کنیم
بعد اون رو تفکیک کنیم و یکی در میان یه رشته یا کاراکتر به اون اضافه کنیم به طوری که هر چه به کاراکترهای جلوتر میرویم یکی به تعداد کاراکتری که اضافه میکنیم اضافه بشه
مثلا:
رشته ی abcd بشه aqbweceyrd

farnaz.saeedi

پنج شنبه 29 دی 1390, 19:20 عصر

سلام
اگه بخوام موقع ثبت نام کاربر از یه رشته رندوم بجای www.mysite.com استفاده کنیم.بعد موقع ورود کاربر از کجا بفهمیم اون رشته رندوم چی بوده که حذفش کنیم؟
باید مقدار رندوم و تو جدول کاربر ثبت کنیم؟

H:Shojaei

پنج شنبه 29 دی 1390, 19:36 عصر

یه چیز دیگه هم میشه
بنویسیم:
$a=rand();
md5('رشته'+$a);
کاملا با
md5('رشته')
فرق میکنه میشه حالا عدد رندم رو داخل db ذخیره کرد

eshpilen

جمعه 30 دی 1390, 03:46 صبح

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

eshpilen

جمعه 30 دی 1390, 04:15 صبح

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

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

ثانیاً راه حلی که گفتم برای شروع بد نیستواسه شروع بنظر بنده به دلایلی که گفتم خیلی هم بده.

من هم قصدم فقط آشناکردن ایشون با این روش بودکدوم روش؟
این روش هیچ ارتباطی با روش اصولی نداره جز یه شباهت ظاهری.
شما ایشون رو با «شبه برنامه نویسی» که متشکل از عنصر پایه ای به نام «سمبل کردن» هست آشنا کردید.

MMSHFE

جمعه 30 دی 1390, 14:44 عصر

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

eshpilen

جمعه 30 دی 1390, 19:16 عصر

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

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

MMSHFE

جمعه 30 دی 1390, 20:04 عصر

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

eshpilen

جمعه 30 دی 1390, 20:54 عصر

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

امنیت روش شما بر پنهان کاری بنا شده و اگر کسی بر پنهان بودن الگوریتم اتکا کنه، این میشه Security through obscurity (http://en.wikipedia.org/wiki/Security_through_obscurity) و وقتی شما از Security through obscurity بعنوان حفاظت اصلی استفاده میکنی، درحالیکه راه حل اصولی وجود داره، این قطعا غلط هست و تمام متخصصان امنیت هم باهاش موافقند.
البته Security through obscurity محل مناقشه هست و بعضی ها اعتقاد دارن در بعضی جاهای خاص مناسبه، و میشه گفت در این مورد هم اگر بعنوان مکمل و نه روش اصلی، بعنوان یک لایهء بیشتر دفاعی اضافه بشه، مشکلی نداره و میتونه امنیت رو مقداری بالاتر ببره. اما کاری که شما کردید اینه که اون رو بصورت روش اصلی بکار بردید.

و بازهم مشکل و اشتباه دیگر اینکه شما حتی این Security through obscurity رو هم صحیح و هوشمندانه پیاده نکردی که آدم دلش خوش باشه. بلکه به شکل بسیار ناشیانه و ناکارا پیاده سازی شده؛ اشتباه بزرگی توش وجود داره.
چرا؟ چون کشف الگوریتم شما حتی بدون داشتن کد منبع هم چندان دشوار نیست و اینقدر ضعیفه که حتی ممکنه بصورت تصادفی هم کشف بشه.
بطور مثال اگر من اگر یه ذره سواد و پشتکار و هوش داشته باشم بعنوان هکری که به دیتابیس شما دسترسی پیدا کرده میام و یک اکانت تست در سایت شما ثبت میکنم و بعد به هش پسوردی که انتخاب کردم در دیتابیس شما نگاه میکنم، روی سیستم خودم هم هش اون پسورد رو با توابع هش مختلف تولید و با اون چیزی که در دیتابیس شما ثبت شده مقایسه میکنم، طبیعتا کشف این حقیقت که عین همون هش در دیتابیس ثبت شده و فقط بینش یه رشتهء دیگه اضافه شده اصلا سخت نیست. بعد که متوجه این قضیه شدم میتونم براحتی هش اصلی پسورد بقیهء کاربران رو دربیارم و روش حمله های متداولی که هست رو انجام بدم.
شما باید بعد از اینکه رشته ها رو به هم وصل کردید یک هش کلی میگرفتید و اون هش رو در دیتابیس ذخیره میکردید. این یک عملیات ضروری بود. با این کار حداقل Security through obscurity رو بصورت کامل روی سیستم هش خودتون داشتید و کسی بدون دسترسی و خواندن سورس برنامه و کشف اون رشتهء ثابت که بعنوان server secret انتخاب کردید نمیتونست هیچ حملهء موثری رو روی هش پسورد کاربران انجام بده. تازه حتی اگر اون رشته هم کشف بشه بازم تاحدی امنیت بیشتری از روش ناقص شما داره، چون حتی در این صورت هم هکر هش اصلی کاربران رو در اختیار نداره. وقتی هش اصلی در دسترس باشه، کوچکترین مانعی برای انجام حمله و رسیدن به پسوردهای اولیه وجود نداره و این کار حتی با سایت ها و سرویسهای آنلاینی که وجود دارن میتونه براحتی انجام بشه.

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

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

yones_safari

جمعه 30 دی 1390, 21:26 عصر

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

رضا قربانی

جمعه 30 دی 1390, 21:48 عصر

سلام
اگه بخوام موقع ثبت نام کاربر از یه رشته رندوم بجای www.mysite.com (http://www.mysite.com) استفاده کنیم.بعد موقع ورود کاربر از کجا بفهمیم اون رشته رندوم چی بوده که حذفش کنیم؟
باید مقدار رندوم و تو جدول کاربر ثبت کنیم؟

اکثرا برای پسورد از هش کردن استفاده می کنند.
بر اساس نام کاربری یا آی دی (کلید ) که براش به صورت اتوماتیک تعریف می کنیم میاییم و ویرایش یا حذف می کنیم .

eshpilen

جمعه 30 دی 1390, 21:48 عصر

ولی جناب eshpilen (http://barnamenevis.org/member.php?148005-eshpilen) ای کاش به جای اینقدر جروبحث های بدون نتیجه روش اصولی اعمال سالت رو میزاشتین تا یاد میگرفتیم!!!!!
قبلا در اینباره چیزهایی گفته بودیم در بحث و تاپیک دیگری. حالا نمیدونم چطور میشه به سادگی اون بحث رو پیدا کرد. توش مثال از روش چند نرم افزار معروف آورده بودم (که البته یکی از دوستان مطلع بهم داده بود).
اتفاقا میخواستم دنبالهء این بحث هم یک تاپیک و مطلب مختص این موضوع ارائه کنم، الان هم 12 تا پیج در فایرفاکس باز هست همش دربارهء salt که همه رو میخواستم نگاه کنم یا بخونم. تازه چنتا رو خوندم و بستم. مطالعهء هرکدام از این مطالب ممکنه نیم ساعت و بیشتر و کمتر زمان ببره.
با وجودیکه قبلا هم ده ها صفحه مطالب راجع به این مسائل خونده بودم ولی چون میخوام کار اصولی و دقیق و کامل و مطمئن باشه و برای آموزش و مرجع قرار بگیره، میبینم باید این مطالعات رو انجام بدم. آدم همهء جزییات و موارد رو دقیق یادش نمیمونه.
هرچند با پستهای اخیر جناب MMSHFE منم بدم نمیامد و تقریبا صرفنظر کردم از این کار. چون بهرحال برای من چیز زیادی نداره جز زحمت و هزینه. ولی اگر میخواید باشه سعی میکنم سرفرصت مطالبی بدم.

ضمنا قبلا یه تاپیک هم درمورد یک الگوریتم هش که مخصوص هش کردن و ذخیرهء پسورد کاربران بود ایجاد کرده بودم: http://barnamenevis.org/showthread.php?310375
این تابع خوبی هست و خودش بصورت خودکار سالت رو هم تولید میکنه که سالت درواقع در همون رشتهء خروجی که میده اضافه شده و نیازی نیست در یک ستون مجزا ذخیره بشه.
ضمنا اگر بخوایم میتونیم یک server secret رو هم به ورودیش اضافه کنیم.

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

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

رضا قربانی

جمعه 30 دی 1390, 22:31 عصر

رضا قربانی

جمعه 30 دی 1390, 23:36 عصر

اینم یک سالت (که نمی شه گفت سالت :لبخند:) از چند دقیقه تایم استراحتم :

$pass = 'Mr.ghorbani';
$hash = substr(md5(strtoupper($pass)), 0, 3).dechex(mt_rand(999,microtime(true))).substr(md5 (strtolower($pass)), 3);
echo wordwrap(strtoupper($hash), 4, '-',true);

پ.ن = در مورد توابع توضیح خواستید بگید تا توضیح بدم

MMSHFE

شنبه 01 بهمن 1390, 00:50 صبح

رضا قربانی

شنبه 01 بهمن 1390, 01:17 صبح

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

MMSHFE

شنبه 01 بهمن 1390, 07:09 صبح

تابع getenv برای استخراج متغیرهای محیطی سیستم عامل هست. متغیرهای محیطی توی حافظه RAM تعریف میشن. هم میشه اونها رو با htaccess. و دستور SetEnv تعریف کنیم و هم توی اسکریپتهای PHP با استفاده از putenv اونها رو ایجاد کنیم. مزیتش اینه که مقادیری که بصورت محیطی تعریف میشن، SuperGlobal هستن و توی همه توابع و... میشه با getenv بهشون دسترسی پیدا کنیم. درواقع مفهومی شبیه متغیرهای محیطی توی خود ویندوز هست (مثل Path و %systemroot% و...) که همه جا میشه بهشون دسترسی داشته باشیم.
موفق باشید.

eshpilen

شنبه 01 بهمن 1390, 09:16 صبح

من خودم در اصل از اين روش استفاده ميكنم:
ابتدا نام كاربري و رمز عبور كاربر رو md5 ميكنم و بعد كنار هم ميگذارم و دوباره md5 ميكنم. تا اينجا تقريباً نيمي از اطلاعاتي كه هكر براي بازكردن رمز لازم داره توي ديتابيس هست (نام كاربري كه بصورت خام ذخيره ميشه). حالا يك رمز مخفي براي سايت ميگذارم كه توي htaccess. اينطوري تعريف ميشه:

SetEnv WEBSITE_SALT 1231asaDWQk3!@#asd25

بعد توي تابع توليد هش اصلي، اون رشته قبلي رو با اين رشته تركيب ميكنم و دوباره md5 ميكنم. كد مربوطه تقريباً اينطوري ميشه:

function myhash($user, $pass) {
$salt = getenv('WEBSITE_SALT');
return md5(md5(md5(strtolower($user)).md5($pass)).$salt);
}

مزيت اين روش در اينه كه Apache فايلهاي htaccess. رو خودش مخفي نگه ميداره و درنتيجه دسترسي به WEBSITE_SALT تقريباً غيرممكنه. مگه اينكه سورس كدها دست هكر بيفته.
ضمناً در اين روش از اونجا كه نهايتاً همه رشته خروجي دوباره md5 شده، همون رشته 32 كاركتر توليد ميشه كه مشابه يك md5 معمولي بنظر مياد. حالا موقع واردكردن نام كاربري و رمز عبور، اگه اين تابع هش يكساني با اونچه كه توي ديتابيس هست توليد كنه، يعني اطلاعات درسته و از اونجا كه نام كاربري با حروف كوچك پردازش ميشه، حساسيت به حروف كوچك و بزرگ در نام كاربري موقع لاگين هم از بين ميره.
نظرتون درمورد اين روش چيه؟ اميدوارم به اين روش ديگه نگين غير اصولي!
موفق باشيد.
از نظر اصولیش اگر بخوایم بگیم، بیشتر روشها که بیشتر افراد استفاده میکنن غیراصولی هستن (البته ما با بحث ساده کردن و ارائه به مبتدی ها کاری نداریم و بهتره کاری نداشته باشیم، چون اصولا نمیتونید یک روش صحیح و تفکر مناسبی رو به یک شکل اینقدر ساده و کوتاه به یک مبتدی ارائه کنید - خیلی چیزها حداقلی دارن که در حد مبتدی ها نمیشه پایین آوردش).
این هم دلایل روشنی داره که در منابع متعددی خوندم و همچنان هم دارم میخونم. چیز غیرواضح و غیرمستندی نیست.
کلا شاید 95% کل برنامه نویسان PHP در بحث امنیت دچار نقص و ضعفهای جدی هستن. چون امنیت یک مبحث گسترده و پیچیده ای هست که خیلی راحت میشه متوجه نشد و ساده گرفتش. رمزنگاری هم که بنظرم باید بگیم یک زیرمجموعه از مبحث امنیت هست دیگه اوج این مسئله است و خودش یک علم و تخصصه که بیشتر افراد حتی در حد مقدماتی هم چیزی ازش نمیدونن. یعنی حتی اگر برنامه نویس بسیار حرفه ای باشید، لزوما در بحث رمزنگاری دانش و مهارت خاصی ندارید. باید منابع خودش رو بخونید و درک کنید تا از سطح مبتدی بالاتر برید. منابعی حجیم و پیچیده.
اون چیزهایی که برنامه نویسان خودشون، بدون دانش تخصصی در علم رمزنگاری، اختراع میکنن به هیچ وجه قابل اتکا نیستن و 99% اشکالات جدی دارن. البته اگر کار اونقدر اهمیت نداشته باشه که این بحثها مهم نیست و میشه سمبل کرد!

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

اینکه 4 تا md5 گرفتید باز یه امتیازه ولی نه خیلی زیاد. نمیدونم هدفتون از چندبار هش کردن چی بوده، ولی اگر هدف Key stretching (http://en.wikipedia.org/wiki/Key_stretching) بوده (که از نظر امنیتی باید داشته باشیم) باید بگم این تعداد به هیچ وجه کافی نیست. الگوریتم های حرفه ای عملیات خودشون رو حداقل 1000 یا 2000 بار تکرار میکنن (تازه عملیاتی که تکرار میکنن، هم پیچیده تر و حساب شده تره و هم طبیعتا هر دورش زمان بیشتری مصرف میکنه). بنابراین 4 تا خاصیت چندانی نداره، چون میزان پردازش و زمانی که اضافه میکنه ناچیزه و بازم میشه تعداد بسیار زیادی هش رو در بازهء زمانی کوچکی تولید و تست کرد.

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

eshpilen

شنبه 01 بهمن 1390, 10:09 صبح

نظر عزیزان در مورد این تابع چیه :
سالت نیست ، چون می تونم رشته هش شده رو برگردونم

ولی نظرتون رو می خواستم بدونم

function encrypt($string)
{
$encrypted = base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5("b`$I|`S)8KoE~+.2182l9z2+5mpJQyGhorbani"), $string, MCRYPT_MODE_CBC, md5(md5("b`$I|`S)8KoE~+.2182l9z2+5mpJQyGhorbani"))));
return $encrypted;
}

echo encrypt("Reza");

البته به جای b`$I|`S)8KoE~+.2182l9z2+5mpJQyGhorbani می شه هر چیزی گذاشت (رندوم کردن یا هر چیز دیگه)

?

اگر خواستید بگید تا decript ش رو هم بگم .

پ.ن : حیف این تاپیکه که ازش استقبال کمی شده ==> http://barnamenevis.org/showthread.php?310375
برای ذخیره پسورد کاربران مناسب نیست. چون برگشت پذیره.
پس به بحث ما تقریبا ارتباطی نداره.
هرکسی هم اگر از این روش برای ذخیرهء پسورد کاربران استفاده میکنه اشتباه میکنه.

اما گذشته از بی ربط بودنش اگر بخوایم از دید صرف استفاده از الگوریتم های رمزنگاری بررسی کنیم دو مشکل منطقی و امنیتی در کد شما هست.
یکی اینکه رمزنگاری 256 بیتی رو مشخص کردید اما از کلید 128 بیتی استفاده کردید (خروجی md5 برابر 128 بیت است).
دیگر اینکه از مد CBC استفاده کردید که نیاز به یک IV متفاوت رندوم برای هر رمزگذاری داره، ولی شما از یک IV ثابت استفاده کردید.

MMSHFE

شنبه 01 بهمن 1390, 16:09 عصر

جناب eshpilen اگه میشه یک نمونه کد برای استفاده از سالت رندوم و نحوه چک کردن صحت رمز واردشده با استفاده از این روش، بگذارید.

eshpilen

شنبه 01 بهمن 1390, 18:29 عصر

باشه به زودی یک تاپیک در این ارتباط میزنم. چون داستان باید گسترده تر و مفصل تر از این حرفا باشه.
علاوه بر دیشب، بیشتر امروز هم داشتم در این ارتباط مطالعه میکردم.
-----------------
تاپیک مورد نظر استارت شد: http://barnamenevis.org/showthread.php?324247

امیـرحسین

شنبه 01 بهمن 1390, 20:17 عصر

برای سالت رندوم همون که سالت رو ذخیره کنیم چه اشکالی داره؟ یه چیزی تو این مایه‌ها:

$sql = "SELECT users.id FROM users WHERE users.username=".$pdo->quote($_POST['username'])."
AND users.password = MD5( CONCAT(".$pdo->quote($_POST['password']).",users.salt) );";

eshpilen

شنبه 01 بهمن 1390, 20:41 عصر

برای سالت رندوم همون که سالت رو ذخیره کنیم چه اشکالی داره؟
هیچ اشکالی نداره. باید ذخیره کنیم. حالا فرقی نمیکنه کجا و به چه شکلی باشه.
مهم اینه که به ازای هر پسورد یک سالت رندوم هم داشته باشیم.

MMSHFE

یک شنبه 02 بهمن 1390, 10:59 صبح

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

eshpilen

یک شنبه 02 بهمن 1390, 11:14 صبح

البته جای ذخیره کردن خیلی مهمه. اگه توی دیتابیس باشه، عملاً وجود سالت رندوم هیچ دردی رو دوا نمیکنهجان؟!!
یعنی میگید در این صورت سالت رندوم هیچ فایده ای نداره؟
خیر به هیچ وجه اینطور نیست.
تمام سیستمهای حرفه ای این کار رو میکنن. و اینهمه منابع که بنده تاحالا خوندم همچین حرفی نزدن.
سالت رندوم امکان استفاده از Precomputed dictionary و rainbow table های آماده رو از بین میبره.
سالت رندوم سرعت و ضریب موفقیت حمله های dictionary و Brute force عادی رو هم کاهش میده، چون نتیجهء محاسبهء هش هر پسورد با یک سالت مشخص که برای یک اکانت بکار رفته، نمیتونه برای اکانتهای دیگر هم تست بشه. کرکر نیاز داره برای هر کاربر مجددا با سالت اون کاربر هش پسورد مورد نظر رو دوباره محاسبه و مقایسه کنه.
فرض کنید سایتی صدهزار اکانت کاربری داشته باشه، این به معنی صدهزار برابر شدن پردازش مورد نیاز کرکر هست. بنظر شما کم چیزیه؟ حتی هزاربرابرش هم چیز کمی نیست.
و وقتی از key stretching هم استفاده شده این قضیه هزینهء خیلی بیشتری هم خواهد داشت.
key stretching هم میاد و با افزایش پردازش و زمان هر محاسبهء هش به چند هزار برابر، دهن کرکر رو سرویس میکنه. هزار ضربدر هزار میشه یک میلیون برابر پردازش و زمان مورد نیاز!
سالت ثابت حداقل این خاصیت اخیر سالت رندوم به ازای هر اکانت رو نداره و این فرض هم که هکر هیچوقت نمیتونه سالت ثابت رو داشته باشه کاملا بی پایه هست.

وقتی هکر به دیتابیس دسترسی پیدا کرد، سالت رو هم داره و میتونه رشته رو حتی راحتتر از حالتی که سالت ثابت داریم ولی در اختیار هکر نیستبعدا در تاپیک مربوطه (http://barnamenevis.org/showthread.php?324247-%D8%B0%D8%AE%DB%8C%D8%B1%D9%87%D8%A1-%D8%A7%D9%85%D9%86-%D9%BE%D8%B3%D9%88%D8%B1%D8%AF-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%A7%D9%86) دربارهء سالت ثابت (همون sever secret یا pepper) هم صحبت خواهیم کرد.
بله سالت ثابت میتونه امنیت رو بالاتر ببره چون همیشه هکر به هردوی دیتابیس و سورس کد (یا هرجای دیگری) دسترسی پیدا نمیکنه و ما این سالت رو هم به سیستم اضافه خواهیم کرد، اما سالت ثابت به هیچ وجه جایگزینی برای «سالت رندوم به ازای هر اکانت» نیست.
جای سالت رندوم به ازای هر کاربر در همون دیتابیس هست و انتقالش به جای دیگه دردی رو دوا نمیکنه، چون اگر جای دیگه خیلی امن باشه همون سالت ثابت رو اونجا ذخیره کنید کفایت میکنه. اگر اون مکان در دسترس هکر قرار بگیره دیگه فرقی نمیکنه فقط سالت ثابت رو اونجا ذخیره کرده باشید یا هردوی سالت ثابت و رندوم رو. تازه سالتهای رندوم بخاطر تعداد و حجم زیادشون جای مناسب براشون همون دیتابیس هست.

MMSHFE

یک شنبه 02 بهمن 1390, 11:41 صبح

عزیز من طبق صحبتهایی که با گروه آشیانه و اعضای فعال انجمنشون داشتم، دارم این حرف رو میگم: ذخیره سالت در دیتابیسی که خود پسورد رو ذخیره کردین، امنیت رو پایین میاره چون وقتی هکر به دیتابیس دسترسی پیدا کرد، سالت رو هم داره. بنابراین، میتونه راحتتر روی رمزگشایی کار کنه. اینهمه روی روشهای Dictionary و Bruteforce و... فکر نکنید. یکم هم روشهای RE (مهندسی معکوس) رو درنظر بگیرید. تمام اهمیت سالت در اینه که کسی نفهمه رشته های اصلی با چی ترکیب شدن و کد هش نهایی رو تولید کردن وگرنه با همون روشهای ساده مثل Dictionary یا Bruteforce هم میشه عملیات مختلفی رو برای ترکیب رشته های موجود در دیتابیس دیکشنری یا رشته های تولیدشده در بروتفورس رو با سالت امتحان کرد و نهایتاً رشته رو رمزگشایی کرد و اینطوری، کلاً الگوریتم تولید هش نهایی لو میره و به راحتی میشه همه پسوردها رو کشف کرد. دقت کنید که هکرهای حرفه ای سیستمهایی در اختیار دارن که میتونه چندین میلیون یا حتی چند میلیارد رمز رو در فواصل زمانی خیلی کوتاه در حد 1 یا چند ثانیه، بررسی کنه. اگه قراره اینقدر حرفه ای عمل کنیم و سالت رو به شکل اصولی بکار ببریم، ساده ترین اصل استفاده از سالت یعنی مخفی بودنش رو هم باید رعایت کنیم. ضمناً اگر میخواین بحثها درست پیش بره، ایندر معلومات اندکتون رو به رخ نکشین و باور کنید بقیه هم بدون مطالعه وارد بحث نمیشن. موفق باشید.

eshpilen

یک شنبه 02 بهمن 1390, 11:54 صبح

عزیز من طبق صحبتهایی که با گروه آشیانه و اعضای فعال انجمنشون داشتم، دارم این حرف رو میگم

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

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

تمام اهمیت سالت در اینه که کسی نفهمه رشته های اصلی با چی ترکیب شدن و کد هش نهایی رو تولید کردن وگرنه با همون روشهای ساده مثل Dictionary یا Bruteforce هم میشه عملیات مختلفی رو برای ترکیب رشته های موجود در دیتابیس دیکشنری یا رشته های تولیدشده در بروتفورس رو با سالت امتحان کرد و نهایتاً رشته رو رمزگشایی کرد
عزیزم اینقدر برات توضیح دادم چرا دقت نمیکنی؟
کی میگه تمام اهمیتش در اینه؟
اصلا همچین چیزی نیست.
سالت رندوم به ازای هر اکانت باعث میشه همین عملیات دیکشنری و Bruteforce که میگی نیاز داشته باشن برای هر پسورد که تست میکنن یک عملیات هش به ازای هر اکانت انجام بدن، اما وقتی سالت به ازای هر اکانت نباشه، هش اون پسورد خاص رو یک بار محاسبه میکنن و بعد میتونن نتیجه رو روی هش N اکانت تست کنن.
در بالا هم با محاسبات ساده و کاملا واقعی نشون دادم که این مسئله میتونه چقدر هزینهء سنگینی داشته باشه. این باعث میشه هکرها بتونن تعداد خیلی کمتری از حداکثر تعداد پسورد/اکانت رو که قبلا تست میکردن تست کنن. چون پردازش و زمان به شدت افزایش پیدا میکنه (بخصوص وقتی از key stretching هم استفاده شده باشه).

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

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

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

eshpilen

یک شنبه 02 بهمن 1390, 16:15 عصر

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

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

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

میتونید تاپیک اخیر بنده رو هم بخونید: لینک (http://forum.iranphp.org/Thread-%DA%86%D8%B1%D8%A7-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%D9%87%D8%A7-%D8%A7%DB%8C%D9%86%D9%82%D8%AF%D8%B1-%DA%A9%D9%85-%D8%B3%D9%88%D8%A7%D8%AF-%D9%88-%D8%B4%D9%88%D8%AA%D9%86%D8%9F)
البته ببخشید که توهین آمیز و خودپرستانه است بنظر شما.
من بلد نیستم نظراتی رو که دارم و حقایقی رو که میبینم به صورت غیرمستقیم و مودبانه تری بگم. شاید اشکالم این باشه.

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

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

لابد چون هکر کارهای جالب میکنه، چون علاوه بر سایتهای زپرتی شرکتها و سایتهای بزرگ رو هک میکنه، چون اخبار راجع بهش میگه، چون از کارهاش سردرنمیاری، چون آموزشش منبع نداره و زیرزمینی هست، توی چشم میاد، توجه عمومی رو جلب میکنه، اهمیت و نتیجهء کارهاش رو عموم مشاهده میکنن، و غیره و غیره.

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

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

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

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

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

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

رضا قربانی

دوشنبه 03 بهمن 1390, 10:00 صبح

تو کلا دست خودت نیست . دلت همیشه خیلی پره

H:Shojaei

دوشنبه 03 بهمن 1390, 14:21 عصر

سلام
من کاری به بحث های شما ندارم اما حرفهای eshpilen به نظر نتیجه ی مطالعه و دقت ایشون روی این مساله هست (البته اگه کدشون نهاییشون رو هم زودتر بذازن ممنون میشیم):قلب:
mer30

eshpilen

دوشنبه 03 بهمن 1390, 14:56 عصر

eshpilen

دوشنبه 03 بهمن 1390, 15:17 عصر

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

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

MMSHFE

دوشنبه 03 بهمن 1390, 15:26 عصر

هکر هم میاد و کد شما رو اینطوری دستکاری میکنه و سالت رو میخونه:

function myhash($user, $pass) {
$salt = getenv('WEBSITE_SALT');
echo $salt;
return md5(md5(md5(strtolower($user)).md5($pass)).$salt);
}
کار سخت و پیچیده ای بود؟
به شرطی که به کد دسترسی داشته باشه. اگه اینقدر دسترسی داشته باشه که کد رو بخونه، کلاً قید اون سرور و هاست رو میزنم. مسئله به این راحتی که میگین نیست. هکر از کجا باید بتونه کدم رو دستکاری کنه؟ اصلاً اگه هکر اینقدر راحت میتونه توی کدها Inject کنه، خوب چرا همونجا که کاربر وارد میشه و براش Session تعریف میشه، رمز تأیید شده رو echo نکنه؟ مگه مریضه بیاد سالت رو بخونه؟ خوب یک مرتبه میگه هرموقع کاربر وارد شد، یک نسخه از رمز رو براش ایمیل کنه. اگه بتونه کد رو تغییر بده، این کار که منطقی تره! توضیحاتتون در سایر بخشها خوب و مناسب هست اما در این مورد واقعاً مسخره بود (ببخشید قصد توهین ندارم، کلمه مناسب دیگری پیدا نکردم).
موفق باشید.

eshpilen

دوشنبه 03 بهمن 1390, 18:07 عصر

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

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

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

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

بعدم کلا با اینطور فرضها نباید برنامه نویسی کرد. فرض کن یه برنامهء بازمتن هست. فرض کن فردا کسان دیگری هم ازش استفاده کردن و سورس دست عدهء دیگری هم بود و به دست آدمهای مختلف رسید.

اینکه بگیم هکر از کجا بدونه و نمیدونم کی حوصله داره و از این حرفا، در دنیای امنیت جایگاهی نداره. نباید روی اینطور چیزهای کوچک و سطحی اتکا کرد. فایل exe رو کرک میکنن، الگوریتمش و پسورد و قفلش رو درمیارن، اونوقت سورس به این خوشگلی و زبان متداول و سطح بالا در امان میمونه؟
این فرضها نهایت میشه یک شکل از security through obscurity. تازه یک مورد خیلی ضعیفش. اینا چیزایی نیستن که جلوی یک هکر حرفه ای و مصمم رو بگیرن. دسترسی داشته باشه پیدا هم میکنه و دستکاری هم میکنه؛ یحتمل خیلی هم راحتتر و سریعتر از چیزی که فکر میکنیم.

گذشته از اینها بنده متوجه نشدم منظور شما از اینکه آپاچی از این فایلها حفاظت میکنه چیه. تاجاییکه من میدونم و تست هم کردم، این فایلها فقط از دسترسی مستقیم از طریق وب محافظت میشن. یعنی اگر کاربر در آدرسبار مرورگر وارد کنه http://example.com/.htaccess آپاچی محتویات این فایل رو به کاربر نشون نمیده. که اینم چیز گنده ای نیست. آپاچی سورس فایلهای PHP شما رو هم که به کاربر نشون نمیده. میده؟
این فایلهای htaccess از نظر دیگه ای حفاظتی ندارن. یعنی عملا امنیت این فایلها با سورس کد خود شما روی سرور تفاوت زیادی نداره. اگر هکر بتونه سورس شما رو بخونه، میتونه htaccess رو هم بخونه.

مثلا من با این کد:

<?php
echo file_get_contents('.htaccess');
?>
محتویات htaccess رو خوندم. هم روی لوکال و هم روی یک هاست تست کردم.
بنابراین هکر لزوما نیازی نداره سورس شما رو پیدا و دستکاری کنه تا چیزی بفهمه.
میتونه از راههای دیگر هم محتویات htaccess رو بررسی کنه.

اصلاً اگه هکر اینقدر راحت میتونه توی کدها Inject کنه، خوب چرا همونجا که کاربر وارد میشه و براش Session تعریف میشه، رمز تأیید شده رو echo نکنه؟ مگه مریضه بیاد سالت رو بخونه؟ خوب یک مرتبه میگه هرموقع کاربر وارد شد، یک نسخه از رمز رو براش ایمیل کنه. اگه بتونه کد رو تغییر بده، این کار که منطقی تره! بله همچین چیزی شدنی هست و بنده هم بهش فکر کرده بودم.
ولی بهرحال این یه حملهء دیگری هست که محدودیتهای خودش رو هم داره و توجیهی برای این نمیشه که ما سیستم هش امن و اصولی ای رو پیاده سازی نکنیم.
چنین چیزی شدنی هست اما هکر باید منتظر بمونه تا چه وقت چه کسی لاگین بکنه یا نکنه. چقدر میخواد صبر کنه؟ خیلی کاربران ممکنه برای طولانی مدت autologin باشن و لاگین دستی نکنن، خیلی ها ممکنه دیر به دیر به سایت سر بزنن و بخوان لاگین هم بکنن، خیلی ها هم که بصورت موقت یا دائمی از سایت رفتن و به این زودیها به سایت نمیان. هکر باید منتظر بمونه تا یه مدت زمان نامعلومی که بعضی افراد لاگین کنن و فقط پسورد این افراد رو بدست میاره. بعدهم در این مدت این امکان حالا کم یا زیاد وجود داره که این نفوذ و دستکاری کدها فاش شده و جلوش گرفته بشه.

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

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

رضا قربانی

پنج شنبه 06 بهمن 1390, 00:46 صبح

محتویات htaccess رو خوندم. هم روی لوکال و هم روی یک هاست تست کردم.
بنابراین هکر لزوما نیازی نداره سورس شما رو پیدا و دستکاری کنه تا چیزی بفهمه.
میتونه از راههای دیگر هم محتویات htaccess رو بررسی کنه.

یعنی می گید ، اچ تی اکسز یک سایت دیگری رو با این دستور می تونید بخونید :

echo file_get_contents('.htaccess');
این فقط داخل هاست و توسط مدیریت پنل قابل دسترسیه . اگر هکر کل هاست بیاد دستش که ...

آقای MMSHFE (http://barnamenevis.org/member.php?55504-MMSHFE) آیا امکانش هست توسط php در فایل اچ تی اکسز قطعه کدی اضافه کنیم ؟ من تا حالا امتحان نکردم

اگر بشه ما می تونیم به صورت رندوم کد تولید کنیم ،

eshpilen

پنج شنبه 06 بهمن 1390, 00:57 صبح

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

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

ظاهرا چون آقای MMSHFE (http://barnamenevis.org/member.php?55504-MMSHFE) توجه نکردن که ما با چه فرضهایی صحبت میکنیم گفتن که سالت ثابت رو در htaccess ذخیره کنیم و جاش اونجا خیلی امنه. و من توضیح دادم که با این فرض که سایت هک شده، htaccess یا سورس کد یا بالاتر از www هیچکدام خیلی امن تر از بقیه نیستن.

رضا قربانی

پنج شنبه 06 بهمن 1390, 01:09 صبح

با این چیزایی که شما می گید و هکر هم چشم برزخی داره و سایت هم کف دستش هست نتیجه می گیریم که یه چیزی تولید کنیم که نه خودمون بدونیم چیه و نه هکر بدونه چیه : یه چیزایی تو مایه های پست شماره 21 همین صفحه 3
بهترین روش همیشه ساده ترین روش

eshpilen

پنج شنبه 06 بهمن 1390, 01:27 صبح

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

رضا قربانی

پنج شنبه 06 بهمن 1390, 01:36 صبح

آقا جان اینا پیش و پا افتادن ما کم هوشیم . عقل نداریم و .... زبونمون مو در اومد شما کد بده که یک هکر وقتی وارد هاست و سیستممون شد نتونه هش یک پسورد رو بدست بیاره ؟

؟
؟
؟
؟
؟
؟

eshpilen

پنج شنبه 06 بهمن 1390, 09:34 صبح

هش پسورد رو بدست بیاره؟
هش رو که بدست میاره.
هدف اینه که رسیدن از هش به پسورد اصلی تا حدممکن سخت بشه و ضریب موفقیت در این کار به شدت پایین بیاد.

MMSHFE

جمعه 07 بهمن 1390, 11:17 صبح

یعنی می گید ، اچ تی اکسز یک سایت دیگری رو با این دستور می تونید بخونید :

echo file_get_contents('.htaccess');
این فقط داخل هاست و توسط مدیریت پنل قابل دسترسیه . اگر هکر کل هاست بیاد دستش که ...
آقای MMSHFE (http://barnamenevis.org/member.php?55504-MMSHFE) آیا امکانش هست توسط php در فایل اچ تی اکسز قطعه کدی اضافه کنیم ؟ من تا حالا امتحان نکردم
اگر بشه ما می تونیم به صورت رندوم کد تولید کنیم ،
بجز هاست خودتون، نمیتونید فایل htaccess. سایت دیگری رو بخونید یا ویرایش کنید. درمورد هاست خودتون هم میشه ویرایشش کنید چون مثل هر فایل دیگری هست. البته میتونید سطح دسترسی رو برای فایل مربوطه فقط به read محدود کنید که نشه ازطریق کد هم ویرایشش کرد.

قبلا گفتم که خیر.
ما وقتی دربارهء سیستم هش امن برای ذخیرهء پسورد کاربران صحبت میکنیم فرض بر این هست که سایت هک بشه. وگرنه اگر سایت هک نشه که اصلا نیازی به این همه بند و بساط نیست.
اون بحث وبشل و این بحث خوندن htaccess هم با همین فرض بوده. یعنی فرض کردیم سایت هک شده. چون باید فرض کنیم. یعنی باید هش ها طوری باشه که حتی اگر همهء اطلاعات سایت دست هکرها افتاد، نتونن اصل پسوردهای کاربران رو به راحتی استخراج کنن.
ظاهرا چون آقای MMSHFE (http://barnamenevis.org/member.php?55504-MMSHFE) توجه نکردن که ما با چه فرضهایی صحبت میکنیم گفتن که سالت ثابت رو در htaccess ذخیره کنیم و جاش اونجا خیلی امنه. و من توضیح دادم که با این فرض که سایت هک شده، htaccess یا سورس کد یا بالاتر از www هیچکدام خیلی امن تر از بقیه نیستن.
دوست عزیز میدونی مشکل کجاست؟ اینکه شما بیش از حد توی رؤیا هستید! مرد حسابی وقتی هکر کل سایت دستشه و سورس کد و... رو داره، طبیعتاً الگوریتم تولید رمز رو داره و نیاز به رمزگشایی نداره! بعدش هم مگه مرض داره که بخواد هش ها رو رمزگشایی کنه و رمز اصلی رو در بیاره؟ خوب عین آدم عاقل میاد دوباره با همون الگوریتم یک رمز جدید برای کاربرها تولید میکنه. بعدش هم وقتی سورس کد رو داره، یعنی اینکه تونسته وارد کنترل پانل بشه و این هم به معنی دسترسی کامل به دیتابیس و ابزارهای موجود در کنترل پانل هست و نهایتاً میتونه تمام اطلاعات پروفایل اعضا و... رو ازطریق دیتابیس استخراج کنه. اونوقت میشه بفرمایید انگیزه هکر از اینکه بخواد رمز کاربرها رو کشف کنه چیه؟ شاید اون هم مثل شما وقت اضافه زیاد داشته باشه و بخواد بعد از کسب تمام اطلاعات لازم، برای گذران اوقات فراغتش رمز اونها رو هم کشف کنه. عزیز من باور کن هکرها هم آدمهای بیکاری نیستن. وقتی همه چیز سایت دستشونه، چهار تا رمز کاربران به هیچ دردشون نمیخوره. اصلاً آدم میاد رمز رو درمیاره که اطلاعات رو استخراج کنه. وقتی اطلاعات رو ازطریق دسترسی به دیتابیس در اختیار داره، دیگه رمز به دردش نمیخوره. حالا باز بیا و هرجا میرسی بگو این افرادی که باهام بحث میکنن بیسوادن! برو خوش باش.

eshpilen

جمعه 07 بهمن 1390, 20:53 عصر

پاسخ شما در این تاپیک: http://barnamenevis.org/showthread.php?325189

رضا قربانی

جمعه 07 بهمن 1390, 23:49 عصر

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

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

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

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

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

eshpilen

شنبه 08 بهمن 1390, 00:17 صبح

تو اصلا مشکل داری . خودت نمی دونی داری چی می گی و چی می خوایی . میایی توسط خود هاست فایل اچ تی اکسز رو می خونی و می گی هکر اینطوری می کنه.
منظورم این بود که اینکه MMSHFE (http://barnamenevis.org/member.php?55504-MMSHFE) گفت اچ تی اکسس مکان بسیار امن تری هست و آپاچی ازش محافظت میکنه صحت نداره؛ چون دسترسی به کد و توانایی استفاده از PHP به معنای دسترسی به اچ تی اکسس هم هست. بنابراین اونقدر تفاوتی نمیکنه سالت ثابت رو توی کد PHP هم بذاریم. هکر یا به کدهای ما دسترسی داره یا نداره. اگر نداشته باشه، پس جای سالت ثابت در کد هم کم و بیش امنه، اگر داشته باشه، دیگه تفاوت چندانی میان اچ تی اکسس و کد نیست چون توسط کد میشه اچ تی اکسس رو هم خوند.

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

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

رضا قربانی

شنبه 08 بهمن 1390, 00:35 صبح

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

دوم اینکه . این جمله من رو فکر کنم متوجه نشدی :
توی پست 47
می گی هش رو که بدست میاره

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

در هر صورت می گی هش رو بدست میاره

eshpilen

شنبه 08 بهمن 1390, 00:40 صبح

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

رضا قربانی

شنبه 08 بهمن 1390, 00:48 صبح

خب هکر نابغه و فرضی شما اومده و توی سیستم نفوذ کرده و تمام اطلاعات و فایل ها هم دستشه و شما هم می گید این هکر هر کاری کنی هک می کنه .
اینطور که شما می گید کل الگوریتمی که برای سالت استفاده کردیم دستشه و می تونه سریع دیکدش کنه یا جریانش رو بفهمه چیه
هکر شما نابغه هست و با یک دید می تونه بفهمه جریانش چی بوده

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

eshpilen

شنبه 08 بهمن 1390, 00:53 صبح

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

رضا قربانی

شنبه 08 بهمن 1390, 01:11 صبح

سه بار تکرار کردم آخر نفهمیدی من چی می گم . باز می گی ...

eshpilen

شنبه 08 بهمن 1390, 01:22 صبح

هیچوقت نباید اساس امنیت سیستم بر پنهان بودن الگوریتم باشه. این میشه Security through obscurity (http://en.wikipedia.org/wiki/Security_through_obscurity).
یکی از اصول ششگانهء کرکهف که مورد تایید متخصصان رمزنگاری امروزی هم هست:

سیستم رمزنگار باید هیچ نکته پنهان و محرمانه‌ای نداشته باشد بلکه تنها چیزی که باید سری نگاه داشت شود کلید رمز است.(اصل اساسی کرکهف) طراح سیستم رمزنگار نباید جزئیات سیستم خود را حتی از دشمنان مخفی نگاه دارد.
یه نگاهی به این پست (http://forum.iranphp.org/Thread-%D8%B0%D8%AE%DB%8C%D8%B1%D9%87%D8%A1-%D8%A7%D9%85%D9%86-%D9%BE%D8%B3%D9%88%D8%B1%D8%AF-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%A7%D9%86?pid=264 36#pid26436) بکن.
ما سیستم رو طوری طراحی میکنیم که هکر حتی اگر الگوریتم رو بدونه، نیاز به پردازش و زمان بسیار زیادتری برای کرک کردن هر هش خواهد داشت.

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

eshpilen

شنبه 08 بهمن 1390, 08:22 صبح

سه بار تکرار کردم آخر نفهمیدی من چی می گم . باز می گی ...
سه بار تکرار کردی. نه توضیح بیشتر.

بهرحال الان فکر کنم منظورت رو متوجه شدم.

ظاهرا منظورت اینه هکری که اینقدر باهوشه که به سایت نفوذ کامل بکنه و الگوریتم رو هم دربیاره میتونه رخنه ای در الگوریتم هش ضدکرک ما هم پیدا کنه و محدودیت های اون رو دور بزنه.

باید بگم این دوتا از نظر ماهیت و دشواری با هم تفاوت زیادی دارن.
همیشه افرادی زیادی تونستن و میتونن به سایتها نفوذ کنن.
همینطور الگوریتم هم چیزی نیست که فهم اون برای تمام افراد غیرممکن باشه. پیچوندن الگوریتم یه راه اصولی نیست.
روی سرور هم راه اصولی مطمئنی برای پنهان کردی چیزی مثل سالت ثابت وجود نداره.

اما اون بخشی که مربوط به الگوریتم هش ما میشه، چیز دیگری هست. اون یه روش اصولیه بر اساس علم رمزنگاری و با تکیه بر خواص Cryptographic hash function (http://en.wikipedia.org/wiki/Cryptographic_hash_function). روشی که متخصصان رمزنگاری طراحی کردن و تاییدش میکنن. روشی که محاسبات ریاضی تاییدش میکنن. روشی که تاکنون کسی موفق به شکست موثر اون نشده.

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

farnaz.saeedi

چهارشنبه 26 بهمن 1390, 09:17 صبح

با سلام، یک رشته ثابت درنظر بگیرین (مثلاً اسمتون) و اون رو md5 کنید و ترکیب کنید با رشته اصلی و دوباره اون رو md5 کنید. به این روش ترکیبی و روشهای مشابه اون که کلاً یک رشته ثابت رو مستقیماً یا بعد از یکسری تغییرات با رشته اصلی ترکیب کرده و دوباره اون رو کد میکنن، اصطلاحاً گفته میشه SALT که مزیتش اینه که نفوذگر نمیدونه کدی که اضافه شده کجای رشته است تا حذفش کنه و فرضاً اگه بتونه رشته رو دیکد کنه، باز هم رشته اصلی رو بدست نیاورده. مثال:

$url = 'www.mysite.com';
$pass = '123456';
$um = md5($url);
$pm = md5($pass);
$hash = substr($pm, 0, 3).$um.substr($pm, 3);
echo $hash;

توی کد فوق، از اونجا که فقط خودتون میتونید رشته اضافه از کارکتر سوم به بعد اضافه شده، درنتیجه بازکردن رمز چنین کدی خیلی خیلی سخت میشه. حالا خودتون برای اینکه پسورد رو چک کنید، کافیه اولاً توی دیتابیس hash$ رو ذخیره کنید و ثانیاً با کد زیر، ببینید پسورد درسته یا نه؟

$url = 'www.mysite.com';
$um = md5($url);
$pm = md5($_POST['pass']);
$hash = substr($pm, 0, 3).$um.substr($pm, 3);
mysql_connect('localhost', 'root', '') or die('Connection error');
mysql_select_db('dbname') or die('Database error');
$user = mysql_query("SELECT * FROM `users` WHERE (`username`='{$_POST['user']}' AND `password`='{$hash}')");
if($user && mysql_num_rows($user) > 0) {
// password is ok
}
else {
// password is wrong
}

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

5e825d55ad283aa400af464c76d713c07ad667a439c68f5145 dd2fcbecf02209
bf925d55ad283aa400af464c76d713c07adf8d1f05dc08cc3b 02e8fcf2c2ba57
c7125d55ad283aa400af464c76d713c07ad665b6ae814e11f0 455c7a65c5b345

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

$hash = substr($pm, 0, 3).$um.substr($pm, 3);

یعنی:

$hash = md5(substr($pm, 0, 3).$um.substr($pm, 3));

بعد همون رمزهای بالا اینجوری میشن:

39136997059a768019ac700799247c0d
b32c466499ee6005f49463e13913092e
15e88f67dbd3fdc8258aac0e4fa7162f

که دیگه کاراکترهای تکراری توشون نیست
حالا به نظر شما این کار مشکلی داره؟یا اینکه من دارم از روش اشتباهی استفاده میکنم.
تشکر