دلیل Hash کردن Password سمت Server ؟!

[A.S.Roma]

سلام ... .

تا الان هر نمونه کدی دیدم ، برنامه نویسان فیلد password را به صورت Hash شده در دیتابیس ذخیره می کنند و عملیات Hashing رو سمت سرور انجام میدهند .

دلیل این کار چیه !؟

چون عملا" ما داریم Password رو به صورت PlainText به سرور ارسال می کنیم .

بهتر نیست سمت کلاینت این کار را انجام بدیم !؟ ( من تا به حال چنین مدلی ندیدم که کسی استفاده کند جز یک مورد که با عث شد این تاپیک رو بزنم و نظر دوستان دیگر را نیز جویا شوم )

[مهدی کرامتی]

فرض کنید بخواهید عمل فوق را سمت کلاینت انجام دهید. با توجه به این که پست شدن فرم ها در ASP.NET تحت اختیار ما نیست عمل فوق را در چه مرحله ای و چگونه می خواهید انجام دهید؟

همچنین انجام عمل فوق سمت کلاینت چه مزیتی دارد؟

[Javad_Darvish_Amiry]

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

[A.S.Roma]

فرض کنید بخواهید عمل فوق را سمت کلاینت انجام دهید. با توجه به این که پست شدن فرم ها در ASP.NET تحت اختیار ما نیست عمل فوق را در چه مرحله ای و چگونه می خواهید انجام دهید؟

همچنین انجام عمل فوق سمت کلاینت چه مزیتی دارد؟
یک Function در جاوااسکریپ برای Encrypt می نویسیم و قبل از Post مقادیر به سرور آنها را توسط آن تابع Hash می کنیم.
مزیت این روش اینه که در حین ارسال داده به سرور اگر کسی به دیتا دسترسی پیدا کرد دیتای Hash شده را در اختیار داشته باشد .

[A.S.Roma]

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

قرار نیست از متدهای رمزنگاری برگشت پذیر استفاده بشه .

اصولا" Hashing غیرقابل برگشته .
یعنی شما می تونید الگوریتم و خروجی را داشته باشید اما نمی تونید با آن دو به ورودی دسترسی پیدا کنید.

در مورد دسترسی هکر به بانک ؛
شخصی که User/Pass هاست یا DB رو داره پسورد یوزر به چه دردش می خوره وقتی کل دیتابیس رو در اختیار داره ؟!

[Javad_Darvish_Amiry]

قرار نیست از متدهای رمزنگاری برگشت پذیر استفاده بشه .
اصولا" Hashing غیرقابل برگشته .

سلام و مرثی از نکته ای که فرمودید. اما من برای این وضعیت هم یه مثال ساده بالا آوردم. توجه بفرمایید:


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

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

شخصی که User/Pass هاست یا DB رو داره پسورد یوزر به چه دردش می خوره وقتی کل دیتابیس رو در اختیار داره ؟!
خوب اگه سایت استاتیک باشه و تغییر در محتویات از سرور امکان پذیر باشه حق با شماست. اما از یه طرف عملا سایتای اینجوری که ارزش هک کردن هم داشته باشن واقعا دیگه نیستن -عرض کردم سایت استاتیک که ارزش هک داشته باشه؛ وگرنه که خوب زیادن-. از طرف دیگه تو یه سایت داینامیک که محتویات تماما از بانک خونده میشن الزاما باید دستکاری داده تو بانک صورت بگیره و برای این کار مثلا نیاز به یوز پسوورد مدیر هست. چون خرابکاری فقط نفوذ به سیستم نیست. خیلی وقتها دزدی اطلاعات و خیلی وقتهای دیگه -که مهمترین بخش هک رو در بر میگیره- تغییر داده ها هست. لاگر های قدرتمند اجازه تغییر مخفیانه بانک رو نمیدن. ولی اگه من با نام مدیر وارد سیستم بشم خیلی راحت تر میتونم به صورت مخفیانه کارم رو انجام بدم. این یه مثال بود. نه اینکه منظورم اینه که اول و آخر همینه نه. یه مثال بود فقط. نمونه دیگه میتونه دسترسی به حساب های پولی و سرمایه ای باشه. انتقال وجه از یه حساب به حساب دیگه از توی بانک و به طور مستقیم به هیچ عنوان امکان پذیر نیست -مثلا به خاطر سیستم های مدیریت تراکنش چه در سطح بانک چه در سطح کاربرد و چه در سطح سرویس ها که یه انتقال ساده وجه باید تو nتا جدول ثبت بشه و چندتاشون هم ممکنه رو یه سرور دیگه یا تو یه بانک دیگه باشن که اونوقت من باید اونا رو هم هک کنم و خوب این کار خیلی دردسرسازه::- اما اگه من مشخصات اکانت شما رو داشته باشم به راحتی میتونم وارد حسابتون بشم و وجه رو به هر حساب دیگه ای انتقال بدم.
(نمونه این وضعیت چند ماه پیش برای یکی از سایت های تجاری تو ایران پیش اومد. یه بنده خدایی با داشتن یوزر و پس مدیر وارد میشد و عکس های سایت رو با عکس های ناجور عوض میکرد. عکس ها تو بانک ذخیره شده بودن و طبیعتا دسترسی به بانک لازم بود. هر چند این مورد خیلی پیچیده نبوده و میشد با داشتن رمز بانک هم این کارو کرد اما به هر حال ایشون با نام کاربری مدیر اینکارو میکرد.این وضعیت حدود ۵ هفته ادامه داشت تا اینکه فهمیدن اشکال کار کجاست و درستش کردن. -البته اشکالات کار چون راههای رخنه تو سایت مذکور زیاد بود اما چون بی مناسبت به مطلب مورد بحث نبود ذکر کردم.-)
در کنار اینها هیچوقت دیده نشده که تو یه سایت مثلا تجاری یا مالی برای تراکنش های سرمایه بیان و دیتا رو با جاوااسکریپت هش کنن و همیشه https آخرین راه چاره ای بوده -تا اینجا- که به ذهنشون رسیده (مگه این که فکر کنیم عقلشون به رمزنگاری با جاوااسکریپت برگشت پذیر یا ناپذیر نرسیده باشه -اینو شوخی کردم محض لبخند :چشمک:-). هر چند این هم خیلی جوابگو نبوده و به هر حال برادران هکر کماکان تازندگان بی بدیل و بی رقیب شبکه ها به حساب میان اما خوب از هیچی بهتر بوده. ممنون از لطفتون. موفق باشید.

[aserfg]

فرض کنید بخواهید عمل فوق را سمت کلاینت انجام دهید. با توجه به این که پست شدن فرم ها در ASP.NET تحت اختیار ما نیست عمل فوق را در چه مرحله ای و چگونه می خواهید انجام دهید؟

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