آموزش: ایجاد یک Hash امن برای پسوردها [بایگانی]

eshpilen

سه شنبه 30 شهریور 1389, 12:12 عصر

دربارهء کدومش منبع میخواید؟ اون مواردی که گفتم که واضح هست و اگر جاییش رو متوجه نشدید بگید تا بیشتر توضیح بدم. منبع هم زیاد هست که اگر روشن کردید دقیقا روی کدوم ادعا مشکل دارید میتونیم بگردیم و پیدا کنیم. چون چیزهایی که بنده گفتم کلی هستن و حاصل مطالعهء انبوهی از مطالب در این زمینه. من واقعا نمیدونم به کدوم قسمتش باید شما رو ارجاع بدم. مثلا کدوم جزء از یک کتاب و در چه ارتباطی. شما بگید درمورد کدوم ادعا یا الگوریتم دقیقا مشکل دارید تا بتونیم پیشتر بریم.
وگرنه باید کل مقالات و کتابهایی رو که خوندم بعنوان منبع بهتون معرفی کنم تا خودتون داخل اونها رو جستجو کنید. باید کامل بخونید و تازه بعضی مطالب از ارتباط چند مقاله یا کتاب حاصل میشن. اینطور نیست که مثلا یک جملهء خاص یک جا و بصورت کاملا مشخص باشه.
البته بعضی موارد جزو اصول تعریف شدهء پایه هستن. مثلا اینکه الگوریتم رمزنگاری ای که پنهان نگه داشته باشه، از نظر رمزنگاری هیچوقت امن محسوب نمیشه، یکی از گزاره های معروف و پایه ای در علم رمزنگاری و امنیت هست که فرد معروفی اون رو بیان کرده و میتونید با کمی جستجو براحتی پیداش کنید (فارسیش هم هست و جاهای زیادی تکرار شده).
در ویکیپدیا همونطور که گفتم مقالات کلی خوبی هست. منکه جزء به جزء رو حفظ نکردم با اسم و مشخصات که الان براحتی پیدا کنم، بلکه درک کردم و یاد گرفتم و نتایج و الگوریتم ها رو بخاطر سپردم. ولی خودتون اگر دوتا مقاله یا مطلب اصولی و معتبر راجع به هر زمینه ای که مشکل دارید بخونید، کم و بیش به اشارات به این موارد برمیخورید.
البته پیشرفته ترین و جامع ترین منبعی که برای مطلع شدن از مفاهیم و نکات مهمی که اشاره کردم تاحالا خوندم، کتاب Handbook of Applied Cryptography هست که فکر نمیکنم کسی در ممتاز بودن و معتبر بودن این کتاب و نویسندگانش شک داشته باشه. مثالهایی که گفتم در این کتاب مطرح شدن. ضمنا گزارهء همیشه از الگوریتم ها و روشهای استاندارد و مورد شناخت و تحلیل عمومی استفاده کنید و از روشهای شخصی و ناشناخته دوری کنید (حتی در اغلب موارد برای متخصصان رمزنگاری)، بازهم یک گزارهء کاملا شناخته شده و جزو اصول ثابت شده در مباحث امنیت و بخصوص رمزنگاری بحساب میاد که در بسیاری از منابع آمده (ولی من بیشتر یادم میاد که در کتاب مذکور خونده باشم).
خودتون اگر کمی فکر کنید و یک مقدار دانش و مهارت پایه ای در این مباحث داشته باشید، متوجه میشید که موارد ذکر شده بقدر کافی منطقی و روشن و مستدل هستن. مشکل سند هم باشه و اگر ضرورت بود گفتم که بگید دقیقا کدوم بخش تا ببینم میتونم چیز واضح و مختصری براش پیدا کنم یا نه (تاجایی که میتونم وقت و انرژی ای به این کار اختصاص بدم).
خب بعضی موارد هم خیلی متداول و بدیهی بنظر میان و شاید جایی بصورت مستقیم اشاره نشده باشه. مثلا روشهای ذخیرهء salt در دیتابیس کاری هست که در مهمترین برنامه های بهترین برنامه نویسان و شرکتها انجام میشه (مثلا نرم افزار همین فروم داره از چه روشی استفاده میکنه؟). بنابراین کسی بحثی روی این نداره که این روش درست هست یا نیست و بجاش روشی که مثلا دوستان در اینجا مثال زدن درسته. اگر هم شک دارید چنین روشهای ناشیانه ای رو در یک فروم رمزنگاری مطرح کنید؛ هرچند گاهی در این فرومها کسی جواب نمیده یا آدم باسوادی سوال شما رو نمیخونه و جواب نمیده (بخصوص که این مقوله خیلی حساس و تخصصی هست و از تخصص بیشتر برنامه نویسان عادی خارجه و با ریاضیات پیشرفته هم اکثرا سر و کار داره). بنابراین بهتره منابع پایه رو مطالعه کنید. و اگر بحث و استدلال کنیم بنظرم کاملا روشن میشه و از اصولی که گفتم هم میشه بصورت ریاضی وار ثابت کرد که چرا روشهایی که میگید درست نیستن (بطور مثال اون روش مذکور، با هر دو اصل رمزنگاری که بهش اشاره کردم منافات داره - یعنی نیاز به پنهان بودن الگوریتم، و ابتکاری و غیراستاندارد بودن روش).

bestirani2

سه شنبه 30 شهریور 1389, 12:43 عصر

من با این روش مخالفم
توی نظرات هم بعضی ها نظر من رو داشتم
وقتی salt رو توی دیتبایس ذخیر میکنی میشه مثل همون md5
اگر هکر بتونه به اطلاعات دیتابیس دسترسی پیدا کنه، راحت میتونه آن را برگردونه
در عوض بیاید چند خط کد بنویسید

$password = crypt('mypassword');

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

if (crypt($user_input, $password) == $password) {
echo "Password verified!";
}

اینطوری هم تأیید میشه در حقیقت، برای بررسی آن حتماً باید رمز کاربری رو بدونیم و راهی برای برگردوندن نیست و یا خیلی سخت هست

sama01

سه شنبه 30 شهریور 1389, 13:16 عصر

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

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

eshpilen

سه شنبه 30 شهریور 1389, 13:38 عصر

وقتی salt رو توی دیتبایس ذخیر میکنی میشه مثل همون md5

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

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

$password = crypt('mypassword');توی این حالت خودش یه Salt رندم به کار میگیره یعنی با هر بار اجرا نتیجه متفاوتی میگیریم
نه نیاز به دیتابیس هست و طبعاً کاهش سرعت نه وابسته به زمان

if (crypt($user_input, $password) == $password) {
echo "Password verified!";
}اینطوری هم تأیید میشه در حقیقت، برای بررسی آن حتماً باید رمز کاربری رو بدونیم و راهی برای برگردوندن نیست و یا خیلی سخت هست
اشتباه میکنید این روش هم اساسا با روشهای دیگر فرقی ندارد.
بالاخره salt یک جایی حال بصورت خوکار در داخل تابع و چه بوسیلهء کد شما تولید میشود و باید جایی هم برای بازیابی مجدد ذخیره شود. بطور مثال در رفرنس رسمی این تابع آمده است:

The standard DES-based crypt() returns the salt as the first two characters of the output.

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

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

It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

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

البته:

As of PHP 5.3.0, PHP contains its own implementation and will use that if the system lacks of support for one or more of the algorithms.

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

if no salt is provided, PHP will auto-generate either a standard two character (DES) salt, or a twelve character (MD5), depending on the availability of MD5 crypt().

میبینید که در این حالت هم PHP درصورت وجود نسخهء MD5 از این تابع، از همان الگوریتم MD5 استفاده میکند. یعنی درواقع استفاده از این تابع به اینصورت حداکثر برابر با استفاده از همان تابع MD5 همراه salt است.

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

منبع: http://php.net/manual/en/function.crypt.php

eshpilen

سه شنبه 30 شهریور 1389, 13:50 عصر

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

این دوستمون رفرنس این تابع رو با دقت نخونده بودن و متوجه نبودن که salt در اینجا هم در رشتهء خروجی مستتر هست و حتما باید ذخیره بشه.

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

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

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

eshpilen

سه شنبه 30 شهریور 1389, 14:37 عصر

برای کاملتر کردن مطلب، فکر میکنم اشاره به این منبع هم بد نباشد، چون بنده به اصطلاح Rainbow table اشاره ای نکردم (قبلا خوانده بودم اما حضور ذهن نداشتم):

http://en.wikipedia.org/wiki/Rainbow_table

بخشی از این مقاله:

A salt is often employed with hashed passwords to make this attack more difficult, often infeasible

همانطور که میبینید، اضافه کردن یک salt میتواند چنین حمله هایی را دشوارتر یا بقول خودش اغلب غیرممکن کند.

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

bestirani2

سه شنبه 30 شهریور 1389, 15:23 عصر

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

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

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

The standard DES-based crypt() returns the salt as the first two characters of the output.

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

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

It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

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

البته:

As of PHP 5.3.0, PHP contains its own implementation and will use that if the system lacks of support for one or more of the algorithms.

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

if no salt is provided, PHP will auto-generate either a standard two character (DES) salt, or a twelve character (MD5), depending on the availability of MD5 crypt().

میبینید که در این حالت هم PHP درصورت وجود نسخهء MD5 از این تابع، از همان الگوریتم MD5 استفاده میکند. یعنی درواقع استفاده از این تابع به اینصورت حداکثر برابر با استفاده از همان تابع MD5 همراه salt است.

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

منبع: http://php.net/manual/en/function.crypt.php

من در کل در مورد ذخیر salt در دیتابیس بحث کردم که پست اول توی مقاله بود و بقیه مطالب رو نخواندم
این کد رو هم به عنوان نمونه از داخل خود php.net گذاشتم و گفتم از ذخیره در دیتابیس بهتر هست
به هر حال همین روش رو با کمی تغییر میشه به عنوان بهترین کار در نظر گرفت
بحث من ای بود که روی خود پسور اکتفا کنید نه چیز دیگری
زمان و نام کاربری گزینه اصلاً خوبی نیست
همون قسمت اول رو میتوانیم با SHA512 رمز نگاری کنیم
در کل روش و ... نمیدهم
فقط این توصیه رو کردم و دارم بهترین چیز برای Salt خود پسور هست
در ضمن mcrypt اصلاً مناسب نیست چون قابل بازگشت هستند
این تابع برای فرستادن اطلاعات برای کوکی مناسب هست

mohmadd

سه شنبه 30 شهریور 1389, 16:25 عصر

من با این روش مخالفم
توی نظرات هم بعضی ها نظر من رو داشتم
وقتی salt رو توی دیتبایس ذخیر میکنی میشه مثل همون md5
اگر هکر بتونه به اطلاعات دیتابیس دسترسی پیدا کنه، راحت میتونه آن را برگردونه
در عوض بیاید چند خط کد بنویسید

$password = crypt('mypassword');توی این حالت خودش یه Salt رندم به کار میگیره یعنی با هر بار اجرا نتیجه متفاوتی میگیریم
نه نیاز به دیتابیس هست و طبعاً کاهش سرعت نه وابسته به زمان

if (crypt($user_input, $password) == $password) {
echo "Password verified!";
}اینطوری هم تأیید میشه در حقیقت، برای بررسی آن حتماً باید رمز کاربری رو بدونیم و راهی برای برگردوندن نیست و یا خیلی سخت هست
بنده هنوز نفهمیدم این تابع چطور کار میکنه ؟
الان این روش پیشنهاد میشه یا خیر ؟

bestirani2

سه شنبه 30 شهریور 1389, 18:33 عصر

بنده هنوز نفهمیدم این تابع چطور کار میکنه ؟
الان این روش پیشنهاد میشه یا خیر ؟
با کمی تغییر پیشنهاد میشه

eshpilen

سه شنبه 30 شهریور 1389, 19:18 عصر

این کد رو هم به عنوان نمونه از داخل خود php.net گذاشتم و گفتم از ذخیره در دیتابیس بهتر هست

در سایت php.net بهرحال برای هرمورد مثال هست، ولی این دلیل نمیشه اون روش امن ترین روش باشه. برای توابع دیگه هم مثال هست.
ضمنا یکسری هم کامنت هستن که میتونن اشتباه یا ضعیف باشن و کسی تضمین نکرده اشکالی نداشته باشن.
درکل هم salt همیشه بهرحال ذخیره میشه. مگر اینکه از salt استفاده نکنیم یا از روش دیگری استفاده کنیم، اما من تا بحال به این روشهای دیگر که امنتر و اصولی تر باشم برنخوردم. مطمئن باشید salt اگر درست استفاده بشه، هیچ خطری نداره و میتونید در دیتابیس ذخیرش کنید.

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

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

در ضمن mcrypt اصلاً مناسب نیست چون قابل بازگشت هستندنمیدونم من دقیقا یادم نیست خیلی وقت پیش دنبال یه تابع هش امن تر از MD5 در پی اچ پی بودم که یه چیزی مثل این رو پیدا کردم. بهرحال یادم هست که از توابع هش استفاده میکردیم، نه توابع رمزنگاری قابل بازیابی.
اگر mcrypt تابع هش نداره شاید این یکی مناسب باشه: http://www.php.net/manual/en/function.hash.php
ظاهرا قابلیت استفاده از همه نوع الگوریتم هش رو داره.

bestirani2

سه شنبه 30 شهریور 1389, 21:39 عصر

در سایت php.net بهرحال برای هرمورد مثال هست، ولی این دلیل نمیشه اون روش امن ترین روش باشه. برای توابع دیگه هم مثال هست.
ضمنا یکسری هم کامنت هستن که میتونن اشتباه یا ضعیف باشن و کسی تضمین نکرده اشکالی نداشته باشن.
درکل هم salt همیشه بهرحال ذخیره میشه. مگر اینکه از salt استفاده نکنیم یا از روش دیگری استفاده کنیم، اما من تا بحال به این روشهای دیگر که امنتر و اصولی تر باشم برنخوردم. مطمئن باشید salt اگر درست استفاده بشه، هیچ خطری نداره و میتونید در دیتابیس ذخیرش کنید.

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

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

نمیدونم من دقیقا یادم نیست خیلی وقت پیش دنبال یه تابع هش امن تر از MD5 در پی اچ پی بودم که یه چیزی مثل این رو پیدا کردم. بهرحال یادم هست که از توابع هش استفاده میکردیم، نه توابع رمزنگاری قابل بازیابی.
اگر mcrypt تابع هش نداره شاید این یکی مناسب باشه: http://www.php.net/manual/en/function.hash.php
ظاهرا قابلیت استفاده از همه نوع الگوریتم هش رو داره.

منظور من از سایت php.net توی خود آموزشش بود نه نظر کاربران
به هر حال نظر من این بود که ذخیره اون توی دیتابیس خطرناک هست
در مورد درست کردن Salt از روی پسور باید بگم که نام کاربری رو میشه توی سایت دید یا زمان رو salt اش رو باید توی دیتابیس ذخیر کرد و یا خودش رو
به هر هر حال این اطلاعات حالا چه تو خود سایت و چه نفوذ به دیتابیس قابل دیدن هست
ولی وقتی از روی پسور salt رو تولید کنیم، پسور هیچ جایی ذخیره نمیشه و رمزنگاری شده ذخیره میشه ولی کاربر پسور رو مجدد برای ورود وارد میکنه
یعنی زمان یا نام کاربری برابر با یک چیز ذخیره شده هست که به نحوی قابل دسترسی هست ولی پسورد رو فقط صاحب اکانت میدونه
mcrypt یا crypt هم الگوریتم هش نیستند و از الگوریتمهای مانند md5 استفاده میکنند
یک چیز دیگه هم اینکه اصلاً نیاز نیست یک برنامه رو پیچیده کنید
مگر میخواید سایت ناسا رو بیارید بالا
همون مثال ساده ای که زدم به نظرم کفایت میکند

rapidpich

چهارشنبه 31 شهریور 1389, 12:21 عصر

وقتی یکی به دیتابیس شما دسترسی داره دیگه چه نیازی به دیکد کردن رمزا داره؟

sama01

چهارشنبه 31 شهریور 1389, 13:10 عصر

منظورتان چیست؟
یعنی چگونه می‌تواند وارد شود؟

bestirani2

چهارشنبه 31 شهریور 1389, 18:28 عصر

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

eshpilen

پنج شنبه 01 مهر 1389, 08:35 صبح

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

eshpilen

پنج شنبه 01 مهر 1389, 08:52 صبح

به هر حال نظر من این بود که ذخیره اون توی دیتابیس خطرناک هست

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

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

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

mcrypt یا crypt هم الگوریتم هش نیستند و از الگوریتمهای مانند md5 استفاده میکننددرمورد mcrypt اشتباه کردم. بعدا یادم افتاد که دنبال پیاده سازی PHP از الگوریتم هایی مثل AES256 میگشتم که این «رابط» رو بهم معرفی کردن (ظاهرا این فقط یک رابط PHP برای کتابخانه های مستقل دیگری هست که البته همراه PHP پکیج شدن).
اما crypt یک تابع هش هست که تاجایی که یادمه از الگوریتم DES برای این منظور استفاده میکنه. البته DES خودش الگوریتم هش نیست، اما میشه با استفاده از اون یک الگوریتم هش هم ساخت. البته در اینکه مثلا crypt خودش یک wrapper باشه و غیره مناقشه ای نیست و اهمیت خاصی نداره. اشاره بهرحال به الگوریتم های زیرین اونا هست و اینکه خروجی از چه نوعی هست و توسط چه الگوریتمی تولید شده.

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

bestirani2

پنج شنبه 01 مهر 1389, 17:43 عصر

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

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

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

درمورد mcrypt اشتباه کردم. بعدا یادم افتاد که دنبال پیاده سازی PHP از الگوریتم هایی مثل AES256 میگشتم که این «رابط» رو بهم معرفی کردن (ظاهرا این فقط یک رابط PHP برای کتابخانه های مستقل دیگری هست که البته همراه PHP پکیج شدن).
اما crypt یک تابع هش هست که تاجایی که یادمه از الگوریتم DES برای این منظور استفاده میکنه. البته DES خودش الگوریتم هش نیست، اما میشه با استفاده از اون یک الگوریتم هش هم ساخت. البته در اینکه مثلا crypt خودش یک wrapper باشه و غیره مناقشه ای نیست و اهمیت خاصی نداره. اشاره بهرحال به الگوریتم های زیرین اونا هست و اینکه خروجی از چه نوعی هست و توسط چه الگوریتمی تولید شده.

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

1. من نگفتم پسورد رو به صورت تنها به کار ببرید، گفتم حتماً به کار ببرید
2. به نظر من میتونه. همیشه به همه چیز شک داشته باش توی امنیت مگر اینکه خلافش ثابت بشه :لبخند:
3. طبق تجربیات و مطالاعات من همون روشی که گفتم میشه گفت بهترین هست البته با کمی آب و تاب، جای کار داره و با ذخیره توی دیتابیس کاملاً مخالفم
بحث امنیت نمیشه یک راهکار کلی داد، من نوع کاری که تو هر پروژه ام انجام میدهم با دیگری متفاوت هست ولی توی همشون پسور توی هش هست
4. crypt هم یک تابع هست که میتونه با توجه به Salt ای که بهش میدی نوع هش رو تعیین کنید

<?php
if (CRYPT_STD_DES == 1) {
echo 'Standard DES: ' . crypt('rasmuslerdorf', 'rl') . "\n";
}

if (CRYPT_EXT_DES == 1) {
echo 'Extended DES: ' . crypt('rasmuslerdorf', '_J9..rasm') . "\n";
}

if (CRYPT_MD5 == 1) {
echo 'MD5: ' . crypt('rasmuslerdorf', '$1$rasmusle$') . "\n";
}

if (CRYPT_BLOWFISH == 1) {
echo 'Blowfish: ' . crypt('rasmuslerdorf', '$2a$07$usesomesillystringforsalt$') . "\n";
}

if (CRYPT_SHA256 == 1) {
echo 'SHA-256: ' . crypt('rasmuslerdorf', '$5$rounds=5000$usesomesillystringforsalt$') . "\n";
}

if (CRYPT_SHA512 == 1) {
echo 'SHA-512: ' . crypt('rasmuslerdorf', '$6$rounds=5000$usesomesillystringforsalt$') . "\n";
}
?>

5. منظورم این بود یک پروژه بزرگ نمیخوایم انجام بدیم که اینهمه بحث کنیم

rapidpich

جمعه 02 مهر 1389, 08:59 صبح

منظورتون sql injection هست؟
هکرش حرفه ای باشه میاد تو سیستم

eshpilen

جمعه 02 مهر 1389, 16:13 عصر

1. من نگفتم پسورد رو به صورت تنها به کار ببرید، گفتم حتماً به کار ببرید

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

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

4. crypt هم یک تابع هست که میتونه با توجه به Salt ای که بهش میدی نوع هش رو تعیین کنید
بله میدونم.
خب منظور؟
منم قبلا گفتم وادارش کنید از الگوریتم های قوی تر استفاده کنه.
بهرحال اصول کار یکی هست. قویترین حالت حالتی هست که از یک salt مناسب که تصادفی هست استفاده بشه.

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

sama01

جمعه 02 مهر 1389, 16:49 عصر

جناب eshpilen؛
این صحبتی در ادامه خواهم گفت، علیه شما نیست.

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

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

- - - - - - - - - - - - - - - - - - - -
از این موضوع بگذریم.

یه سوال:
چرا استفاده از Password در salt مفید نیست. ولی درج یک رشته که در db قابل دست‌رسی است اشکالی ندارد؟
من استدلال شما را در صورتی قبول دارم که هکر، الگوریتم تولید salt را بداند. یعنی به source فایل php ما دسترسی پیدا کنه.
ولی دسترسی‌اش به اطلاعات db از طریق مثلا sql injection نمی‌تواند کمکی به او کند.

ولی اگر salt به صورت clear در db ذخیره شود، دسترسی هکر به اطلاعات db از طریق sql injection، نیمی از راه را برای هکر هموار می‌کند.

درسته؟

- - - - - - - - - - - - - - -
ممنون می‌شم یه توضیح کلی هم در مورد نحوه‌ی دورزدن md5 بیان کنید. منظورم بیان دقیق مراحل نیست. باین روش کلی کار است.

eshpilen

جمعه 02 مهر 1389, 17:55 عصر

یه سوال:
چرا استفاده از Password در salt مفید نیست. ولی درج یک رشته که در db قابل دست‌رسی است اشکالی ندارد؟
من استدلال شما را در صورتی قبول دارم که هکر، الگوریتم تولید salt را بداند. یعنی به source فایل php ما دسترسی پیدا کنه.
ولی دسترسی‌اش به اطلاعات db از طریق مثلا sql injection نمی‌تواند کمکی به او کند.
خوبه الان دقیقا متمرکز شدی روی بعضی نکات مهم.
اصل معروف و پایه ای در امنیت و رمزنگاری هست که میگه اتکا بر پنهان بودن الگوریتم برای امنیت، نادرست هست. اشکال مختلف و موارد بیان مختلفی از این قانون وجود داره. و بنظرم با همون مبحث Security through obscurity در ارتباط یا همجنس هست.
حالا اگر برای این سند میخواید فکر کنم بشه براحتی پیدا کرد؛ چون چنین مفاهیمی خیلی معروف و پایه و بدوی هستن در مبحث امنیت و رمزنگاری. یا اگر مشکل شما سند نیست و این اصل رو که تمام خبرگان این فیلد قبول دارن و مبنای کارشون قرار دادن قبول نمیکنید، بفرمایید که چرا.

ولی اگر salt به صورت clear در db ذخیره شود، دسترسی هکر به اطلاعات db از طریق sql injection، نیمی از راه را برای هکر هموار می‌کند.

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

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

In 1996, a flaw was found with the design of MD5. While it was not a clearly fatal weakness, cryptographers began recommending the use of other algorithms, such as SHA-1 (http://en.wikipedia.org/wiki/SHA-1) (which has since been found also to be vulnerable). In 2004, more serious flaws were discovered, making further use of the algorithm for security purposes questionable; specifically, a group of researchers described how to create a pair of files that share the same MD5 checksum (http://en.wikipedia.org/wiki/Checksum).[4] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E %E2%80%8E%E2%80%8E%E2%80%8Eite_note-autogenerated1-3)[5] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E %E2%80%8E%E2%80%8E%E2%80%8Eite_note-autogenerated2-4) Further advances were made in breaking MD5 in 2005, 2006, and 2007.[6] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E %E2%80%8E%E2%80%8E%E2%80%8Eite_note-5) In an attack on MD5 published in December 2008, a group of researchers used this technique to fake SSL certificate validity.[7] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E %E2%80%8E%E2%80%8E%E2%80%8Eite_note-sslHarmful-6)[8] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E %E2%80%8E%E2%80%8E%E2%80%8Eite_note-browserflaw-7) US-CERT of the U. S. Department of Homeland Security (http://en.wikipedia.org/wiki/Department_of_Homeland_Security) said MD5 "should be considered cryptographically broken and unsuitable for further use,"[9] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E %E2%80%8E%E2%80%8E%E2%80%8Eite_note-8) and most U.S. government applications will be required to move to the SHA-2 (http://en.wikipedia.org/wiki/SHA-2) family of hash functions after 2010.[10] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E %E2%80%8E%E2%80%8E%E2%80%8Eite_note-9)

The security of the MD5 hash function is severely compromised. A collision attack (http://en.wikipedia.org/wiki/Collision_attack) exists that can find collisions within seconds on a computer with a 2.6Ghz Pentium4 processor (complexity of 224.1).[15] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E ite_note-14) Further, there is also a chosen-prefix collision attack (http://en.wikipedia.org/wiki/Chosen-prefix_collision_attack) that can produce a collision for two chosen arbitrarily different inputs within hours, using off-the-shelf computing hardware (complexity 239).[16] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E ite_note-15)
These collision attacks have been demonstrated in the public in various situations, including colliding document files[17] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E ite_note-16)[18] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E ite_note-special-file-formats-17) and digital certificates (http://en.wikipedia.org/wiki/Digital_certificate).[7] (http://en.wikipedia.org/wiki/Md5C#%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E%E2%80%8E ite_note-sslHarmful-6)
As of 2009, a theoretical attack also breaks MD5's preimage resistance (http://en.wikipedia.org/wiki/Preimage_resistance).

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

ضمنا بنده تعجب میکنم آیا شما در جریان این بحث زحمت خواندن منابع در دسترس و روشن موجود را به خودتان نداده اید یا چیز دیگری را میخواهید بدانید!؟

منبع: http://en.wikipedia.org/wiki/Md5

sama01

جمعه 02 مهر 1389, 19:08 عصر

خوب.
من یک شکل ساده کشیدم که شاید به‌تر بتونم منظورم رو منتقل کنم.

http://www.barnamenevis.org/forum/attachment.php?attachmentid=57021&stc=1&d=1285344014

در حالت 1، یک salt تصادفی ساخته می‌شود؛ با password ترکیب می‌شود و پس از hash‌ شدن، هم رمز hash شده و هم salt در db ذخیره می‌شوند.
در حالت 2، یک salt بر اساس password ساخته می‌شود؛ با password ترکیب می‌شود و پس از hash‌ شدن،فقط رمز hash شده در db ذخیره می‌شود.

حال فرض کنیم یک هکر توانسته پس از یک sql injection به تمام اطلاعات جدول users دست پیدا کند.
در حالت 1:
هکر به username، رمز hash شده، و salt دسترسی پیدا کرده است. یعنی هکر به یک رشته‌ی hash شده دست پیدا کرده که می‌داند hash شده‌ی ترکیب رمز کاربر و salt است.

در حالت 2:
هکر به username و رمز hash شده دست یافته است. ولی نمی‌داند که این رمز، hash شده‌ی ترکیب رمز کاربر با چه چیزی است.

آیا در این حالت، باز هم شانس هکر برای هک کردن حالت 2 بیش از حالت 1 است؟

توجه: فرایند ساخت salt در هر دو حالت می‌تواند پیچیده باشد.

eshpilen

جمعه 02 مهر 1389, 20:15 عصر

هکر به username و رمز hash شده دست یافته است. ولی نمی‌داند که این رمز، hash شده‌ی ترکیب رمز کاربر با چه چیزی است.البته به شرطی که الگوریتم لو نره این مطلب رو نمیدونه.

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

bestirani2

جمعه 02 مهر 1389, 20:32 عصر

1. من نظرم رو دادم. به هر حال دید و فکر فرق میکنه.
2. اگر سند درست حسابی دارید خودتون ارائه کنید
من استدلال خودم رو دادم
وقتی ما پسور را با یک عامل دیگه ترکیب میکنیم
طبعاً چون فقط کاربر پسورد رو دارد، هیچ کس دیگه کلید رمزگشایی رو ندارد
در صورتی که یک عامل ذخیره شده در دیتابیس اگه هکر بهش نفوذ هم پیدا نکنه، حداقلش این هست خود صاحب سایت میتونه اون رو بدست بیاره
مسلماً الگوریتمی قویتر هست که فقط صاحب پسورد بتونه اون رو برگردونه
لحن صحبتتون هم اصلاً درست نبود
دو حالت داریم
یا هر دو سر یک چیز با استدلال بحث میکنیم که باید همدیگه رو با استدلال قانع کنیم که در این صورت "پسر جان همینطور یه حرفی نزن. ببخشید که رک صحبت میکنم، ولی شما چه دانش و صلاحیتی در این مقوله ها داری که میگی با فلان چیز مخالفی؟"
یا یک چیز ثابت شده هست (حالا شاید به غلط ثابت شده مثل زمین که اول میگفتند گرد هست و هزاران چیز علمی) که اگر اینطور هست از یک سایت معتبر یک منبع بدید (نه یک وبلاگ عادی و یا سیستم ها بحث و گفتگو)
3. مطمئن باشید من دائم در حال یادگیری هستم و پروژه بزرگ هم دارم
اینجا بحث یادگیری نیست
اینجا بحث سر درستی یک موضوع هست که یا باید با استدلال قانع کنید من رو یا با یک سند محکم که اگر این کار رو کردید، چشم من اون را یاد میگیرم.

eshpilen

جمعه 02 مهر 1389, 20:47 عصر

1. من نظرم رو دادم. به هر حال دید و فکر فرق میکنه.

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

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

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

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

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

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

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

eshpilen

جمعه 02 مهر 1389, 20:56 عصر

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

bestirani2

جمعه 02 مهر 1389, 21:07 عصر

1. دقیقاً
حرفی هست که من اول زدم طی تجربیات و مطالعات
باور کنید منم مطالعه کردم، حالا نمیدونم منبابعی که خواندیم این همه فرق داشته یا نگرشمون از اون مطلب :لبخند:
البته مطالبی رو که میخوانم من، فکر میکنم و هر چیزی رو قبول نمیکنم
چون هر کسی میتونه کتاب بده بیرون
2. دلیل این که منم گفتم بحث رو ادامه ندیم همین بود هر کدام چیزهای ناشی از بینش و مطالعات خودمون داریم و هیچکدام هم قانع نمیشیم و بحث به جایی نمیرسه
3.درسته در نهایت ذخیره میشه ولی مثل یک کلید نصفه میمونه و تا پیش نصفه دیگرش نباشه نمیتونه در رو باز کنه
اولاً من مطالعاتی از بزرگان به قول شما داشتم این طور بوده
دوماً اونها که خدا نیستند که حرف 100% زده باشند
این همه دانشمند که امروزه خلاف گفته هاشون ثابت شده
4. اون وقت این خبرگان کیا هستند؟
چرا فکر میکنید 100 برابر من خواندید؟
در ضمن این رو از من داشته باش، مطالعه توی برنامه نویسی 10% هست
40% تمرین و کد نویسی و 50% بقیه هوش و علاقه
من اصلاً عادت ندارم و خوشم نمیاد یک برنامه رو به صورت روالی بنویسم
یعنی چیزهایی که قبلاً نوشته شده مثلاً یک سیستم وبلاگ رو با یک سری امکانات دیگه و همیشه سعی کردم چیزهای جدید و با الگوریتم های جدید بنویسم
فکرم نمیکنم دیگه جایی برای بحث باشه به غیر از این که چیز جدید بگید
چون من یکی که واقعاً وقتم پر هست و نمیتونم بیام و جواب بدهم

eshpilen

جمعه 02 مهر 1389, 21:08 عصر

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

bestirani2

جمعه 02 مهر 1389, 21:17 عصر

sama01

جمعه 02 مهر 1389, 21:18 عصر

چیزهایی که بنده گفتم برای هرکدومش صدها صفحه مطلب خوندم.
کی به کیه؟ من هم می‌گم 1000 صفحه خوندم.
دوست عزیز؛ این طوری نمی‌شه. اگر خودت بدونی کافیه؟ یا باید به دیگران هم منبع مراجعه بدی؟

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

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

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

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

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

eshpilen

جمعه 02 مهر 1389, 21:26 عصر

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

همه این‌جا هستیم تا شانه به شانه‌ی یک‌دیگر دانسته‌های‌مان را روی هم بگذاریم و پیش‌رفت کنیم.
هاه!
شانه به شانه!
دست از این تعارفات و فروتنی نمایی ها بردارید.
من با هرکسی شانه به شانه نمیشوم. آنهم به صرف اینکه ایرانیست یا همکار است یا در این فروم است و غیره.
واقعا شما برای این اینجا هستید؟ منکه باور نمیکنم. لطفا سندش را لطف کنید :قهقهه:

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

شما وقتی خود salt را در db در اختیار هکر قرار بدید، آیا بخشی از نیاز هکر را پاسخ نداده‌اید؟
چه پاسخ بی ربطی به نقل قول مربوطه. البته از شما بعید هم نیست. چون منطق شما در صفات شما حل میشود.

bestirani2

جمعه 02 مهر 1389, 22:03 عصر

eshpilen

جمعه 02 مهر 1389, 22:14 عصر

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

به عنوان نمونه
http://barnamenevis.org/forum/showthread.php?t=235293

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

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

نکته جالب دیگرش اینه که ادعا میکنید
توی تمام مطالب
سی، سی++، توسعهء وب (PHP و بقیهء مخلفاتش)، Qt، Python، دات نت (C#‎‎‎هزاران کتاب مطالعه کردید که در این صورت معلوم نیست چند سالتون هست
در ضمن مطالعه ای که به عمق مطلب نرسید و خودتون کد نزنید هیچ فایده ای نداره

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

bestirani2

جمعه 02 مهر 1389, 22:26 عصر

آه از بحث اصلی پریدید به بحث شخصیت و سواد طرف مقابل.
یعنی مغلطهء حمله به شخص بجای پاسخگویی و بحث با سند و استدلال.
اما من فکر نمیکنم واقعا نیازی باشد به این حرفهای بی ربط شما جواب بدهم.
بله شما هرجور دوست دارید فکر و ادعا کنید. نظر شما برای من مهم نیست. تنها سود علمی ای که از این فروم بگیرم یا به دیگرانی که با لیاقت باشند بدهم برایم مهم است.
این شما بودید پریدید توی بحث شخصیت و شروع به توهین به من و sama01 (http://barnamenevis.org/forum/member.php?u=42615) کردید
این چیزی هم که من نوشتم مربوط به ادعای شما بود که کلی مطالعه داشتید و ... نه صحبت روی شخصیتتون.
پاسخ آخر من کاملاً واضح هست و این شما هستید که به جای بحث و استدلال از نظر خبرگانی که هیچ اثری ازشون نیست، صحبت میکنید

eshpilen

جمعه 02 مهر 1389, 23:30 عصر

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

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

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

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

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

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

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

این شما بودید پریدید توی بحث شخصیت و شروع به توهین به من و sama01 (http://barnamenevis.org/forum/member.php?u=42615) کردید

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

eshpilen

شنبه 03 مهر 1389, 00:29 صبح

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

پس روش ظاهرا صحیح و ممکن ما برای افزایش امنیت چی شد؟
Random salt + secret modification in input string

bestirani2

شنبه 03 مهر 1389, 06:38 صبح

اگر ما salt را از خود پسورد تولید کنیم، نتیجتا خروجی دو پسورد یکسان بازهم یکسان خواهد بود

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

$password = crypt('mypassword');

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

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

خوب وقتی این دیتای کاملاً تصادفی رو در اختیار هکر باشه، دیگه تصادفی نیست
salt مثل کلید میمونه
وقتی هکر اون رو نداره نمیتونه تمام کلیدهای دنیا رو امتحان کنه تا یک در رو باز کنه ولی وقتی داره، خوب باز میکنه :لبخند:
شاید اساس این توابع غیر قابل بازگشت باشد ولی هزار راه برای برگشت وجود دارد
به عنوان نمونه توابع mcrypt هم از الگوریتمهای هش کردن crypth استفاده میکنند ولی با دانستن کلید و چند مورد دیگه میشه برش گردوند

در ضمن سورس این الگوریتمها رو هم میشه پیدا کرد و از روی اونهای برگردوند ولی وقتی Salt، پسورد باشد، هکر کلیدی ندارد و عملاً بازگرداندن محال هست که تنها راه تست یک سری پسورد معمول هست که این مشکل از طرف کاربر هست که برای حل این مشکل بایدکاربر رو محدود به حداقل طول پسور و به کار بردن حتمی اعداد و علائم ویژه کرد

در مورد انتخاب نام کاربری به نام salt کاملاً واضح هست که بیشتر سیستم ها اون رو به بقیه کاربر ها نشون میدند که این کاملاً رد هست

در مورد زمان، هکر تنها کافیه بتونه زمان ثبت نام رو پیدا کنه و کلیه ثانیه های اون زمان رو تست کنه، پس کار سختی نیست ورود

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

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

eshpilen

شنبه 03 مهر 1389, 08:49 صبح

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

$password = crypt('mypassword'); که در این وضعیت، salt خودکار انتخاب میشه و این یعنی 6 تا الگوریتم هش و هزاران هزار کلید یک هش تصادفی داریم که با هر بار اجرا میبینیم که حتی طولش با دفعه قبل هم یکسان نیست.
پس نتیجه دو پسور یکسان، یکسان میشود رد می شود.

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

خوب وقتی این دیتای کاملاً تصادفی رو در اختیار هکر باشه، دیگه تصادفی نیست

salt مثل کلید میمونه

مهمترین کار salt این است که از حملهء مهم و موثری جلوگیری میکند که قبلا رفرنس و سند آنرا هم در این تاپیک گذاشتم:

http://en.wikipedia.org/wiki/Rainbow_table

A rainbow table is a lookup table (http://en.wikipedia.org/wiki/Lookup_table) offering a time-memory tradeoff (http://en.wikipedia.org/wiki/Space-time_tradeoff) used in recovering the plaintext (http://en.wikipedia.org/wiki/Plaintext) password (http://en.wikipedia.org/wiki/Password) from a password hash generated by a hash function (http://en.wikipedia.org/wiki/Hash_function), often a cryptographic hash function (http://en.wikipedia.org/wiki/Cryptographic_hash_function). A common application is to make attacks against hashed passwords feasible. A salt (http://en.wikipedia.org/wiki/Salt_%28cryptography%29) is often employed with hashed passwords to make this attack more difficult, often infeasible.

در اینجا به وضوح بیان شده است که این روش برای بازیابی پسورد از هش استفاده میشود. و اینکه استفاده از salt آنرا دشوارتر، در اغلب موارد غیرممکن، میسازد.

salt هم کلید نیست. همچنان که هش ساده هم کلید نیست.

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

در ضمن سورس این الگوریتمها رو هم میشه پیدا کرد و از روی اونهای برگردوند ولی وقتی Salt، پسورد باشد، هکر کلیدی ندارد و عملاً بازگرداندن محال هست که تنها راه تست یک سری پسورد معمول هست که این مشکل از طرف کاربر هست که برای حل این مشکل بایدکاربر رو محدود به حداقل طول پسور و به کار بردن حتمی اعداد و علائم ویژه کرد
بازهم که حرف خودتان را زدید!
یعنی شما تا اینجا متوجه نشدید تولید salt از روی پسورد چه مشکل بزرگی دارد؟
و اینکه چرا در هیچ الگوریتم و تابع استانداردی از این روش استفاده نمیشود؟
اگر salt از روی پسورد تولید شود، امکان استفاده از روشهایی مثل Rainbow table ممکن میشود. این را قبول دارید یا نه؟
و فکر میکنید چرا برای کرک هش پسوردهای ساده هم از چنین روشهای غیرمستقیمی استفاده میشود و از خود الگوریتم که به ادعای شما قابل برگرداندن است استفاده نمیکنند؟
شما دیگر ادعاهای عجیب و بزرگی میکنید. اگر الگوریتم هش بصورت مستقیم با استفاده از الگوریتم خودش قابل بازگردانی بود که دیگر الگوریتم هش نمیشد و فایده ای نداشت!

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

در مورد انتخاب نام کاربری به نام salt کاملاً واضح هست که بیشتر سیستم ها اون رو به بقیه کاربر ها نشون میدند که این کاملاً رد هستکسی کجا گفت نام کاربری و salt را به هم ارتباط دهیم؟!

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

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

eshpilen

شنبه 03 مهر 1389, 09:00 صبح

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

eshpilen

شنبه 03 مهر 1389, 09:08 صبح

در ضمن این رو از من داشته باش، مطالعه توی برنامه نویسی 10% هست
40% تمرین و کد نویسی و 50% بقیه هوش و علاقه

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

eshpilen

شنبه 03 مهر 1389, 16:26 عصر

الان بخش تولید اعداد تصادفی رو از کتاب Handbook of Applied Cryptography داشتم نگاه میکردم. دیدم یک بخش از متنش خوب خلاصه و کلی و پرمحتوا هست براتون میذارم. اینم بخاطر سند دوستی شما! بالاخره چیزی عایدتون شد :لبخند:

(i) Hardware-based generators
Hardware-based random bit generators exploit the randomnesswhich occurs in some physical
phenomena. Such physical processes may produce bits that are biased or correlated, in
which case they should be subjected to de-skewing techniques mentioned in (iii) below.
Examples of such physical phenomena include:
1. elapsed time between emission of particles during radioactive decay;
2. thermal noise from a semiconductor diode or resistor;
3. the frequency instability of a free running oscillator;
4. the amount ametal insulator semiconductor capacitor is charged during a fixed period
of time;
5. air turbulence within a sealed disk drive which causes random fluctuations in disk
drive sector read latency times; and
6. sound from a microphone or video input from a camera.
Generators based on the first two phenomena would, in general, have to be built externally
to the device using the random bits, and hence may be subject to observation or manipulation
by an adversary. Generators based on oscillators and capacitors can be built on VLSI
devices; they can be enclosed in tamper-resistant hardware, and hence shielded from active
adversaries.
(ii) Software-based generators
Designing a random bit generator in software is even more difficult than doing so in hardware.
Processes upon which software random bit generators may be based include:
1. the system clock;
2. elapsed time between keystrokes or mouse movement;
3. content of input/output buffers;
4. user input; and
5. operating system values such as system load and network statistics.
The behavior of such processes can vary considerably depending on various factors, such
as the computer platform. Itmay also be difficult to prevent an adversary from observing or
manipulating these processes. For instance, if the adversary has a rough idea of when a randomsequencewas
generated, she can guess the content of the system clock at that time with
a high degree of accuracy. A well-designed software random bit generator should utilize as
many good sources of randomness as are available. Using many sources guards against the
possibility of a few of the sources failing, or being observed or manipulated by an adversary.
Each source should be sampled, and the sampled sequences should be combined using
a complex mixing function; one recommended technique for accomplishing this is to apply
a cryptographic hash function such as SHA-1 (Algorithm9.53) orMD5 (Algorithm9.51) to
a concatenation of the sampled sequences. The purpose of the mixing function is to distill
the (true) random bits from the sampled sequences.

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

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

eshpilen

یک شنبه 04 مهر 1389, 19:19 عصر

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

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

یا میگید این خبرگان کیا هستن که میگی.
اگر شما کتاب ذکر شده رو خونده بودید و درک کرده بودید، دیگه این حرف رو نمیزدید، چون واقعا معدود بودن این افراد و خبره بودن اونها به شما ثابت میشد. نیازی به ذکر اسم هم نیست، ولی اگر اسم میخواید توی اون کتاب اسم افراد خبره زیاد اومده. نویسندگان خود کتاب هم مسلما جزو این خبرگان محسوب میشن.
درمورد منابع مورد مطالعهء بنده فرمودید و اینکه چقدر و چیا هست. خب باید بگم آمارش دستم نیست ولی میدونم که خیلی زیاد بوده، چون بجز این کتاب مقاله های بسیاری از ویکیپدیا در مقولهء رمزنگاری رو خوندم. گهگاهی هم مقاله از سایتهای دیگه رو. یه مقاله ای که میخونم، گاهی میرم توی لینکهایی که در متنش اومده و باز از توی مقالاتی که اون لینکها باز میکنن میرم به لینک های دیگه و همینطور گاهی تا چند سطح پایین میرم (دقیقا مثل پیاده سازی تابع recursive) و میبینی بعد از یکی دو ساعت یا حتی بیشتر تازه برمیگردم به مکان اولیه تا اونجایی که در مقالهء اصلی خونده بودم. یعنی از هیچ مطلب مهم و موثری نمیگذرم. ضمنا بله سن من احتمالا از شما حداقل شش هفت سالی بیشتر هست و از طرف دیگه وقت آزاد هم زیاد داشته و دارم و چون خورهء مطالعه و شیفتهء علم هستم، بخش بزرگی از 24 ساعت رو در طی سالها درحال مطالعهء مطالب تخصصی و علمی بودم.
اون زبانهایی هم که در پروفایلم نوشتم، حداقل رفرنس رسمی و مثال و تمرین هرچی داشته خوندم و انجام دادم. در بعضیاش هم پروژه های کوچکی انجام دادم.
شما میگید نقش مطالعه در برنامه نویسی 10%. من میگم نه حداقل 50%. تازه این بصورت میانگین در تمام زمینه های برنامه نویسی هست، وگرنه در چیزایی مثل Cryptography میگم حداقل 80% هست. چون اینطور چیزا همش ریاضیات و تئوری هست و پیاده سازی بدون پایه و تحلیل تئوری هیچی نیست و اغلب اطلاعات کاملی نمیده و با آزمون و خطای صرف هم نمیشه خیلی چیزها رو در این زمینه فهمید و تحلیل کرد.
نقش تئوری و ریاضیات رو هرگز دست کم نگیرید. مثلا در فیزیک با نوابغی مثل انیشتین، به کمک ریاضی و تئوری پردازی بود که بزرگترین و مهمترین حقایق و نظریه ها متولد شدن که کاربردهای شگفت انگیز اونها هم کاملا مشهود هست. شاید هیچوقت یا حداقل ده ها سال بعد، فیزیک تجربی تازه میتونست به بخشی از این دستاوردها برسه.
برنامه نویسی هم بنظر من واقعا کدنویسی و مطالعهء تئوری و الگوریتمش اونقدری با هم تفاوت نداره. هردو لازم هستن، اما اتفاقا برخلاف خیلی رشته ها که پیاده سازی عملی اونها خیلی فیزیکی و متغییر و غیرقابل پیشبینی هست و چیزای زیادی داره که در تئوری و مطالعهء فرد نبودن، در برنامه نویسی بیشتر چیزای مهم رو میشه با تئوری و مطالعه فهمید. فقط برای نهایی و کامل کردن تمام جزییات لازم و افزایش مهارت عملی و بعضی از چیزایی که خارج از خود برنامه نویسی نیاز هستن، نیاز به کدزنی داریم.
حالا یه آدمی شاید تئوری رو خوب و کامل نفهمیده یا تنبلیش میاد کار کنه (چون خشک و خسته کننده هست)، یا اینکه مثلا با کار عملی راحتتر یاد میگیره، این دلیل نمیشه برای همه اینطور باشه. اونی که قدرت یا علاقه و انگیزه و اراده رو داره تئوری رو مطالعه و درک کنه و به کار بگیره، میتونه ظرف 5 سال از اونایی که 15 سال تجربهء عملی برنامه نویسی دارن، قابلیت های علمی بیشتری داشته باشه. اینکه میگم علمی، چون بعضی چیزها دیگه جزو خود برنامه نویسی و چندان علمی نیستن و با تجربهء عملی بدست میان. خیلی کارها در خیلی برنامه نویسی ها هم که تکراری هستن و از نظر تئوریک پیچیدگی و حجم برجسته ای ندارن، بنابراین خیلی ها میتونن با دانش تئوریک کمتر خیلی برنامه ها رو هم بنویسن. این توهین یا منظور به شخص خاصی نیست اصلا، صرفا بیان یک واقعیته از دید من! حالا کسی میخواد خوشش بیاد یا نیاد یا منو خودپرست فرض کنه که میخوام خودم رو مطرح کنم. اما منظور من بیان واقعیات بوده و تبادل نظر با دیگران در اینمورد برای محک زدن سطح و درستی دانش و مهارت و تفکر خودم. ضمنا آدم لازم باشه باید واقعیت رو درمورد خودش هم بیان بکنه. مثلا من اگر بخوام برم یجا استخدام بشم که چند نفر دیگه هم متقاضی داره، مسلما نقاط قوت خودم رو در این رقابت مطرح میکنم و اگر احساس کنم متقاضی های دیگه در اون زمینه ها ضعیف تر از من هستن ممکنه اونا رو به چالش بکشم و به مبارزه دعوت کنم. چون این کار از نظر اخلاقی بنظرم مشکلی نداره و کاری هست که در شرایط ذکر شده میتونه از نظر عقلانی لازم باشه. بالاخره آدم باید توانایی های خودش رو مطرح و ازشون در عمل استفاده کنه یا نه!؟