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

[eshpilen]

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

امن ترین راه حل این مسئله تاجاییکه میدونم تاحالا استفاده از HTTPS بوده. ولی HTTPS هزینه ها و امکانات خاصی رو میخواد و پردازش و منابع بیشتری رو در هر دو سمت کلاینت و سرور مصرف میکنه و کندتره، و شاید به همین دلیل درکل بیشتر سایتهای اینترنت از HTTP استفاده میکنن و نه HTTPS.

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

[eshpilen]

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

[rezakho]

اگر خیلی اسرار به این کار داری می تونی پروتوکل SSL را خودت با یک الگوریتم درهم سازی نامتقارن شبیه سازی کنی :)
البته مشکلات خاص خودش رو داره.

[Reza1607]

مي توني قبل از ارسال رمز اون رو با جاوااسكريبت هش كني و بعد ارسال كني

[eshpilen]

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

[eshpilen]

مي توني قبل از ارسال رمز اون رو با جاوااسكريبت هش كني و بعد ارسال كني دقیقا چطوری یعنی؟ میتونی مثالی بزنی؟

[Reza1607]

دقیقا چطوری یعنی؟ میتونی مثالی بزنی؟


www.webtoolkit.info/javascript-md5.html

[eshpilen]

ممنون.
یعنی میگی پسورد رو در سمت کلاینت md5 و ارسال میکنیم و سمت سرور هم همون هش md5 پسورد که موقع ثبت نام در دیتابیس ذخیره شده با این هش مقایسه میشه؟

[Reza1607]

شما سمت كلاينت رمز رو هش ميكنيد بعد براي جك كردن اين رشته رو مستقيم با اون رشته اي كه در db‏ ذخيره كردين مقايسه مي كنيد

[eshpilen]

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

[Reza1607]

تا حالا به اين موضوع فكر نكرده بودم
ممنون

[idocsidocs]

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

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

در کل اگر کسی جاوا اسکریپت رو غیرفعال کنه اصلا نمی تونه با این روش لاگین کنه !

[Unique]

در کل اگر کسی جاوا اسکریپت رو غیرفعال کنه اصلا نمی تونه با این روش لاگین کنه !

کسی که جاوا اسکریپت را غیر فعال میکنه بهتره اصلا توی وب نیاد ! چون توی msn یا yahoo یا gmail هم نمیتونه وارد بشه !
متاسفانه ما برنامه نویسان ایرانی خیلی کاربر ها را لوس میکنیم ! اگه همه IE6 را فراموش میکردیم الان بیش از 70 یا 80 درصد کاربرای ایرانی از این IE6 مزخرف ، فاجعه بی در و پیکر استفاده نمی کردند !
حالا هم بی خیال کاربری که javascript را غیر فعال میکنه یا کلا Browser اون مشکل داره ! اصلا بهتره توی اینترنت پاشو نگذاره ! (این نظر شخصیه منه)

در رابطه با hash هم چرا شما اشتباه مکینید ! ، بجای md5 کردن سمت سرور روی browser با javascript تبدیل به md5 hash بکنید ! اینجوری کسی نمیدونه رشته اولیه چی بوده !

[idocsidocs]

در رابطه با hash هم چرا شما اشتباه مکینید ! ، بجای md5 کردن سمت سرور روی browser با javascript تبدیل به md5 hash بکنید ! اینجوری کسی نمیدونه رشته اولیه چی بوده !
خب اگر از سالت استفاده نکنیم، می شه کلمه رمز رو حدس زد. یه سری ابزار در این رابطه هست که با دادن کد هش، کلمه اصلی رو برمی گردونن. اگر رشته سالت رو بزاریم توی کد جاوا اسکریپت، راحت لو می ره. به همین دلیل باید توی سرور رشته سالت رو هم اضافه کنیم.

[rezakho]

SSL که درهم سازی نیست. SSL خیلی پیشرفته هست و کلی حساب و کتاب داره. از الگوریتمهای نامتقارن مثل RSA و گواهینامه های دیجیتال و این حرفا استفاده میکنه.
ببخشید، با عجله نوشته بودم، دقت نکردم، منظورم همین RSA هست، اگر از md5 یا دیگر الگوریتم های مثل این استفاده کنی، نفوذگر با تحلیل کدهای جاوااسکریپت سایتت می فهمه که با کدام الگوریتم پسوردت رو مخفی کردی، ولی با RSA بدون داشتن کلید خصوصی عملا کشف رمز غیر ممکنه
اینم یه مثال با جاوااسکریپت :)
http://ohdave.com/rsa/

[eshpilen]

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

سیستم بنده: CPU 2.5 GHz RAM 1 GB

[Unique]

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

hash های md5 را نمیشه Reverse کرد ! اونی که شما میشناسی یکسری نرم افزار Brut Force هست که با مقایسه ها پسورد را حدس میزنن البته باید کاربر خیلی پسورد آبکی انتخاب کرده باشه که میشه با مجبور کردنش به حداقل 6 یا 8 کاراکتر و استفاده از حروف کوچک و بزرگ و عدد و کاراکتر هایی نظیر * و $ و # امکان حدس را تقریبا محال کرد !

[eshpilen]

من میخواستم به نتیجهء کاملی برسم تا یک روش جالبی رو براتون معرفی کنم.
این روش اسمش Challenge-Response هست. البته این یه اسم کلی برای اصول پایهء چنین الگوریتم هایی هست.

در «این صفحه (http://pajhome.org.uk/crypt/md5/auth.html)» یک روش از این نوع معرفی شده. در بخش Adding MD5 to an Authentication System توضیح داده.
ضمنا این روشی که در این صفحه معرفی کرده ظاهرا نسخهء قدیمی ولی متداول بوده که ضعفهای امنیتی قابل توجهی داره که خودش در بخش Risks لیست کرده.

روش دیگه ای رو در «این صفحه (http://pajhome.org.uk/crypt/md5/advancedauth.html)» معرفی کرده تحت عنوان Alternative System که با قبلی شباهت داره اما حساب شده تر و پیشرفته تره و بیشتر ضعفهای روش قبلی رو برطرف کرده (فقط یک مورد رو نتونسته حل کنه).

البته باید به این نکته هم توجه داشته باشید که این روش صرفا مراحل احراز هویت در فرایند ثبت نام و لاگین دستی رو امن میکنه. اما مثلا سشن ها و کوکی هایی که برای احراز هویت خودکار، بعد از لاگین دستی به کلاینت ارسال میشن (سیستم سشن هم یک کوکی محتوی سشن آیدی رو ارسال میکنه) به شکل مشابهی مانند پسورد قابل استراق سمع هستن و هکر میتونه با بدست آوردن اونها بجای کاربر لاگین کنه. بنابراین برای امنیت واقعی باید این موارد رو هم بوسیلهء سیستم مشابهی امن کرد. در همون منبعی که دادم در این مورد روشی (http://pajhome.org.uk/crypt/md5/advancedauth.html#sessionid) رو پیشنهاد کرده.

[rezakho]

بابا تو دیگه کی هستی :)
از او اول سر کار بیدیم :)

[eshpilen]

نه بابا سرکار نذاشتم.
در واقع این تاپیک مرحلهء اول تحقیقات بنده بود که میخواستم بدونم آیا ایده ای که داشتم (http://forum.iranphp.org/Thread-%D8%A8%D8%B3%DB%8C-%D8%B9%D8%AC%DB%8C%D8%A8-%D9%86%D8%A7%DA%A9-%D9%81%DA%A9%D8%B1-%DA%A9%D9%86%D9%85-%DB%8C%D9%87-%D8%A7%D9%84%DA%AF%D9%88%D8%B1%DB%8C%D8%AA%D9%85-%D8%A7%D8%AE%D8%AA%D8%B1%D8%A7%D8%B9-%DA%A9%D8%B1%D8%AF%D9%85-%D8%AF%D8%B1-%D8%B3%D8%B7%D8%AD-%D8%AC%D9%87%D8%A7%D9%86%DB%8C) قبلا اختراع شده یا نه و یا آلترناتیو بهتری شاید از قبل وجود داشته باشه.
خوشبختانه در فروم دیگر خیلی زود (ولی بعد از تاسیس این تاپیک) مشخص شد که چنین روشی وجود داره و از نظر روش کلی دقیقا همون ایدهء بنده هست.
منتها اگر میخواستم فورا اون روش رو در اینجا مطرح کنم بنظرم جالب نمیشد؛ همه چیز با هم قاطی میشد و احتمالا موارد دیگه و اطلاعات و ایده های دیگر مطرح و روی نقاط ضعف و قوت اونا بحث نمیشد.
بنظرم بهتر شد که رویهء این تاپیک متفاوت با اون یکی بود. اینکه تنوع بوجود آمد باعث دید جامعتری و اطمینان بیشتری شد.

[idocsidocs]

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

[eshpilen]

سابقهء چی؟ اختراع؟
من ندارم. ولی پدر مرحومم 3 تا اختراع صنعتی به ثبت رسوند.
حالا مگه حتما باید سابقهء اختراع داشته باشیم؟!
زیاد مطالعه کنی و زحمت بکشی بالاخره یه روزی ممکنه اختراعی ابتکاری چیزی بکنی.
منم که در زمینهء امنیت و الگوریتم و رمزنگاری زیاد مطالعه داشتم.
البته همونطور که تاحالا به دیگران گفتم، ایده هایی که ما داریم و فکر میکنیم اختراع هستن به احتمال 99.9% قبلا اختراع شدن یا اصلا از اساس اشتباهی در اونهاست/غیرعملی هستن.
تاحالا تقریبا هرچی اختراع بوده که یخورده ساده هم بوده اختراع شده طبیعتا.
بخاطر اینهمه انسان و تحقیقات در طول تاریخ.
الان اختراع بزرگ کردن خیلی سخت تره. چون اختراعات الان باید خیلی پیچیده تر باشن احتمالا.

[idocsidocs]

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

[eshpilen]

اگر ایده ای که توی این تاپک مطرح کردید تکراری هست و ایده شما قبلا اجرا شده، می شه دقیقا بگید که چه چیزی تو ذهنتون بود؟
خب این الگوریتم دیگه: http://pajhome.org.uk/crypt/md5/advancedauth.html#alternative
فقط یخورده جزییاتش فرق داشت.

[Unique]

راستش این کار به نظر من خیلی جالب نیست در زمانی که میشه از ssl استفاده کرد ! خرید ssl ماهی 5 هزار تومان هم هزینه نداره ! و بسیار امن تر از روش ارائه شده است.
به هر حال جالب بود و تا حالا بهش فکر نکرده بودم ! ;)