salt چیست

[abdollah110110]

سلام
لطفا بگویید salt چیست؟
متشکرم

[Keramatifar]

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

[Pro.Graming]

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

[eshpilen]

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

[Pro.Graming]

ایا امکان جدا کردن سالت از هش وجود داره؟

[eshpilen]

یعنی میفرمایید فقط یک هش رو که از ترکیب یک Salt و یک رشتهء دیگه بدست آمده داشته باشیم و بتونیم فقط از روی این هش خروجی، Salt و رشتهء اولیه رو بازیابی کنیم؟

[Pro.Graming]

بله.نمیشه آره؟
در ضمن سالت به این صورت هست که ابتدا با پسورد ترکیب میشه بعد ترکیب این دو پسورد + سالت هش میشه؟
میشه بیشتر توضیح بدید؟
ممنون

[eshpilen]

بله نمیشه. یعنی راه فرمولی و بهینه نداره و فقط میشه از ترفندهای غیرمستقیم که بنظرم در کل نهایتا در دسته بندی Brute force هستن استفاده کرد. این از خواص الگوریتم های هش هست که یک طرفه هستن و تابع معکوس اونها کشف نشده از نظر ریاضی و از تحلیل خروجی هم چیزی از ورودی مشخص نمیشه. بطور مثال از خصوصیات یک الگوریتم هش دارای استحکام Cryptographic این هست که وقتی یک بیت در ورودی اون عوض بشه، وضعیت هر بیت خروجی به احتمال 50% عوض میشه. یعنی بطور متوسط نصف بیت ها عوض میشن، و بیت هایی که عوض میشن قابل پیشبینی نیستن و نمیشه الگوی خاصی رو در اونها با توجه به ورودی کشف کرد.
تا وقتی ضعفی در یک الگوریتم هش کشف نشده و عملا شکسته نشده این خصوصیات وجود دارن.
در الگوریتم هایی مثل MD5 ضعفهای جدی پیدا شده و به همین جهت دیگه استفاده ازشون نهی شده و کوچ به الگوریتم های قویتر خیلی وقته شروع شده (بطور مثال کوچ به SHA256). البته در کاربردهایی مثل ذخیره سازی هش پسورد کاربران در دیتابیس (همراه با Salt) فکر میکنم هنوزم امکان کرک کردن MD5 وجود نداره. مواردی که تونستن MD5 رو به زانو دربیارن در چیزهای دیگری بوده تاجاییکه میدونم (بطور مثال جعل امضاهای دیجیتال). بهرحال این الگوریتم مثل آدمی هست که به تریاک معتاد شده و دیگه بهش اطمینان نیست؛ ممکنه چند وقت دیگش کراکی بشه و فاتحه!!

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

بطور مثال میشه اینطور عمل کرد:

h(h(s|d)|s)
h تابع هش ماست.
s همون Salt هست.
d دیتای اصلی.
و علامت | به معنای الصاق دو رشته.

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

[tux-world]

حالا اگه بخواییم تو PHP یه رشته رو به اینصورتیکه فرمودید رمزنگاری کنیم کد مثالی برای این منظور سراغ دارید ؟ آیا اگه به این صورت عمل کنیم امنیت داده‌ها مون میره بالا ؟

[eshpilen]

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



سلام. چند تا نرم افزار معروف و روش هشينگشون رو برات ميذارم:
وي بي: includes/class_dm_user.pho

/**
* Takes a plain text or singly-md5'd password and returns the hashed version for storage in the database
*
* @param string Plain text or singly-md5'd password
*
* @return string Hashed password
*/
function hash_password($password, $salt)
{
// if the password is not already an md5, md5 it now
if ($password == '')
{
}
else if (!$this->verify_md5($password))
{
$password = md5($password);
}

// hash the md5'd password with the salt
return md5($password . $salt);
}

ماي بي بي inc/function_user.php


/**
* Salts a password based on a supplied salt.
*
* @param string The md5()'ed password.
* @param string The salt.
* @return string The password hash.
*/
function salt_password($password, $salt)
{
return md5(md5($salt).$password);
}
وردپرس: wp-includes/pluggable.php
(به قيافه ي ساده ش نگاه نكن... مفصل تره(سلت و هش رو كنار هم نگه ميداره و با بلو فيش هم انكريپت ميكنه)

/**
* Create a hash (encrypt) of a plain text password.
*
* For integration with other applications, this function can be overwritten to
* instead use the other package password checking algorithm.
*
* @since 2.5
* @global object $wp_hasher PHPass object
* @uses PasswordHash::HashPassword
*
* @param string $password Plain text user password to hash
* @return string The hash string of the password
*/
function wp_hash_password($password) {
global $wp_hasher;

if ( empty($wp_hasher) ) {
require_once( ABSPATH . 'wp-includes/class-phpass.php');
// By default, use the portable hash from phpass
$wp_hasher = new PasswordHash(8, TRUE);
}

return $wp_hasher->HashPassword($password);
}
دروپال :
ام دي فايو ساده (؟) دقيقا نتونستم وقت بذارم روش ولي به نظر ميرسه فقط ام دي فايو ميكنه
ساپرت سوئيت
ام دي فايو ساده:
includes/functions_users.php


*/
function changeUserPassword($userid, $newpassword)
{
global $dbCore;

$dbCore->shutdownQuery("UPDATE `". TABLE_PREFIX ."users` SET `userpassword` = '". md5($newpassword) ."', `userpasswordtxt` = '". $dbCore->escape($newpassword) ."' WHERE `userid` = '". intval($userid) ."';");

return true;
}

علي الحساب فكر كنم بس باشه نه؟:love:

[eshpilen]

روشهاي بالا رو خلاصه میکنم:
ظاهرا وی بی معروف که نرم افزار همین فروم هم هست از چنین روشي استفاده میکنه:

h(h(d)|s)
يعني از پسورد هش گرفته و بعد salt رو به انتهاي هش حاصل شده اضافه كرده و از رشتهء حاصل دوباره هش ميگيره.

فروم ماي بي بي:

h(h(s)|d)
از salt هش گرفته و سپس اين هش رو به ابتداي پسورد اضافه ميكنه و بعد هش رشتهء حاصل رو ميگيره.
يجورايي مشابه از نظر الگوريتم ولي معكوس از نظر پارامترها نسبت به روش وي بي.

روش وردپرس از روي كد دقيقا مشخص نيست. اما اينطور كه گفته هم از salt استفاده ميكنه و هم رمزگذاري ميكنه (رمزگذاري قابل بازگشت با هش كه يك طرفه هست تفاوت ميكنه).

دروپال:

h(d)
ظاهرا هش بدون salt كه بنابراين درمقابل كرك هش كاملا آسيب پذيره. بنابراين كاربرد اين روش در يك نرم افزار معروف جاي پرسش داره. شايد اين روش رو از نسخه هاي خيلي قديمي و اوليه داشته و تاحالا بخاطر Backward compatibility حفظش كرده.

[tux-world]

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


$pw=wp_hash_password('my password');
if ($_POST['pws'] == $pw)
echo'ok';
else
echo'NO';

درسته ؟

[eshpilen]

مثلا با این هش میکنی:

h(h(d)|s)
یعنی مثلا موقع ثبت نام کاربر:

$password_hash=md5(md5($password).$salt)
salt باید یه مقدار رندوم باشه. فقط طولش خیلی کوتاه نباشه. باید طول مناسبش رو دوباره از دوستم بپرسم :لبخند:

بعد شما هش نهایی ($password_hash) و salt رو باید برای هر کاربر در دیتابیس ذخیره کنی.
ما پسورد کاربر رو در سمت سرور ذخیره نمیکنیم. بلکه فقط هش اون رو ذخیره میکنیم (البته همراه با salt ای که برای تولید اون هش استفاده کردیم).

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


$password=$_POST['password'];

$password_hash=fetch_password_hash_for_username_fr om_database();

$salt=fetch_salt_for_username_from_database();

if(md5(md5($password).$salt) == $password_hash)) echo 'Ok.';
else echo 'Wrong!';

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

[tux-world]

ما پسورد کاربر رو در سمت سرور ذخیره نمیکنیم. بلکه فقط هش اون رو ذخیره میکنیم (البته همراه با salt ای که برای تولید اون هش استفاده کردیم).
پس رمز مگه تو دیتابیس ذخیره نمیشه ؟ خوب میشه سمت سرور مگه نه ؟

[eshpilen]

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

[tux-world]

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

[eshpilen]

آره چرا نمیشه!
اینم جواب سوالم (طول salt):


من در مورد طول و توزيع سالت استاندارد خاصي نديدم... فقط به نظر ميرسه كه بايد از چهار پنج كاراكتر بيشتر باشه كه كرك كردنش با ديكشنري ارزش نداشته باشه... نميدونم اگر تحقيق خاصي در اين موردها كلا ديدي منم بدم نمياد بدونم.

[eshpilen]

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

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

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

[MMSHFE]

با سلام، من براي Salt از هش MD5 زمان جاري (time) استفاده ميكنم. اينطوري طولش هميشه 32 كاركتر هست و هش رمز و Salt رو با هم توي يك فيلد ميگذارم (حالا يا اول يا آخر) و به راحتي موقع كار، 32 كاركتر اول يا آخر رو جدا ميكنم و بعنوان Salt استفاده ميكنم و اگه رمز واردشده، بعد از هش بهمراه Salt همون داده موجود در DB رو توليد كرد، يعني رمز درست وارد شده. به نظرتون امنيت اين روش چطوره؟

[tux-world]

می تونین کد این روشی رو که فرمودید رو بذارید ببینیم ؟ میخوام ازش استفاده بکنم ممنون میشم

[eshpilen]

با سلام، من براي Salt از هش MD5 زمان جاري (time) استفاده ميكنم. اينطوري طولش هميشه 32 كاركتر هست و هش رمز و Salt رو با هم توي يك فيلد ميگذارم (حالا يا اول يا آخر) و به راحتي موقع كار، 32 كاركتر اول يا آخر رو جدا ميكنم و بعنوان Salt استفاده ميكنم و اگه رمز واردشده، بعد از هش بهمراه Salt همون داده موجود در DB رو توليد كرد، يعني رمز درست وارد شده. به نظرتون امنيت اين روش چطوره؟
بنظر بنده این روش جالب نیست. چون شما بیخودی روزهء شک دار میگیرید و از نظر تئوریک مقداری از امنیت برنامهء خودتون کم میکنید. نوشتن و استفادهء یک تابعی که salt تصادفی با هر طول دلخواه تولید بکنه مثل آب خوردن هست؛ پس چرا بجاش از عاملی که خصیصهء تصادفی بودن و محدودهء مقادیر ممکن اون کمتر هست استفاده کنیم؟ یک رشتهء رندوم که توسط توابع مخصوص رندوم ایجاد شده از زمان رندوم تر یا درواقع غیرقابل پیشبینی تر هست.
یک مثال تئوریک میزنم از روشهایی که میشه از ضعف این متد سوء استفاده استفاده کرد.
فرضا شما ممکنه برای لاگین خودکار کاربر بیایید این هش رو که با salt تولید شده در کوکی سمت کلاینت ذخیره کنید. خب ظاهرا مشکلی وجود نداره چون تا وقتی کرکر که تونسته به روشی به محتوی کوکی کاربر دسترسی پیدا کنه salt رو هم نمیدونه عملا غیرممکن هست که بتونه اون هش رو کرک کنه. اما چون شما از زمان (بنظرم با رزولیشن درحد ثانیه) برای تولید salt استفاده کردید، کرکر میتونه بعد از پیدا کردن زمان ثبت نام کاربر مورد نظر، یکسری حدسهایی رو که درمورد پسورد کاربر داره بصورت آفلاین با سرعت کافی تست کنه. چون 24 ساعت مجموعا 24*60*60=86400 زمان مختلف داره که با رزولیشن یک ثانیه از هم تفاوت میکنن، کافیه کرکر برنامه ای بنویسه که حدسهای خودش رو با هرکدوم از timestamp های موجود در اون 24 ساعت تست کنه (البته با فرض اطلاع از الگوریتمی که شما بکار بردید). یعنی Brute force میکنه، ولی یک Brute force که میتونه بصورت آفلاین برای تعداد محدودی از حدسها عمل بکنه و اگر یکی از این حدسها درست باشه هش عملا کرک خواهد شد. درحالیکه اگر شما از یک salt تصادفی با طول مناسب استفاده بکنید، چنین حملهء آفلاینی توسط هکر عملا غیرممکن خواهد بود.
کرکر اگر بخواد این حدسها رو بصورت آنلاین تست کنه کارش بسیار دشوارتر خواهد بود و اصلا میشه گفت اگر تعداد حدسها زیاد باشه این کار غیرممکن هست. بخصوص که شما در بخش لاگین سایت خودتون مکانیزمهایی مثل محدودیت زمانی بین وارد کردن اطلاعات لاگین یا قفل شدن IP درصورت چند بار اشتباه وارد شدن پسورد گذشته باشید.
کرکر میتونه حدسهای خودش رو یا یک محدودهء خاص رو که فکر میکنه به احتمال زیاد پسورد کاربر در اون محدوده هست به این روش بصورت خودکار و با سرعت کافی روی یک PC معمولی تست کنه. درسته نمیتونه محدودهء بزرگی رو تست کنه و اگر پسورد کاربر غیرقابل حدس باشه و با طول و استحکام مناسب انتخاب شده باشه عملا کارش غیرممکن میشه، اما اگر ایده ای از پسورد انتخاب شده توسط کاربر داشته باشه و یک محدوده ای رو که بقدر کافی کوچک باشه میتونه خیلی خیلی سریعتر از روش آنلاین تست کنه و این حملهء آفلاین توسط استفادهء شما از زمان بجای یک salt تصادفی ممکن شده.
در حالت آنلاین این کار براش احتمالا صرف نمیکنه چون زمان و منابع بسیار زیادتری باید صرفش کنه.
پس میبینید که استفاده از یک salt که کاملا تصادفی نیست و محدودهء اون قابل محاسبه و خیلی کوچکتر از محدودهء یک salt کاملا تصادفی با طول کافی هست، منجر به ممکن شدن یا راحتتر شدن یکسری از حمله ها میشه. درسته شاید بازهم امنیت در سطح بالایی باشه ظاهرا و این ضعف اینقدر بزرگ نباشه، یا شما بگید اصلا من هش رو در کوکی ذخیره نمیکنم، اما بهرحال شما یک محدودیت رو بدون اینکه هیچ ضرورتی داشته باشه در سیستم خودتون وارد کردید.

بنده شخصا فکر میکنم استفاده از یک salt که طولش و کاراکترهای ممکن اون دقیقا مثل الگوریتم هش استفاده شده باشه، امن ترین حالت ممکنه. یعنی مثلا اگر از MD5 استفاده میکنیم، salt ما یک رشتهء تصادفی 32 کاراکتری از کاراکترهای ممکن 9-0 و A-F باشه.
احتمالا کمتر نرم افزاری salt ای با چنین محدودهء بزرگی داره، ولی بنده با دانش و تحلیل خودم به این نتیجه میرسم؛ و از طرف دیگه میبینم این محکم کاری هیچ ضرر و هزینهء خاصی هم نداره و پیاده سازی اون خیلی راحت هست.

بطور مثال بنده یک تابع نوشتم در یک فایل که هروقت میخوام اینکلود میکنم:

<?php

if(ini_get('register_globals')) exit("<center><h3>Error: Turn that damned register globals off!</h3></center>");
if(!isset($parent_page)) exit("<center><h3>Error: Direct access denied!</h3></center>");

function random_string($chars, $length) {

$random_string='';
for($i=0; $i<$length; $i++) $random_string.=$chars[mt_rand(0, strlen($chars)-1)];

return $random_string;
}

?>

طرز استفاده هم مثلا اینطور هست:

$loginkey=random_string('ABCDEFGHIJKLMNOPQRSTUVWXY Zabcdefghijklmnopqrstuvwxyz0123456789', 64);
یعنی کاراکترهای ممکن و طول دلخواه رو بهش میدم و برام یه رشتهء تصادفی با اون خصوصیات رو میسازه.
البته برای نیاز ما میشه از این خیلی ساده تر هم نوشت و مثلا کاراکترهای ممکن و طول رو به داخل فایل تعریف تابع برد و مثلا یک مقدار پیشفرض از 32 کاراکتر موجود در MD5 رو داشته باشه و بنابراین بتونیم به این سادگی ازش استفاده کنیم:

$salt=random_string();

[tux-world]

register_globals مگه باید فعال باشه؟ این تو اکثر سرورها غیرفعاله و این که منظورتون از $parent_page چیه ؟ و چطوری مقدار دهی میشه که بفهمه آدرس به صورت پله ای مراجعه شده و به اینجا رسیده و نخواسته سایت رو دور بزنه ؟

[MMSHFE]

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

[eshpilen]

با سلام، دوست گرامي من براي توليد Salt از هش زمان برحسب ميلي ثانيه استفاده ميكنم كه به ندرت براي دو كاربر تكراري در مياد (يعني دو كاربر در حد هزارم ثانيه همزمان به سرور وصل بشن).
تكراري شدنش اصلا بحث ما نبود و ارتباطي به ضعفي كه گفتم نداره.



ضمناً اين روش از تعريف تابع توسط خودمون سريعتره چون فقط از يك تابع استفاده ميشه ولي در تعريف تابع خودمون، حداقل چند دستور PHP رو فراخواني خواهيم كرد.در مسئلهء مهم امنيت، چنتا دستور و پراسس اضافه و چند ميلي ثانيه سرعت بيشتر هيچ اهميتي ندارن.
اول بايد امنيت رو تامين كرد، بعد به فكر بهينه سازي سرعت بود. تازه اونم درصورتي كه از نظر سرعت واقعا مشكل داشتيم.


بعلاوه هكر نميدونه كه Salt كجاي رشته است (ممكنه از كاركتر پنجم يا دهم به بعد گذاشته باشم) و درنتيجه نميدونه Salt رو چطور جدا كنه ولي كدي كه خودم توليد كردم اين رو ميدونه! لذا به راحتي Salt رو جدا ميكنه و رمز رو هش ميكنه و دوباره Salt رو در محل موردنظر درج ميكنه و اگه همون كد موجود در DB توليد شد، رمز رو معتبر ميدونه. كدش رو هم ظرف همين يكي دو روز براتون ميگذارم.حتما ميدونيد Security through obscurity (http://en.wikipedia.org/wiki/Security_through_obscurity) چي هست و چرا غلطه. اونم وقتي هيچ اجبار و هزينهء خاصي دركار نيست كه بخوايد به اين عامل اتكا كنيد؛ پس 100% درست نيست.

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

[tux-world]

eshpilen عزیز حالا استفاده از اون توابعی که فرمودید با طول رشته ای دوستتون مرقوم فرمودن و تو وردپرس هم ازش استفاده میشه به نظرتون امنیتی حداقل نسبی رو داره ؟

[eshpilen]

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

[MMSHFE]

با سلام، يك مورد ديگه هم كه به نظرم مياد در بحث امنيت ازش استفاده كنيم اينه كه با استفاده از اطلاعات Referer، بررسي كنيم كه اطلاعات براي فرم ازطريق فرم خود سايت ارسال شده باشن تا اينطوري جلوي فرمهايي كه در سايتهاي ديگه درست شدن و اطلاعات رو براي صفحه ما ارسال ميكنن بگيريم. البته ميدونم به موضوع بحث زياد ربط نداره ولي چون موضوع امنيت هست، اين مورد هم به نظرم خوب هست كه رعايت بشه.
موفق و مؤيد باشيد.

[tux-world]

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

function quote_smart($value)
{
$val=htmlspecialchars(stripslashes($value), ENT_QUOTES);
if(!is_numeric($value))
{
if(get_magic_quotes_gpc()) $value = stripslashes($value);
return "'" .mysql_real_escape_string($value) . "'";
}
else return $value;
}
و این تابع :

mysql_real_escape_string
این خط هم درست کار نمیکنه ببخشید که تو جای خوبش نگقتم:

<input class="button_red" style="width:153px;margin-top:25px;" type="button" id="submit" onclick="<?php xmlhttpPost(\"http://\".$_SERVER[\"HTTP_HOST\"]. \"validate.php\"); ?>" value="ورود به سایت" >

[payam-nice]

باسلام

$pass = md5(md5($password).$email);
من برای کد کردن رمز از این روش استفاده می کنم به نظرتون درست هست یا نه ؟