سناریو 1 - ذخیره پسورد کاربران و اعتبارسنجی آن در نرم افزار اتوماسیون اداری

سلام دوستان عزیز ،
پیش از آغاز فعالیت ، تاپیک "آغاز پیاده سازی طرح ارتقاء سطح علمی - ذکر جزییات" را مطالعه نمایید ،
سناریوی شماره 1 :
در یک نرم افزار اتوماسیون اداری مبتنی بر ویندوز(Windows-Based Application) ، برای ذخیره ی پسورد کاربران در دیتابیس و اعتبارسنجی آن(Authentication) نیاز به روشی مناسب میباشد. مدیر پروژه اصرار بر این دارد که امنیت(Security) از کارایی(Performance) در این خصوص میبایست بیشتر مورد توجه قرار گیرد ، این نکته را مد نظر داشته باشید که حتی مدیر سیستم(System Administrator) نیز نباید توانایی به دست آوردن پسورد کاربران(Retrieve) را داشته و تنها اجازه تغییر آن را خواهد داشت . کاربران نیز در صورت فراموش نمودن پسورد(Forgotten Password) باید یک پسورد جدید توسط نرم افزار برایشان تخصیص داده شود(Reset Password).زبان برنامه نویسی مورد استفاده در این پروژه C-Sharp میباشد.
مرحله ی اول :
الگوریتم رمزنگاری(Cryptography) مناسب را همراه با روش اعتبارسنجی با ذکر جزییات دقیق و علت پیشنهاد آن ، ارائه دهید ، دقت کنید که در این مرحله نیازی به ارسال کد نمیباشد و تنها الگوریتم مد نظر میباشد . تأکید میکنم که راه حل(Solution) های ارسالی باید عملی(Practical) و قابل پیاده سازی باشند ،
مرحله ی دوم :
Password Policy های پیشنهادی برای این سیستم را نیز شرح دهید - با ذکر دلیل و جزئیات - ،

مراحل سناریو :
1)تعیین الگوریتم رمزنگاری مورد نیاز همراه با روش اعتبارسنجی
2)تعیین Password Policy

اصلاحات :
1)نوع دیتابیس مورد نظر از سناریو حذف شد ، (سپاس از آقای علی کشاورز)
2)در این سناریو System Administrator و Database Administrator مجزا هستند ، (سپاس از آقای بهروز راد)

پیشاپیش از شرکت شما در این بحث سپاسگزارم ،/

بحث تکمیل شد ، مستندات به زودی آماده شده و در اختیار شما قرار خواهد گرفت ،/

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

نقل قول:

---

الگوریتم رمزنگاری(Cryptography) مناسب را با ذکر جزییات دقیق و علت پیشنهاد آن ، ارائه دهید ،

---

MD5 یا SHA-1.
دلایل:
1- الگوریتم های برگشت ناپذیر هستند، و نمیشه کد تولید شده توسط آنها را به کد اولیه برگرداند.
2- پیاده سازی های مختلفی از آنها موجود هست که میشه به راحتی از آنها استفاده کرد. در ویندوز توسط CryptoAPI پیاده سازی شده و در دسترس هست. در دات نت هم تا جایی که اطلاع دارم، کلاس هایی برای ساخت Hash کد توسط این الگوریتم ها بصورت آماده وجود داره.

نقل قول:

---

پایگاه داده(Database) مورد استفاده در این پروژه SQL Server 2005 یا SQL Server 2008

---

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

نقل قول:

---

MD5 یا SHA-1.

---

الگوريتم‌های چكيده‌ی پيام يا خلاصه پيام يا همون Hash Algo ها مستقيماً ارتباطی با رمزنگاری اطلاعات ندارند. اگر قرار باشد كلمه‌ی عبور كاربری در محلی به صورت رمز شده ذخيره شود پس بايد بتوان اون كلمه عبور را رمزگشایی نيز كرد، بنابراين الگوريتمهای چكيده پيام به دليل يك طرفه بودنشان برای اين كار مفيد نيستند و البته كاربرد خاص خودشون رو دارند. پيشنهاد من استفاده از الگوريتم‌های متقارن يا نامتقارن است.

نقل قول:

---

اگر قرار باشد كلمه‌ی عبور كاربری در محلی به صورت رمز شده ذخيره شود پس بايد بتوان اون كلمه عبور را رمزگشایی نيز كرد

---

در نیازمندی پروژه ذکر شده که:

نقل قول:

---

این نکته را مد نظر داشته باشید که حتی مدیر سیستم(System Administrator) نیز نباید توانایی به دست آوردن پسورد کاربران(Retrieve) را داشته و تنها اجازه تغییر آن را خواهد داشت . کاربران نیز در صورت فراموش نمودن پسورد(Forgotten Password) باید یک پسورد جدید توسط نرم افزار برایشان تخصیص داده شود(Reset Password).

---

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

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

در این سناریو باید از یک الگوریتم برگشت ناپذیر (Hash) استفاده بشه.
MD5 برای این امر مناسب نیست. SHA1 مناسبه.
MD5، یک الگوریتم 128 بیتی هست در صورتی که SHA1، الگوریتمی 160 بیتی هست. از همه مهمتر اینکه MD5 دارای Collision هست و به همین دلیل به ندرت ازش استفاده میشه. همین Collision ها بر روی SHA0، HAVAL، MD4 و RIPEMD هم وجود دارند.

قرقي نميكنه md5 باشه يا sha1 . در هر كدام اگر طول پسورد وارد شده كوتاه باشد با brute force قابل شكست است (خيلي سريع).
بنابراين علاوه بر هش كردن، استفاده از يك password policy هم توصيه مي‌شود . مثلا طول پسورد كمتر هشت كاراكتر نباشد و امثال آن (چيزي شبيه به ويندوز 2003 به صورت پيش فرض).
بعلاوه باز هم براي از كار انداختن بحث BF ، مي‌توان از salted hash استفاده كرد. مقاله‌اش فكر كنم در سايت هست.

نقل قول:

---

نوشته شده توسط anubis_ir

قرقي نميكنه md5 باشه يا sha1 . در هر كدام اگر طول پسورد وارد شده كوتاه باشد با brute force قابل شكست است (خيلي سريع).

---

خیر اینجور نیست.
فرقی بین یک الگوریتم 128 بیتی با یک الگوریتم 160 بیتی قائل نمیشی؟
هر الگوریتمی در نهایت با متغیر زمانی مختلف شکسته میشه. Brute Force رو بر روی تمامی الگوریتم ها میشه پیاده سازی کرد اما این موضوع با باگی که در اون الگوریتم وجود داره متفاوت هست.
MD5 دارای Collision هست در صورتی که SHA1 اینطور نیست.

موفق باشید.

قصد انحراف اين تاپيك رو ندارم ... ولي زمانيكه كه مي‌گويد با متغير زماني مختلف، يعني مويد حرف من. بنابراين خير اينطور "هست". كمي ديرتر يا زودتر (بسته به مراحل الگوريتم ، نه طول محاسبه شده نهايي)، ولي "بله". (بنابراين در ادامه بحث password policy مطرح مي‌شود)
ضمنا بحث Collision به اين معنا نيست كه مي‌توان از روي هش ، مقدار اوليه را حدس زد. بلكه ثابت كرده‌اند امكان دارد دو رشته متفاوت هش يكساني داشته باشند (با تعداد تست‌هاي غيرقابل تصور).
SHA-1 هم داراي اين تصادم هست. http://en.wikipedia.org/wiki/SHA ولي در كل براي بحث جاري اين تاپيك تفاوتي نمي‌كند.
استفاده از salt به همراه md5 كفايت مي‌كند.

نقل قول:

---

نوشته شده توسط anubis_ir

بعلاوه باز هم براي از كار انداختن بحث BF ، مي‌توان از salted hash استفاده كرد.

---

نقل قول:

---

نوشته شده توسط anubis_ir

استفاده از salt به همراه md5 كفايت مي‌كند.

---

به این قسمت دقت کردی؟

نقل قول:

---

نوشته شده توسط علیرضا مداح

این نکته را مد نظر داشته باشید که حتی مدیر سیستم(System Administrator) نیز نباید توانایی به دست آوردن پسورد کاربران(Retrieve) را داشته و تنها اجازه تغییر آن را خواهد داشت .

---

این Salted Hash باید در جایی نگهداری بشه. اون موقع فکر می کنی اگر System Administrator اون رو ببینه چه اتفاقی می افته؟ یک Dictionary Attack کافیه!

نقل قول:

---

نوشته شده توسط anubis_ir

SHA-1 هم داراي اين تصادم هست. http://en.wikipedia.org/wiki/SHA ولي در كل براي بحث جاري اين تاپيك تفاوتي نمي‌كند

---

به توانش نگاه کن. نسخه های بعدی رو هم ببین. حالا به MD5 نگاه کن... نوشته YES!

در اين مورد (طرح اين سوال به اين شكل) جاي تناقض بزرگي هست و آن هم اين است كه مدير سيستم شما يا امين است يا خير و اگر نيست شما در مخمسه بدي قرار گرفته‌ايد. اين مورد را بايد قبل از هر كاري برطرف كرد. (چون مدير سيستم نيازي به دانستن salt براي دستكاري اطلاعات و يا حتي drop كردن ديتابيس نداره و اين جزو حقوق مسلم اون هست)

و اگر salt روبروي چشمان يك نابكار باشد، اينجا همان بحث مطرح شده password policy بايد رعايت شود تا BF را عقيم سازد.

نقل قول:

---

نوشته شده توسط anubis_ir

در اين مورد (طرح اين سوال به اين شكل) جاي تناقض بزرگي هست و آن هم اين است كه مدير سيستم شما يا امين است يا خير و اگر نيست شما در مخمسه بدي قرار گرفته‌ايد. اين مورد را بايد قبل از هر كاري برطرف كرد.

---

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

مرسی از تشکر دوستان در بحث.
مطالب ذیل رو هم مطالعه بفرمایید.
در لینک ذیل توصیه ی اکید شده که از MD5 استفاده نشه:
http://www.rsa.com/rsalabs/node.asp?id=2738
در لینک ذیل نیز خوندن بخش Add Some Salt to Your Hash توصیه میشه:
http://msdn.microsoft.com/en-us/library/aa302352.aspx

متشکرم و موفق باشید.

به نظر من ترکیب این تکنولوژی ها با هم میتونه امنیت بیشتری رو فراهم کنه، به طور مثال Hash کردن داده ها و استفاده از اون به عنوان (بر فرض مثال) Public Key و سپس بکارگیری یکی از الگوریتمهای نامتقارن رمزنگاری به منظور افزایش امنیت داده ها راهکار جالبی میتونه باشه (البته با توجه به سناریوی مطرحی علیرضا که امنیت از سرعت مهمتر باشه)

برای پیش بردن بحث لازم است تا چند نکته را در خصوص نظرات دوستان بیان کنم ،
نتیجه ای که تا به اینجا به دست آمد بهره گیری از الگوریتم های Hash میباشد ، در دات نت و در فضای نام System.Security.Cryptography پیاده سازی های متفاوتی از الگوریتم SHA موجود میباشد ، کدامیک را پیشنهاد میکنید؟چرا؟

• SHA1
• SHA256
• SHA384
• SHA512

نقل قول:

---

(چون مدير سيستم نيازي به دانستن salt براي دستكاري اطلاعات و يا حتي drop كردن ديتابيس نداره و اين جزو حقوق مسلم اون هست)

---

به این نکته توجه کنید که در یک سیستم هر کاربر باید با هویت شخص خود به انجام فعالیت بپردازد و نباید این امکان وجود داشته باشد که مدیر سیستم با هویت کاربر دیگری در سیستم Login کند ،

نقل قول:

---

به نظر من ترکیب این تکنولوژی ها با هم میتونه امنیت بیشتری رو فراهم کنه، به طور مثال Hash کردن داده ها و استفاده از اون به عنوان (بر فرض مثال) Public Key و سپس بکارگیری یکی از الگوریتمهای نامتقارن رمزنگاری به منظور افزایش امنیت داده ها راهکار جالبی میتونه باشه (البته با توجه به سناریوی مطرحی علیرضا که امنیت از سرعت مهمتر باشه)

---

حامد جان ، کدامیک از الگوریتم های نامتقارن(Asymmetric) را در این خصوص پیشنهاد میکنید؟و چرا؟
در ضمن تکنیک جالبی را مطرح کردید ، در بسیاری از نرم افزارها از این تکنیک بهره گیری میشود ، لطفا" توضیحات بیشتری در این خصوص برای دوستان ارائه دهید ،

نقل قول:

---

در لینک ذیل نیز خوندن بخش Add Some Salt to Your Hash توصیه میشه:
http://msdn.microsoft.com/en-us/library/aa302352.aspx

---

نظر دوستان در رابطه با تکنیک Salted Hash چیست؟

در ضمن دقت کنید که فاکتور Peformance علیرغم اینکه در این پروژه از اولویت بالایی برخوردار نیست نباید به طور کامل نادبده گرفته شود ،

از تمامی دوستانی که در بحث مشارکت میکنند/خواهند کرد سپاسگزاری میکنم ،

نقل قول:

---

نوشته شده توسط علیرضا مداح

به این نکته توجه کنید که در یک سیستم هر کاربر باید با هویت شخص خود به انجام فعالیت بپردازد و نباید این امکان وجود داشته باشد که مدیر سیستم با هویت کاربر دیگری در سیستم Login کند ،

---

این مدیر سیستمی که ازش نام میبری تا چه حد به سیستم دسترسی داری؟ آیا اون DBA هم هست؟

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

نقل قول:

---

ترکیب این تکنولوژی ها با هم میتونه امنیت بیشتری رو فراهم کنه، به طور مثال Hash کردن داده ها و استفاده از اون به عنوان (بر فرض مثال) Public Key و سپس بکارگیری یکی از الگوریتمهای نامتقارن رمزنگاری به منظور افزایش امنیت داده ها راهکار جالبی میتونه باشه

---

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

نقل قول:

---

این مدیر سیستمی که ازش نام میبری تا چه حد به سیستم دسترسی داری؟ آیا اون DBA هم هست؟

---

خیر . سناریو در این مورد اصلاح شد.

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

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

نقل قول:

---

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

---

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

با سپاس از پیشنهادهای شما ،
قرار نیست در این پروژه یک نرم افزار توسعه داده شود ، تنها باید با توجه به جزئیات گقته شده یک الگوریتم رمزنگاری انتخاب شده و سپس مطابق با آن مراحل دیگر سناریو پیش رود ،
هدف فعلا" تنها یافتن الگوریتم رمزنگاری مناسب ، Password Policy مناسب و چگونگی اعتبارسنجی و در نهایت پیاده سازی آن است ،
پیشنهاد میکنم برای پیشروی بحث به نکات گفته شده در پست 13 توجه کنید ،

نقل قول:

---

به این نکته توجه کنید که در یک سیستم هر کاربر باید با هویت شخص خود به انجام فعالیت بپردازد و نباید این امکان وجود داشته باشد که مدیر سیستم با هویت کاربر دیگری در سیستم Login کند ،

---

نقل قول:

---

در این سناریو System Administrator و Database Administrator مجزا هستند

---

- مدير سيستم نيازي نداره بجاي شخص ديگري وارد شود. او به همه چيز دسترسي تام دارد.
- System Administrator مي‌تونه هر لحظه كه اراده كنه Database Administrator هم باشه.
- Database Administrator هر لحظه كه اراده كنه مي‌تونه هركاري با داده‌ها بدون لاگين بجاي شخص ديگري انجام بده.

نقل قول:

---

مدير سيستم نيازي نداره بجاي شخص ديگري وارد شود. او به همه چيز دسترسي تام دارد.

---

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

نقل قول:

---

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

---

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

حامد جان از شرکت شما در بحث و پیشنهادات شما سپاسگزارم ،

نقل قول:

---

اما علیرضا اگه بحث از جای دیگه ای شروع میشد و سپس به اینجا میرسید، خیلی بهتر بود (البته این نظر منه) مثلا سناریو به این صورت شروع میشد

---

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

این روشهایی که دوستان پست کردن از لحاظ الگوریتمیک یک اشکال بزرگ داره !
فرضیات :
1-من یک یوزرم تو سیستم شما
2-چون قراره بالاخره به بانک شما وصل بشم یه جایی باید یوزر و پسورد وصل شدن به بانک به همراه نام سرور رو به من بدید (حالا در بهترین حالت یوزر کاملا محدود شده ولی به هر حال دسترسی داره به بانک)
3-پسورد من مثلا 123 هست که هش شده و تبدیل شده به A پس من میدونم که همیشه 123 میشه A
4- اگر بتونم به بانک وصل بشم (که خیلی سخت هم نیست) و پس هش شده Admin رو یکجا تو سیستم خودم کپی کنم سپس A رو توی پس Admin بریزم و login کنم به برنامه(پس میشه 123) بلافاصله بعد از لاگین شدن پس هش شده admin رو سر جای خودش بر میگردونم و ...

از شرکت شما در این بحث سپاسگزارم ،

نقل قول:

---

2-چون قراره بالاخره به بانک شما وصل بشم یه جایی باید یوزر و پسورد وصل شدن به بانک به همراه نام سرور رو به من بدید (حالا در بهترین حالت یوزر کاملا محدود شده ولی به هر حال دسترسی داره به بانک)

---

اصولا" برای حل چنین مشکلی ، یک پسورد پیش فرض(مانند 123) برای هر کاربر در نظر گرفته میشود و اولین باری که کاربر به سیستم لاگین میکند از وی خواسته میشود که پسورد را عوض کند ، همچنین تنظیم نام سرور نیز عموما" توسط شخصی که مسئول نصب نرم افزار است صورت میگیرد یا به گونه ای دیگر به اطلاع کاربران شبکه میرسد ،

نقل قول:

---

3-پسورد من مثلا 123 هست که هش شده و تبدیل شده به A پس من میدونم که همیشه 123 میشه A

---

الف)یک کاربر هیچگاه از مقدار Hash شده ی پسورد خود اطلاعی ندارد ،
ب)اگر از Salted Hash استفاده شود ، دیگر 123 همیشه A نخواهد بود ،

نقل قول:

---

4- اگر بتونم به بانک وصل بشم (که خیلی سخت هم نیست) و پس هش شده Admin رو یکجا تو سیستم خودم کپی کنم سپس A رو توی پس Admin بریزم و login کنم به برنامه(پس میشه 123) بلافاصله بعد از لاگین شدن پس هش شده admin رو سر جای خودش بر میگردونم و ...

---

چطور اینکار را انجام میدهید؟ ، اینکار در سیستم و شبکه ای که از لحاظ امنیتی در سطح پایینی قرار دارد ، امکان پذیر است ، در غیر اینصورت اگر ConnectionString در app.config ذخیره شده و رمزنگاری شده باشد ، بدست آوردن آن کار ساده ای نخواهد بود چون تا حد زیادی ConnectionString به صورت Hack-Proof خواهد بود ، همچنین Salted Hash در این مورد نیز از یکسان بودن مقدار Hash شده ی پسورد دو یا چند کاربر جلوگیری میکند ،

لطفا" نظرات حود را در خصوص مرحله دوم - Password Policy اعلام نمایید - به سناریو مراجعه شود ، در این خصوص اصلاح شد -

نقل قول:

---

نوشته شده توسط علیرضا مداح

از شرکت شما در این بحث سپاسگزارم ،


اصولا" برای حل چنین مشکلی ، یک پسورد پیش فرض(مانند 123) برای هر کاربر در نظر گرفته میشود و اولین باری که کاربر به سیستم لاگین میکند از وی خواسته میشود که پسورد را عوض کند ، همچنین تنظیم نام سرور نیز عموما" توسط شخصی که مسئول نصب نرم افزار است صورت میگیرد یا به گونه ای دیگر به اطلاع کاربران شبکه میرسد ،


الف)یک کاربر هیچگاه از مقدار Hash شده ی پسورد خود اطلاعی ندارد ،
ب)اگر از Salted Hash استفاده شود ، دیگر 123 همیشه A نخواهد بود ،

چطور اینکار را انجام میدهید؟ ، اینکار در سیستم و شبکه ای که از لحاظ امنیتی در سطح پایینی قرار دارد ، امکان پذیر است ، در غیر اینصورت اگر ConnectionString در app.config ذخیره شده و رمزنگاری شده باشد ، بدست آوردن آن کار ساده ای نخواهد بود چون تا حد زیادی ConnectionString به صورت Hack-Proof خواهد بود ، همچنین Salted Hash در این مورد نیز از یکسان بودن مقدار Hash شده ی پسورد دو یا چند کاربر جلوگیری میکند ،

لطفا" نظرات حود را در خصوص مرحله دوم - Password Policy اعلام نمایید - به سناریو مراجعه شود ، در این خصوص اصلاح شد -

---

* - شما فرضتو این بزار که یک نفر حرفه ای با هدف نفوذ به سیستمت داره این کار رو میکنه نه یک یوزر معمولی
* - در ضمن در اکثر شرکت های کارفرما شرکتی که مسول شبکه است با شرکتی که مسول نرم افزار اتوماسیون آن است متفاوت است پس امنیت شبکه در این زمینه خیلی قابل اتکا نیست . خیلی اوقات این شرکت ها رقیب هم هستند و پیروزی یکی به نوعی شکست دیگری محسوب میشه ! حالا شاید تو کشور های صنعتی این مورد معنی نداشته باشه ولی شخصا تو ایران این موضوع رو زیاد دیدم
* - عرض کردم که اگه به جدول نگهداری پسورد ها نفوذ کنم (که کار سختی هم نیست) می تونم از نتیجه هش شده پسوردم اطلاع حاصل کنم

در ضمن منظورت رو از Salted Hash متوجه نشدم ؟ اگر هر بار نتیجه هش شدن متفاوت است چه نیازی به ذخیره اون در بانک است ؟! اونوقت چه طور میشه فهمید رمز یوزر چی بوده که بخواهیم اونو تست کنیم ؟ مگه قرار نشد از الگوریتم یک طرفه استفاده کنیم ؟ با این وصف باید راحی برای برگشتش پیدا کنیم مثل الگوریتم های RSA که دوطرفه است و همیشه 123 --> A نمیشه

Salted Hash لزوما" بدین معنا نیست که هر بار که کاربر لاگین میکند یک رمز جدید تولید میشود ، بلکه پسورد با یک آیتم دیگر که به عنوان Salt معرفی میگردد و ممکن است که یکی از فیلدهای دیتابیس باشد-مانند نام کاربری- و یا به طور تصادفی ایجاد و در بانک ذخیره شده باشد ، با یک شیوه ی خاص ترکیب شده و سپس Hash میشود تا دو کاربر با پسورد یکسان ، پسوردهای Hash شده ی یکسانی نداشته باشند ، پیشنهاد میکنم مقاله ی زیر را در این خصوص مطالعه نمایید :
CodeProject - The art And Science of Storing Passwords

با سلام
شرح مختصر
1- در سيستم اتوماسيون اداري اصولاً هر شخصي که LOGIN نمايد داراي کارتابل خودش بوده و فقط قادر به ديدن مکاتبات ارجاع شده به خودش مي باشد در نتيجه حتي اگر ADMIN هم به سيستم LOGIN نمايد فقط در محيط خودش وارد شده و امکانات زيادتري خواهد داشت از جمله تغيير رمز افراد ديگر و ...
2- دسترسي ADMIN به هر شخص داده شود يعني امکانات خودش در محيط خود به انضمام امکانات ADMIN با توجه به اين موضوع پس ADMIN يک نقش مي باشد که در سيستم با امکانات FULL CONTROL تعريف شده است. و عملاً قدرت ديدن مکاتبات ديگران را ندارد قادر به دسترسي به ارسال و مراسلات را دارد.
3- تعريف نقش : براي هر نقش به تفکيک ميتوان عمل نمود و ضمن امکانات اضافه . ويرايش . حذف .گزارش گيري و ... حدود دسترسي را مشخص نمود .
نيازي به پيچيده کردن مطالب نيست و پسوردها ميتواند تنهابا الگوريتمي مثل hash در ديتابيس ذخيره شود
دوستان توجه داشته باشن اگر هر مشکلي در رابطه با شبکه و نرم افزار صورت بگيره اين admin سيستم است که بايد پاسخگو باشد و رفع مشکل نمايد .(اصل بر برائت است)
4- با توجه به مواد مطرح شده ذخيره در بانک اطلاعاتي کافي به نظر ميرسه و اگر از سيستم پشتيبان گرفته شود کل يوزرها نيز حفظ ميشود.

يک سئوال که مطمئناً در طراحي نقش به سزاي دارد.
اين اتوماسيون قدرت اجراي آن يا محدوده اجراي آن چقدر است در يک شبکه محلي اجرا ميشود يا در اينترنت يا ...

به نظر من بهتره برای اینکه کاربران نتوانند در بانک نام کاربری و پسورد خودشون رو ردیابی کنند تا بتوانند با دانستن اینکه پسورد میشه A بتوانند پسورد ادمین رو هک کنند در زمان ذخیره نامهای کاربری این گزینه را هم کد کرده تا دیگر کسی نتواند از این موضوع استفاده منفی کنید در ضمن برای hash کردن هم به نظره من برای هر کاری که جنبه حفاظتی داره استفاده از گزینه هائی که آقای مداح (پست شماره 13 )مطرح کردن بد نیست ولی چون این موارد در دسترس همه است بهتره یک کلید چند حرفی یا عددی یا از علامات خاص ( که می تونه این هم hash شده باشه تا در دسترس نباشه ) تعریف کرد تا به صورت کلی از موضوع مورد نظر حفاظت بشه

برای اینکه در صورت نفوذ یک فرد به db‌باز هم نتونه کاری انجام بده میشه هم username و هم password‌رو بصورت hash‌شده در db‌ نگه داری کرد و هر کدام هم salt متفاوتی داشته باشند (که حالا رو این که salt‌چی باشه میشه بحث کرد).
با این کار حالا به فرض یکی اومد و نفوذ کرد تو db که حاوی مقادیر hash‌شده username ها و pass هاست. حتی اگر این فرد نفوذگر یک user هم باشه (که میدونه username و pass اش چیه) بازم نمیتونه بفهمه که مقدار hash‌شده pass‌اش چیه که اونو با Admin عوض کنه چون اصلا نمیتونه username خودشو پیدا کنه و چون از مقدار salt و نیز الگوریتم hash هم اطلاعی نداره پس احتمال کارامد بودن BF‌هم به صفر میل میکنه!
برای login‌کردن هم مقادیر hash‌ شده username‌و password وارد شده مورد بررسی قرار میگیرند و در صورت وجود چنین جفتی در db‌اون user میتونه login‌بشه و در غیر اینصورت دو حالت وجود داره: یا username‌اشتباه وارد شده و یا password.
به همین دلیل هم هست که موقعی که pass ایمیل خودتون رو اشتباه وارد میکنید میگه ممکنه username‌اشتباه باشه یا ممکنه password اشتباه باشه چون در واقع نمیشه فهمید که کدوم اشتباه هستند.
به عقیده بنده این حالت نگهداری اطلاعات login‌ امنیت خیلی خوبی داره.

از شرکت دوستان در بحث سپاسگزارم،

ایده ی مطرح شده از جانب bermoda و parsavb برای Hash کردن نام کاربری ، روش خوبیست که موجب افزایش امنیت میگردد و کار نفوذگر را بسیار دشوار خواهد کرد،

نقل قول:

---

که حالا رو این که salt‌چی باشه میشه بحث کرد

---

خوب بگذارید بحث را به این سمت ببریم ، چه پیشنهادی برای پیاده سازی Salted Hash در این روش دارید؟لطفا" چگونگی پیاده سازی را شرح دهید ،

پ.ن: لطفا" در حال حاضر تنها بر روی موضوع سنارو متمرکز شوید ، باتشکر ،/

میشه برای اینکه تا حد زیادی مقدار salt هم از دید پنهان باشه و در ضمن مقدار ثابتی هم نباشه، برای هر username و pass‌ که میخوایم hash کنیم یک مقدار random برای salt در نظر بگیریم (که به نظر من یک آرایه از بایت ها که بصورت random بدست اومده با طول ثابت) سپس مقدار hash شده username‌ رو بدست میاریم و برای نگهداری مقدار Salt اونو به آخر مقدار hash‌ شده اضافه میکنیم و مقدار جدید رو در db بعنوان username‌ نگهداری میکنیم. برای password هم همین کار رو انجام میدیم ولی مقدار salt اون متفاوت خواهد بود.
البته دقت کنید که در این حالت باید طول salt بدست اومده ثابت باشه تا موقع خوندن دوباره salt از رو username دچار مشکل نشیم.
در هنگام login نیز مقادیر از db خونده میشن و Salt ها از روی username و password استخراج شده و مقادیر hash اطلاعات ورودی کاربر با استفاده از این salt های استخراج شده محاسبه می شوند و در صورت تطابق کاربر اجازه login خواهد داشت.
مطمئنا برای امنیت بیشتر مقدار Salt میشه با استفاده از الگوریتمهای نامتقارن اونو encrypt کرد و مقدار encrypt‌ شدشو به username و pass اضافه کرد. ولی به نظر من احتیاجی به این کار نخواهد بود.

خوب بگذارید این بحث را یک مقدار بشکافیم،
1)آیا لزوما" احتیاجی به Hash کردن "نام کاربری" نیز هست؟
هنگامیکه کاربر برای ورود به سیستم ، نام کاربری را وارد میکند ، این نام کاربری دیده میشود و همچنین معمولا" هنگامیکه برنامه در حال اجراست در قسمتی از آن نام کاربری درج میشود - به صورت Plain-Text - همچنین در بعضی مواقع ، حدس زدن یا به هر حال بدست آوردن نام کاربری زیاد دشوار نخواهد بود ، نظر شما چیست؟

2)آیا بهتر نیست روش Attach کردن Salt به پسورد را تغییر دهیم؟ بدینصورت که به جای اینکه Salt را مستقیما" به انتهای پسورد اضافه کنیم ، آن را با یک روش مشخص در طول پسورد پخش (Distribute) کنیم،
3)

نقل قول:

---

سپس مقدار hash شده username‌ رو بدست میاریم

---

روش Salted-Hash عموما" بدین صورت است که ابتدا مقدار مورد نظر(پسورد ، نام کاربری ...) با Salt (که میتواند جهت امنیت بیشتر به طور رندوم تولید شود) ترکیب شده و مقدار بدست آمده از ترکیب این دو ، Hash میشود ، حال ما میتوانیم برای اینکه به قول شما Salt تا میزانی از دید پنهان بماند ، آن را به انتهای این مقدار Hash شده ی به دست آمده اضافه نماییم ، این مورد نیز جای بحث دارد ،

لطفا" نظرات خود را در خصوص مسائل ذکر شده مطرح نمایید ،/

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

خوب این کاری هست که من انجام می دهم

نام کاربر در برنامه ها باید منحصر بفرد باشد این که روشن هست از آن با U یاد می کنیم
پسورد هم که برای هر کاربر وجود خواهد داشت با P از آن یاد می کنیم

الگوریتم من
U را با P جمع می کنم، این جمع کردن می تواند قراردادن پشت سر هم کارکترها باشد یا مثلا
جمع بیت وایز کاراکترها بعد از این کار خروجی بدست آمده را با یک الگوریتمی حالا md5 یا sha1 یا sha2 هش می کنم و در دیتابیس ثبت می کنم. این قسمت از کد حتما باید با کارهایی که در برنامه انجام می شود کاملا حفاظت بشود.

نقل قول:

---

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

---

بله صحیح است ، اگر نفوذگر به کد برنامه دسترسی پیدا کرده و الگوریتم های مورد استفاده یا شیوه ی Salted-Hash کردن پسورد یا نام کاربری را بدست بیاورد از دشواری کار برای وی کاسته میشود ،
روش پیشنهادی شما برای محافظت از آین قسمت خاص از کد چیست؟

نقل قول:

---

نوشته شده توسط علیرضا مداح

بله صحیح است ، اگر نفوذگر به کد برنامه دسترسی پیدا کرده و الگوریتم های مورد استفاده یا شیوه ی Salted-Hash کردن پسورد یا نام کاربری را بدست بیاورد از دشواری کار برای وی کاسته میشود ،
روش پیشنهادی شما برای محافظت از آین قسمت خاص از کد چیست؟

---

من در این زمینه کار نکردم ، که روش خاصی داشته باشم ، اگر از .نت استفاده می کنید می توانید از ابزارهای xenocode و smartcode و ... چندتا دیگر استفاده کنید.

نقل قول:

---

آیا لزوما" احتیاجی به Hash کردن "نام کاربری" نیز هست؟

---

به نظر من برای بالاتر بردن امنیت این کار الزامی است. چرا که در صورت نفوذ به db هم نفوذگر را کاملا سردرگم خواهد کرد و امکان پیدا کردن اینکه چه username ی دارای چه مقدار hash‌شده ای برای password اش است، بسیار کم می کند.

نقل قول:

---

همچنین معمولا" هنگامیکه برنامه در حال اجراست در قسمتی از آن نام کاربری درج میشود - به صورت Plain-Text -

---

خوب از این نظر نیز مشکلی نخواهد بود چرا که اصلا اجباری نیست تا مقدار واقعی username رو دوباره از db خوانده و آنرا نمایش داد (در طول برنامه) --البته این کار امکان پذیر نیز نحواهد بود به دلیل hashing.
برای این کار پس از اعتبار سنجی اطلاعات login در صورت صحت اطلاعات ورودی، مقدار plain text مربوط به username که در زمان login وارد شده خوانده شده و به عنوان username آن کاربر در طول برنامه نشان داده می شود.

نقل قول:

---

حدس زدن یا به هر حال بدست آوردن نام کاربری زیاد دشوار نخواهد بود

---

این امر چه تاثیری بر روند کار می تواند داشته باشد؟ فرض کنیم که فردی بتواند به درستی نام کاربری را حدس بزند، اما در صورتیکه کلمه عبور را اشتباه وارد کند نمی تواند بفهمد که نام کاربری اش درست بوده.

نقل قول:

---

آیا بهتر نیست روش Attach کردن Salt به پسورد را تغییر دهیم؟ بدینصورت که به جای اینکه Salt را مستقیما" به انتهای پسورد اضافه کنیم ، آن را با یک روش مشخص در طول پسورد پخش (Distribute) کنیم،

---

موافقم

نقل قول:

---

روش Salted-Hash عموما" بدین صورت است که ابتدا مقدار مورد نظر(پسورد ، نام کاربری ...) با Salt (که میتواند جهت امنیت بیشتر به طور رندوم تولید شود) ترکیب شده و مقدار بدست آمده از ترکیب این دو ، Hash میشود ، حال ما میتوانیم برای اینکه به قول شما Salt تا میزانی از دید پنهان بماند ، آن را به انتهای این مقدار Hash شده ی به دست آمده اضافه نماییم ،

---

اما در اینصورت ما یک salt داریم و در صورت لو رفتن آن (به هر نحوی) هم username رو از دست داده ایم و هم password را (یعنی امکان این امر افزایش پیدا میکنه).
اگر هر کدام را جداگانه hash‌ کنیم در اینصورت salt های متفاوتی خواهیم داشت و امکان این که هر دو salt‌ لو بروند کمتر خواهد بود. در پایان میتوان برای نگهداری مقادیر hash شده username و password را با هم ترکیب کرد (با الگوریتم های مناسب) و سپس در db نگهداری کرد.

نقل قول:

---

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

---

به نظر من بهتر است این بحث را به آینده موکول نمایید تا مسیر بحث منحرف نشود زیرا این مسئله جزو پیاده سازی محسوب می شود . (البته این فقط پیشنهاد است)

نقل قول:

---

خوب از این نظر نیز مشکلی نخواهد بود چرا که اصلا اجباری نیست تا مقدار واقعی username رو دوباره از db خوانده و آنرا نمایش داد (در طول برنامه) --البته این کار امکان پذیر نیز نحواهد بود به دلیل hashing.
برای این کار پس از اعتبار سنجی اطلاعات login در صورت صحت اطلاعات ورودی، مقدار plain text مربوط به username که در زمان login وارد شده خوانده شده و به عنوان username آن کاربر در طول برنامه نشان داده می شود.

---

منظور از نمایش نام کاربری به صورت Plain-Text مقداری بود که از سوی کاربر هنگام Login وارد میشود،
بدینمنظور دو ایده برای بحث وجود دارد :
1) نام کاربری که در طول برنامه نشان داده میشود همیشه با یک فرمت خاص نمایش داده شود(مثلا به صورت Lower-Case یا Upper-Case) ، چون هنگامیکه نام کاربری Hash میشود به صورت Case-Sensitive در می آید و با این روش نمیتوان از فرمت واقعی آن اطلاع پیدا کرد ،
2)نام کاربری هر شخص به طور رندوم تولید شده و به وی داده شود تا نتوان از روی نام یا نام خانوادگی و دیگر اطلاعات یک کاربر ، نام کاربری وی را حدس زد ،

نقل قول:

---

این امر چه تاثیری بر روند کار می تواند داشته باشد؟ فرض کنیم که فردی بتواند به درستی نام کاربری را حدس بزند، اما در صورتیکه کلمه عبور را اشتباه وارد کند نمی تواند بفهمد که نام کاربری اش درست بوده.

---

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

نقل قول:

---

اما در اینصورت ما یک salt داریم

---

خیر ، در این روش نیز برای هر پسورد یا نام کاربری یک Unique Salt به طور رندوم توسط الگوریتم های موجود ایجاد میگردد ، پس با لو رفتن Salt یکی از کاربران ، Salt کاربران دیگر همچنان مخفی باقی میماند ،

نقل قول:

---

به نظر من بهتر است این بحث را به آینده موکول نمایید تا مسیر بحث منحرف نشود زیرا این مسئله جزو پیاده سازی محسوب می شود . (البته این فقط پیشنهاد است)

---

موافقم ،

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

1- LoginID
2-password
3-username
4-سایر اطلاعات شخصی و مورد نیاز
login ID را همیشه استرینگ می گیرم.
ترکیب خاصی از ورودی loginid را هش کرده و به عنوان loginid بکار می برم و در دیتابیس ذخیره می کنم
ترکیب خاص دیگری ازloginid , password را هش کرده و به عنوان پسورد ذخیره می کنم
بعد از اعتبارسنجی فیلد سوم هم در یک کلاس به نام کاربران که در برنامه دارم به عنوان نام کاربر در یک خاصیت ذخیره شده و جهت نمایش بکار می برم.

نقل قول:

---

نام کاربری که در طول برنامه نشان داده میشود همیشه با یک فرمت خاص نمایش داده شود(مثلا به صورت Lower-Case یا Upper-Case) ، چون هنگامیکه نام کاربری Hash میشود به صورت Case-Sensitive در می آید و با این روش نمیتوان از فرمت واقعی آن اطلاع پیدا کرد ،

---

من پیشنهاد میکنم که username‌به هر صورت که وارد شد (توسط کاربر) قبل از hash‌شدن به صورت uppercase‌یا lowercase درآمده و سپس hash‌شود. چون اصولا نباید username‌ کاربران case sensitive‌ باشد (همانگونه که هیچ جای دیگر هم چنین نیست). پس در اینصورت فرمت خاصی هم برای نمایش احتیاج نخواهد بود و به هر شکلی که کاربر username خود را وارد کرده باشد به همان صورت هم در برنامه نمایش داده میشود.

نقل قول:

---

اگر تاثیری ندارد ، چه لزومی بر Hash کردن نام کاربری وجود دارد؟

---

در واقع هدف اصلی از hash‌ کردن نام کاربری این است که اگر فردی توانست به db م نفوذ کند قادر به بدست آوردن مقدار hash شده password اش نباشد (بر اساس username) چرا که اگر username‌ بصورت plain-text در db نگهداری شود، احتمال اینکه نفوذگر بتواند مقدار hash‌ شده password خود را بدست آورده و با جابجایی آن با سایر کاربرها (مثلا Admin) سیستم را در اختیار بگیرد، بسیار افزایش می یابد.

نقل قول:

---

پس با لو رفتن Salt یکی از کاربران ، Salt کاربران دیگر همچنان مخفی باقی میماند ،

---

من منظورم این نبود که برای همه کاربران یک Salt‌ داریم، بلکه منظورم این بود که برای یک کاربر یک salt داریم و با روشی که بنده عرض کردم برای هر کاربر دو تا Salt خواهیم داشت ، یکی برای username و دیگری برای password. در اینصورت اگر یکی از salt ها لو برود باز هم امنیت سیستم به مخاطره نخواهد افتاد زیرا salt ها متفاوت بوده اند.

نقل قول:

---

من منظورم این نبود که برای همه کاربران یک Salt‌ داریم، بلکه منظورم این بود که برای یک کاربر یک salt داریم و با روشی که بنده عرض کردم برای هر کاربر دو تا Salt خواهیم داشت ، یکی برای username و دیگری برای password. در اینصورت اگر یکی از salt ها لو برود باز هم امنیت سیستم به مخاطره نخواهد افتاد زیرا salt ها متفاوت بوده اند.

---

بله ، مسلما" همینطور است و Usename و Password دارای Salt های متفاوتی خواهند بود و منظور از Unique Salt در پست قبلی ، یک Unique Salt برای پسورد و یک Unique Salt دیگر برای نام کاربری بود ،
بهتر است که موضوع Password Policy را نیز در بحث بگنجانیم ،
به نظر شما چه فاکتورهایی میتواند برای تمیز دادن یک پسورد Strong از یک پسورد Weak مورد استفاده قرار گیرد؟لطفا" نظرات خود را در این خصوص بیان نمایید ،/