هش کردن پسورد روی کلاینت قبل از ارسال و در نتیجه عدم امکان ولیدیت کردن پسورد

[eshpilen]

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

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

میخواستم بدونم نظر شما چیه؟
بنظرتون ولیدیت سمت سرور پسورد واجب تره یا اینکه پسورد رو روی کلاینت هش کنم و ولیدیت سمت سرور رو بیخیال بشم؟

[amin1softco]

عزیزم باید یک کدر بنویسی که خودت بلد باشی قبلاً بحث شده بود فک کنم.
بعد با php اونور دیکدش کن و سپس هش کن و بریز داخل پایگاه
اصولیش فک کنم اینجوریه
http://ntt.cc/2008/01/19/base64-enco...avascript.html
http://mwop.net/blog/133-PHP-decodin...mponent-values

[farhadfery]

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

به نظر من بستگی داره این روش شما روی چه سایتی اعمال می شه. یکجایی هست که اطلاعات خیلی مهم و لو رفتن رمز کاربر (رمز ساده بگذاره) ضرر به کل مجموعه می زنه. اونجا نمی شه گفت که به ضرر خود کاربر و فکر می کنم راه حلی که در بالا جناب امیر گفتند مناسب باشه. اما در یک سایت دیگه یکجایی که رمز کاربر برای خود اون مهم => در صئرت عدم رعابت معیارهای رمز مناسب ,خوب بگذار دودش تو چشم خودش بره.

در مورد کدر هم که آقا امیر می گه به نظر من باید جند تا کدر داشته باشید که هرچند وقت یکبار جا به جا بشند.

[eshpilen]

عزیزم باید یک کدر بنویسی که خودت بلد باشی قبلاً بحث شده بود فک کنم.
بعد با php اونور دیکدش کن و سپس هش کن و بریز داخل پایگاه
اصولیش فک کنم اینجوریه
http://ntt.cc/2008/01/19/base64-enco...avascript.html
http://mwop.net/blog/133-PHP-decodin...mponent-values

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

[amin1softco]

یک کدر بنویسی

این قسمت نگفته شما حتماً باید از base64 استفاده کنید اون لینکم یک مثال بود در مثال هم مناقشه نیست ماشالا چیزی که فراوون یافت می شه و می تونید بنویسید یک انکدر جدیده که کاملاً می تونه مختص خودتون باشه و به قول دوستمون farhadfery می تونید از چندتا انکدر استفاده کنید و اگر از الگوریتم هایه فشرده سازی استفاده کنید خیلی بهتره تازه در کتاب اصول امنیت سیستمها روش هایه زیادی رو توضیح داده اگر خیلی مایل هستید می تونید از روش های کلید عمومی و خصوصی توضیح داده شده یکیش رو پیاده کنید. و ازش استفاده کنید. این روشی که من گفتم یک راه ساده و سر راست بود که امنیت نسبی رو تأمین می کنه .

ولی خوب اگه دوست دارید بازم حرفه ایی تر بشه می تونید مشخصات کاربر رو دریافت کنید مثلاً ip بعد با تابع هش براش یک کلید درست کنید و در ثابت های جاوا براش ارسال کنید (یا از طریق آجاکس) بعد ip رو با تابع هش در یک جدول مثلاً session ذخیره کنید.
طرف کلاینت این کلید + پسورد با تابع base64 جاوا اسکریپت کد می شه و برای سرور ارسال می شه اونجا اول با base64 دیکدش کنید بعد هش متعلق به ip طرف رو از دیتابیس استخراج می کنید و داده را از هش جدا می کنید.
البته پیچ و تابش دیگه دسته خودتونه و یک اسنیفر خیلی باید با سورس شما آشنا باشه که بتونه دیکد کردن رو انجام بده. این اصول کاره ولی هر کسی به روشی می تونه این کار رو انجام بده دیگه نهایتش استفاده از https که این کار ها رو لازم نداره
پ.ن : کلید+پسورد می تونه مثلاً xor بیت ها یا همچین کاری باشه بستگی به سلیقه خودتون و توابع معروف رمزگذاری.

[farhadfery]

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

[eshpilen]

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

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

و به قول دوستمون farhadfery می تونید از چندتا انکدر استفاده کنید

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

اگر خیلی مایل هستید می تونید از روش های کلید عمومی و خصوصی توضیح داده شده یکیش رو پیاده کنید. و ازش استفاده کنید.

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

این روشی که من گفتم یک راه ساده و سر راست بود که امنیت نسبی رو تأمین می کنه .

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

ولی خوب اگه دوست دارید بازم حرفه ایی تر بشه می تونید مشخصات کاربر رو دریافت کنید مثلاً ip بعد با تابع هش براش یک کلید درست کنید و در ثابت های جاوا براش ارسال کنید (یا از طریق آجاکس) بعد ip رو با تابع هش در یک جدول مثلاً session ذخیره کنید.
طرف کلاینت این کلید + پسورد با تابع base64 جاوا اسکریپت کد می شه و برای سرور ارسال می شه اونجا اول با base64 دیکدش کنید بعد هش متعلق به ip طرف رو از دیتابیس استخراج می کنید و داده را از هش جدا می کنید.

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

البته پیچ و تابش دیگه دسته خودتونه و یک اسنیفر خیلی باید با سورس شما آشنا باشه که بتونه دیکد کردن رو انجام بده. این اصول کاره ولی هر کسی به روشی می تونه این کار رو انجام بده دیگه نهایتش استفاده از https که این کار ها رو لازم نداره

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

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

[AmirSky]

فرضا Base64 چه امنیتی میده؟! کسی که ترافیک رو مانیتور کنه میتونه براحتی اون رو دیکد کنه.

یعنی امنیت Base64 اینقدر پایینه؟

بعد وقتی انکودر در سمت کلاینت باشه خوب هرکسی میتونه به الگوریتم دسترسی داشته باشه

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

[eshpilen]

یعنی امنیت Base64 اینقدر پایینه؟

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

بعد وقتی انکودر در سمت کلاینت باشه خوب هرکسی میتونه به الگوریتم دسترسی داشته باشه

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

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

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

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

دیشب سیستم هش سمت کلاینت رو به تمام فیلدهای پسورد در تمام فرمهای برنامم اضافه کردم.
اینم یک نمونه ازش در فرم ثبت نام:

document.register_form.repass.value=document.regis  ter_form.password.value=site_salt+'-'+hex_sha256(site_salt+document.register_form.pass  word.value);

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

[AmirSky]

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

برای کد های سمت سرور چی؟ به چه شکل قراره پسورد چک بشه؟ آیا قصد داری همون پسوردی که از سمت کلاینت ارسال میشه رو در دیتابیس ذخیره کنی؟

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

درعوض Base64 شما چه الگوریتم برگشت پذیری رو پیشنهاد میکنید؟

[eshpilen]

برای کد های سمت سرور چی؟ به چه شکل قراره پسورد چک بشه؟ آیا قصد داری همون پسوردی که از سمت کلاینت ارسال میشه رو در دیتابیس ذخیره کنی؟

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

if(strpos($_POST['password'], $site_salt)!==0) $_POST['password']=$site_salt.'-'.hash('sha256', $site_salt.$_POST['password']);

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

درعوض Base64 شما چه الگوریتم برگشت پذیری رو پیشنهاد میکنید؟

در مورد موضوع این تاپیک که الگوریتم های برگشت پذیر متقارن کاربردی ندارن. نامتقارن هم مثلا RSA میتونه باشه که البته گفتم بخاطر کندی و سنگین بودنش در سمت کلاینت، ازش استفاده نکردم.

اما اگر سوال کلی است و میگید برای رمزگذاری برگشت پذیر بطور کلی از چه الگوریتم هایی استفاده کنیم، در بین انواع متقارن خب AES که معرف همگانه و تقریبا همه جا در هر زبانی هم پیدا میشه (حتی تاجاییکه یادمه پیاده سازی جاوااسکریپت هم داره). البته الگوریتم های دیگه مثل 3DES و Twofish هم هستن.
برای کاربردهای با امنیت معمولی کلید 128 بیتی کفایت میکنه. برای کاربردهای نیازمند امنیت طولانی مدت (یعنی مثلا میخواید مطمئن باشید حتی تا 50 سال دیگه هم کل توان پردازشی بشریت قادر به رمزگشایی دیتای شما نیست - البته این به کیفیت کلید/پسورد استفاده شده هم بستگی داره) از کلید 256 بیتی استفاده کنید. در بین این سه تا که گفتم، 3DES تا حداکثر طول کلید 168 بیت ساپورت میکنه و نمیتونید از 256 بیت استفاده کنید (البته 168 هم خودش خیلی زیاده ها).
بین Twofish و AES هم AES بهتره چون استانداردتره و ساپورت بهتری داره و سرعتش هم بیشتره.

بنابراین AES انتخاب استاندارده.

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

ضمنا حداقل طول کلید فعلی برای RSA برابر 3072 بیت است (برابر امنیت کلید 128 بیتی برای الگوریتم های متقارن).
البته کلیدهای 2048 بیتی RSA هم تا سال 2030 امن محسوب میشن (در ارتباط با طول کلید میتونید این مقاله رو ببینید: http://en.wikipedia.org/wiki/Key_length).

[AmirSky]

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

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

در بین انواع متقارن خب AES که معرف همگانه و تقریبا همه جا در هر زبانی هم پیدا میشه (حتی تاجاییکه یادمه پیاده سازی جاوااسکریپت هم داره).

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

بقول شما SSL راهکار اصولی واقعی هست، ولی در عمل به دلایلی ازش بصورت گسترده استفاده نمیشه.

اگه اکثر سایتها از این روش استفاده کنند آیا از محدودیتهایی استفاده از آن کاسته نخواهد شد؟

در کدهایی که برای جاوا اسکریپت گذاشتید میشه بگید site_salt در کجا مقدار دهی میشه؟

هدف از سوالات رسیدن به نتیجه قابل قبول جهت استفاده میباشد.

[eshpilen]

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

قبلا گفته بودم که این کار هم انجام میشه.

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

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

اگه اکثر سایتها از این روش استفاده کنند آیا از محدودیتهایی استفاده از آن کاسته نخواهد شد؟

چرا.
ولی فعلا که اینطور نیست.
یه سرور وقتی میبینه با SSL ظرفیت سرویس دهیش چندین برابر کم میشه پس طبیعی هست که تمایلی به این کار نداشته باشن.

در کدهایی که برای جاوا اسکریپت گذاشتید میشه بگید site_salt در کجا مقدار دهی میشه؟

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