نیاز به salt در الگوریتمهای هش non-deterministic

سلام.
من قبلا از الگوریتمهایی مثل md5 و sha برای هش کردن پسورد استفاده میکردم، با salt و اینطور داستان‌ها (یه وقتایی salt یکپارچه و یه وقتایی saltهایی که برای هر کاربر مجزا ساخته میشه)

برای پروژه‌ای که الآن روش کار میکنم، تصمیم گرفتم از الگوریتم scrypt استفاده کنم چون ادعا میکردن که هزینه‌ی سخت‌افزاری که کرکش کنه خیلی بالاست.

هزینه‌ی کرک الگوریتم scrypt

همیشه اینطور فکر میکردم که هش‌ها باید deterministic باشن. یعنی هر زمان که یه استرینگ رو وارد الگوریتم میکنیم و یه هش میگیریم، اگه دوباره همون استرینگ رو بهش دادیم دوباره همون هش رو دریافت کنیم.
ولی درمورد scrypt (و bcrypt) یه کم قضیه فرق میکنه.
مثل اینکه خودش به دیتای ما salt اضافه میکنه.

آیا این salt برای امنیت پسوردها کافیه؟ یا باز‌هم نیاز هست خودمون salt اضافه کنیم؟
سوال دوم اینه که موقع verify، از کجا میفهمه که چه saltی استفاده کرده؟ هربار فرق میکنه! (فکر میکنم یه تعداد زیادی salt داره که هر بار به صورت رندم یکی رو انتخاب میکنه و موقع تست کردن همه رو تست میکنه ببینه کدوم درسته)

1 Like

اینکه از یک secret key برای همه پسوورد ها استفاده کنیم میتونه خیلی خطرناک باشه چون احتمال پیدا کردن پسوورد های دیگه رو بالا میبره، مثلا اگر پسورد شما ۱۲۳۴۵۶ باشه و secret همه یکسان باشه خب اگر شما به db دسترسی پیدا کنید در اون صورت میتونید ببینید که پسورد شما در حالت انکریپت شده چیه و خب هر پسورد دیگه ای که شبیه پسوورد شما باشه یعنی ۱۲۳۴۵۶ هست.
اما در متد salt هر پسوورد salt خودشو داره که با پسوورد ذخیره میشه و عموما بخشی از پسوورده، مثلا ۱۶ کرکتر اول و پروسه ای که پسورد رو مچ میکنه میدونه که چه قسمتی از هش پسورد هست و چه قسمتی salt. این باعث میشه که هیچ جوری نشه پسوورد رو حدس زد

2 Likes

بله. این مساله رو میدونستم و البته منظورم از salt یکسان، در حقیقت «روش ساخت salt یکسان» بود.
من یه استرینگ ثابت داشتم که با نام کاربری و پسورد قاطی میکردم و هش میساختم. اینطوری اگه دو نفر پسوردشون یکسان بود، هش یکسانی توی دیتابیس نداشتن.

سوال من بیشتر درمورد روش کارکرد scrypt بود.
میخوام بدونم میشه بهش اعتماد کرد و اصلا salt اضافه نکرد؟
و البته میخوام بدونم دقیقا چیکار میکنه و این saltی که خودش اضافه میکنه رو چطوری به دست میاره که دوباره بتونه موقع verifyکردن ازش استفاده کنه؟

بالا همینو عرض کردم، salt بخشی از پسوورد هش شدست

1 Like

آهان. پس هش رو به استرینگ اضافه میکنه و مجموع اینا رو هش میکنه، بعد هش شده‌ی پسورد رو میچسبونه به salt و کلشو میده بهم.
مرسی!

1 Like

به همین سادگی.
اون توضیح دلیل salt هم برای شما نبود، کلا گفتم که اگر کسی نمیدونست ببینه داستان چیه

1 Like

احتمالا اینجا با ==$ جدا شده باشه.

$s0$f0801$EwiZ+CTAXPNT2GOzNjH0bg==$CWN72Lw29HleRnJRoEeS2VMU02qs3kRIs0qEg+gHK2A=
$s0$f0801$JSVCshxDK/L50kQX+zHHGA==$FTfzQ7OhBUXRCbz//Bp1fF0PEh5EViosQ8N8fwxqVLU=

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

1 Like

آره.
مثل اینکه چندتا قسمت داره که با $ از هم جدا شدن. احتمالا برای مشخص کردن ورژن الگوریتم هم باشه.

من روی پروژه ای کار میکردم که از scrypt استفاده میشد و هر پسوورد یک فیلد salt هم‌ کنارش داشت یعنی salt یه فیلد توی دیتابیس بود، برای همین لازمه که دقیقا بدونی داری چکار می کنی

1 Like