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

[علیرضا مداح]

سلام دوستان عزیز ،
پیش از آغاز فعالیت ، تاپیک "آغاز پیاده سازی طرح ارتقاء سطح علمی - ذکر جزییات (http://www.barnamenevis.org/forum/showthread.php?t=120541)" را مطالعه نمایید ،
سناریوی شماره 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 مجزا هستند ، (سپاس از آقای بهروز راد)

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

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

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

[vcldeveloper]

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


پایگاه داده(Database) مورد استفاده در این پروژه SQL Server 2005 یا SQL Server 2008
پیشنهاد می کنم که بصورت ساخت یک کامپوننت یا یک مجموعه کامپوننت انجام بشه که reusability کد بالا بره. برای بانک اطلاعاتی به نظر من عدم وابستگی به یک نوع خاص از بانک اطلاعاتی موجب افزایش reusability و انعطاف پذیری کد میشه.

[m-khorsandi]

MD5 یا SHA-1.

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

[vcldeveloper]

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

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

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

[Behrouz_Rad]

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

[anubis_ir]

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

[Behrouz_Rad]

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

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

موفق باشید.

[anubis_ir]

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

[Behrouz_Rad]

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



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

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


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

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


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

به توانش نگاه کن. نسخه های بعدی رو هم ببین. حالا به MD5 (http://en.wikipedia.org/wiki/Md5) نگاه کن... نوشته YES!

[anubis_ir]

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

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

[Behrouz_Rad]

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

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

مرسی از تشکر دوستان در بحث.
مطالب ذیل رو هم مطالعه بفرمایید.
در لینک ذیل توصیه ی اکید شده که از 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

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

[hdv212]

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

[علیرضا مداح]

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



SHA1 (http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha1%28VS.80%29.aspx)
SHA256 (http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256.aspx)
SHA384 (http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha384.aspx)
SHA512 (http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha512.aspx)




(چون مدير سيستم نيازي به دانستن salt براي دستكاري اطلاعات و يا حتي drop كردن ديتابيس نداره و اين جزو حقوق مسلم اون هست)به این نکته توجه کنید که در یک سیستم هر کاربر باید با هویت شخص خود به انجام فعالیت بپردازد و نباید این امکان وجود داشته باشد که مدیر سیستم با هویت کاربر دیگری در سیستم Login کند ،



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


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

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

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

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

[Behrouz_Rad]

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

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

[vcldeveloper]

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



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

[علیرضا مداح]

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

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

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

[vcldeveloper]

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

[علیرضا مداح]

با سپاس از پیشنهادهای شما ،
قرار نیست در این پروژه یک نرم افزار توسعه داده شود ، تنها باید با توجه به جزئیات گقته شده یک الگوریتم رمزنگاری انتخاب شده و سپس مطابق با آن مراحل دیگر سناریو پیش رود ،
هدف فعلا" تنها یافتن الگوریتم رمزنگاری مناسب ، Password Policy مناسب و چگونگی اعتبارسنجی و در نهایت پیاده سازی آن است ،
پیشنهاد میکنم برای پیشروی بحث به نکات گفته شده در پست 13 (http://www.barnamenevis.org/forum/showpost.php?p=586929&postcount=13) توجه کنید ،

[anubis_ir]

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



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

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

[علیرضا مداح]

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


بله صحیح است ، اما نباید هم این امکان برای وی وجود داشته باشد که با هویت شخص دیگری به فعالیت بپردازد ، اما فعلا" بحث بر روی مسئله ی دیگریست ،
لطفا" فعلا" برای ادامه ی بحث به پست 13 (http://www.barnamenevis.org/forum/showpost.php?p=586929&postcount=13) مراجعه نمایید تا بتوانیم بحث را بر روی موضوع مورد بحث در سناریو به پیش بریم ، ان شاءالله با اتمام این سناریو مطالب دیگری را نیز در صورت امکان در این خصوص موزد بررسی قرار خواهیم داد ،

[hdv212]

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

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

[علیرضا مداح]

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


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

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

[Microsoft.net]

این روشهایی که دوستان پست کردن از لحاظ الگوریتمیک یک اشکال بزرگ داره !
فرضیات :
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 اعلام نمایید - به سناریو مراجعه شود ، در این خصوص اصلاح شد -

[Microsoft.net]

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


اصولا" برای حل چنین مشکلی ، یک پسورد پیش فرض(مانند 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 (http://www.codeproject.com/KB/recipes/StoringPasswords.aspx)

[daskar]

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

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

[parsavb]

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

[Amir Oveisi]

برای اینکه در صورت نفوذ یک فرد به 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 در این روش دارید؟لطفا" چگونگی پیاده سازی را شرح دهید ،

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

[Amir Oveisi]

میشه برای اینکه تا حد زیادی مقدار 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 شده ی به دست آمده اضافه نماییم ، این مورد نیز جای بحث دارد ،

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

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

[linux]

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

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

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

[علیرضا مداح]

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

[linux]

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

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

[Amir Oveisi]

آیا لزوما" احتیاجی به 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 کاربران دیگر همچنان مخفی باقی میماند ،



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

موافقم ،

[linux]

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

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

[Amir Oveisi]

نام کاربری که در طول برنامه نشان داده میشود همیشه با یک فرمت خاص نمایش داده شود(مثلا به صورت 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 مورد استفاده قرار گیرد؟لطفا" نظرات خود را در این خصوص بیان نمایید ،/

[Behrouz_Rad]

به نظر شما چه فاکتورهایی میتواند برای تمیز دادن یک پسورد Strong از یک پسورد Weak مورد استفاده قرار گیرد؟لطفا" نظرات خود را در این خصوص بیان نمایید ،/

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

موفق باشید.

[علیرضا مداح]

در بحث Password Strength ، فاکتورهای زیر میتوانند مورد بحث قرار گیرند :
1)حداقل طول پسورد ،
2)Case-Sensitive بودن پسورد ،
3)تعیین گروه کاراکترها که حتما" باید پسورد شامل عضوی از آنها شود ،
4)حداقل تعداد کاراکتر از هر گروه که باید پسورد شامل آن شود ،
5)تعیین کاراکترهای غیرمجاز یا مجاز ،
6)محدودیت استفاده از نام کاربری به عنوان بخشی از پسورد ،
7)محدودیت استفاده از پسورد قبلی به عنوان بخشی از پسورد جدید به هنگام تغییر پسورد ،
7)...

[razavi_university]

کمی دیر متوجه این بحث شدم
پس ببخشید کمی عقبم!

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

[علیرضا مداح]

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

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

در حال حاضر نظرات خود را در رابطه با مباحث مطرح شده در پست 42 که در مورد Password Stength میباشد ، مطرح نمایید ،/

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

[jaza_sa]

3)تعیین گروه کاراکترها که حتما" باید پسورد شامل عضوی از آنها شود ،

که میتونه شامل عدد ، کاراکترهای خاص و حروف باشه

[mohammed]

در بحث Password Strength ، فاکتورهای زیر میتوانند مورد بحث قرار گیرند : ....


سلام

به نظر من Password Strength چیز لازمی است اما باید بسیار ضعیفتر از آنچه مسوولین شبکه ها درخواست می کنند باشد. بطور مثال وضعیت پیش فرض Windows Server در این مساله را نگاه کنید.

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

فکر می کنید در سیستمهای زیر بار با مجبور کردن کاربران به تبعیت از آن به چه می رسیم؟ یا پسوردهای یکسان تکراری (مثلا EWQqwe3 که اگر روی کی برد نگاه کنید فهمیدنش مثل آب خوردن است.) یا درخواست بهره بردار در غیر فعال کردن کلی آن که آنهم نتیجه اش بدتر از اولی است.

[mohammed]

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



SHA1 (http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha1%28VS.80%29.aspx)
SHA256 (http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256.aspx)
SHA384 (http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha384.aspx)
SHA512 (http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha512.aspx)



م ،

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

توصیه می شود از یکی از الگوریتمهای 2 تا 4 استفاده شود. این مجموعه را SHA2 نیز می نامند.

[علیرضا مداح]

@mohammed
به بحث ما خوش آمدید ،/


به نظر من Password Strength چیز لازمی است اما باید بسیار ضعیفتر از آنچه مسوولین شبکه ها درخواست می کنند باشد. بطور مثال وضعیت پیش فرض Windows Server در این مساله را نگاه کنید.


ما قصد طراحی یک سیستم امن را داریم ، پس امنیت سیستم از بالاترین اولویت برخوردار است ، در صورتیکه پسورد کاربران از لحاظ طبقه بندی جزو دسته ی Weak قرار گیرند ، بسیاری از فعالیت های دیگر که جهت سخت تر کردن حملات Brute-Force-Dictionary و ... صورت میگیرند ، کاربرد مناسب خود را نخواهند داشت ،
بله ، موردی که ذکر کردید نمونه ای شایع در بین کاربران سیستم های ادارای میباشد و ناشی از دست پایین گرفتن خطر از دست دادن و لو رفتن اطلاعات توسط مدیران میباشد ،
روشهایی برای جلوگیری از این امر وجود دارد که میتوانیم بر روی آنها بحث کنیم :
1)وادار نمودن کاربر به تعویض پسورد به صورت دوره ای و Expire شذن پسورد ،
2)نگهداری تاریخچه ای از پسوردها و محدود کردن کاربر به انتخاب یک پسورد جدید که در Password History وجود نداشته باشد ،
3)اعمال محدودیت برای استفاده از نام کاربری به عنوان بخشی از پسورد ،
4)...

[mohammed]

علیرضای عزیز - سلام

با شما موافقم. ضمن آنکه مواردی که گفتی را درست می دانم نظرم را درباره Password Strength گفتم. یعنی پیشنهاد می کنم سختگیری زیادی روی قواعد حاکم بر وضعیت کلمه رمز نباشد. به عنوان مثال: کاربر به تعویض پسورد ملزم باشد اما دوره تعویض زیاد باشد (مثلا 3 ماه) - نوع ترکیب خیلی ساده نباشد اما خیلی سخت هم نباشد مثلا طول آن حداقل 4 حرف باشد و حداقل از دو گروه حروف کوچک، حروف بزرگ، اعداد، علایم استفاده نماید. - ...

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

[razavi_university]

برای داشتن یک پسورد قوی باید پسورد وارد شده توسط کاربر رو بررسی کنیم (شبیه Password Meter (http://www.passwordmeter.com/)ها) و فاکتور های اون میتونه اینها باشه
1- حداقل 8 حرف باشد
2- شامل حروف کوچک باشد
3- شامل حروف بزرگ باشد
4 شامل اعداد باشد
5 شامل علامتها باشد


اگر N رو تعداد کاراکتر ممکن در نظر بگیریم و L تعداد آن در پسورد لگاریتم در مبنای 2 اون با فرمول زیر محاسبه کنیم H کنیم مقدار قوی بودن اون رو حدودا نشون میده

http://upload.wikimedia.org/math/1/7/f/17fc16b5e23ca94b3c92c2c227b748c9.png

http://i38.tinypic.com/2crlehe.jpg
منبع ویکیپدیا (http://en.wikipedia.org/wiki/Password_strength)
و البته قوانین حاکم بر اونها:
- کاراکترها تا حد امکان تکراری و ترتیبی نباشند
- عدم استفاده از اسم کاربری یا ترکیب آن برای پسورد
- از کلمات فرهنگ لغات نباشد
- در صورتی که برای جاهای مختلف چند پسورد مورد نیاز باشد این پسورد ها یکسان یا شبیه نباشد
- به صورت دوره عوض شود و پسورد جدید با قبلی یکسان یا مشابه نباشد

و برای ایمنی بیشتر پسورد در قالب میل و .. ارسال نشود و پیشنهاد دهنده پسورد (PassGenerator) هم وجود داشته باشد

در اولین فرصت یک Password Meter اینجا قرار میدم(WinApp)

[علیرضا مداح]

علیرضای عزیز - سلام

با شما موافقم. ضمن آنکه مواردی که گفتی را درست می دانم نظرم را درباره Password Strength گفتم. یعنی پیشنهاد می کنم سختگیری زیادی روی قواعد حاکم بر وضعیت کلمه رمز نباشد. به عنوان مثال: کاربر به تعویض پسورد ملزم باشد اما دوره تعویض زیاد باشد (مثلا 3 ماه) - نوع ترکیب خیلی ساده نباشد اما خیلی سخت هم نباشد مثلا طول آن حداقل 4 حرف باشد و حداقل از دو گروه حروف کوچک، حروف بزرگ، اعداد، علایم استفاده نماید. - ...

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

هنگامیکه سیستم از لحاظ فنی دارای ضعف باشد ، مسلما" تمام تلاشهای دیگر که در جهت آگاه سازی کاربران و بخش انسانی یک سازمان صورت میگیرد بی فایده خواهد بود ، Password Policy ها در صورت اعمال باید به گونه ای بازدارنده پیاده سازی گردند تا راه را برای نفوذگر دشوارتر کنند - البته غنی سازی سازمان از لحاظ فنی باید در راستای دیگر فعالیت های لازم نیز باشد ،

@razavi_university
ایده های مطرح شده جالب و کاربردی هستند ، در صورتیکه این Password Policy ها در جای مناسب خود و به طور صحیح پیاده سازی شوند ، نقش بسیار مهمی را در جلوگیری از حملات گوناگون ایفا میکنند ،


و برای ایمنی بیشتر پسورد در قالب میل و .. ارسال نشود و پیشنهاد دهنده پسورد (PassGenerator) هم وجود داشته باشد


این Password Generator میتواند در هنگام ایجاد کاربر جدید و همچنین فراموشی پسورد ، یک پسورد Unique که تمام شرایط را دارا باشد ، ارائه دهد ،

[mostafaaa]

البته یک چیزی که به نظر اینجانب میرسه توجه به این مطلب هست که همیشه ما در پروژه های بزرگ مجبور به استفاده از Roule ها یا گروه های کاربران هستیم که هر کدام نیز دسترسی های خاص خودشان رو دارن.
حالا اگه من یکی از یوزر های سیستم باشم و به هر دلیلی به DB دست پیدا کنم ، اصلا لزومی نمیبینم که پسوورد ادمین رو بدست بیارم، چرا دسترسیهای یوزر خودم رو تغییر ندم.
برای مثال دیتابیس نمونه ASPNETDB رو بررسی کنید.
با اینکه برای ذخیره پسوورد کاربران از Salt هم استفاده کرده ولی به راحتی میتونید با دسترسی به DB به یه یوزر مجوز رول ADMIN رو بدید.

[علیرضا مداح]

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

حال میخواهیم بر روی این مسئله بحث کینم که :
هنگامیکه پروژه توسط C# پیاده سازی شد ، اگر نفوذگر به سورس کد پروژه دست پیدا کند و از روش ترکیب پسورد با SALT یا الگوریتم های Hash و کلا" از چگونگی پیاده سازی عملیات ذکر شده اطلاع پیدا کند :
-آیا این امر موجب کاهش امنیت سیستم میگردد؟ یا به عبارتی یک نقص/ضعف امنیتی محسوب میشود؟
اگر جواب مثبت است ، لطفا" راهکار(های) خود را در این خصوص بیان نمایید ،

[razavi_university]

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

[علیرضا مداح]

خوب در اینحالت دو ایده جهت بحث وجود دارد :
1)از ابزارهای Protector همانند XenoCode و ... استفاده کنیم ،
2)اسمبلی مورد نظر که سورس کد پیاده سازی امور امنیتی در آن وجود دارد را توسط الگوریتم های موجود Encrypt کرده ، سپس در زمان اجرا ، آن را Decrypt کرده و توسط تکنیک Reflection در دات نت به اعضای آن به صورت Hard-Code و توسط اشیاء فضای نام System.Reflection دسترسی داشته باشیم ، در این خصوص نیز این 2 مبحث جهت بحث مطرح خواهد بود که :
الف)نظر شما در رابطه با امنیت این روش چیست؟
ب)کلید عمومی(Public Key) یا کلید خصوصی(Private Key) در چه مکانی ذخیره گردد؟

-شما نیز ایده های خود را جهت بحث مطرح نمایید ،/

[Fh_prg]

به عنوان كسي كه سالها تو امنيت نرم افزار تجربه داره ميگم: (البته حرفام كليه و مربوط به موضوع ميشه)


اطلاعات اصلي مربوط به كاربر چيه؟


كاربر
نام و نام خانوادگي كاربر
كلمه رمز
سطح دسترسي


چيكار كنم كه يك كاربر خرابكار با دسترسي به ديتابيس و پيدا كردن پسوردهش شده مدير ، نتونه با جايگزين كردن پسورد هش شده خودش به جاي پسورد مدير راه خودش رو براي ورود به صورت مدير باز كنه؟


پسورد هش شده حتما بايد يك رابطه رياضي با نام كاربري داشته باشه تا قابل جايگذاري نباشه (مثلا ميتونه يك رابطه رياضي ساده يا پيچيده با CRC نام كاربر داشته باشه)
بهتره براي اينكه از تداخلها و توليد پترنهاي يكسان جلوگيري كنيم هميشه نام كاربري رو با يك مقدار تصادفي جمع كنيم البته اين عمل فقط يك بار و در لحظه تعريف كردن نام كاربر اتفاق ميفته...


من به عنوان يك خرابكار ابتدا سعي ميكنم از خود برنامه شروع كنم: پشت سيستم ميشينم و نام كاربري كه قبلا از كسي شنيدم وارد ميكنم...كلمه رمز چيه؟ چندتا كلمه رمز پيش فرض دارم كه هميشه اول اونا رو چك ميكنم بعد از وارد كردن كلمه رمز دهم سيستم يك اخطار بهم ميده : نام كاربري شما دچار تخلف شده و هم اكنون تخلف شما به مدير گزارش شد! كمي ميترسم ! با خودم ميگم برنامه رو از طريق تسك منيجر ميبندم و دوباره سعي ميكنم ولي نه بعد از اجراي دوباره بازم همون پيغامو ميده و ميگه مدير بايد قفل و باز كنه...بهتر ميبينم بلند شم برم پي كارم تا گندش در نيومده... با خودم فكر ميكنم چرا بعد از ده بار اشتباه بايد پيغام بده چرا مثل بقيه برنامه ها بعد از 3 يا 4 بار اين اتفاق نيفتاد؟ اهان احتمالا كاربراي اينجا اينقد ناشي و كم حواسن كه معمولا بعد از 5-6 باز اشتباه تازه كلمه رمزشون يادشون مياد!


به عنوان خرابكار ميرم سراغ sql injection تجربه بهم ثابت كرده حتي برنامه هاي دسكتاپ و غير وب هم ميتونن اين ضعف بزرگ رو داشته باشن چندتا فرمان sql به جاي نام كاربر ميدم ولي اتفاقي نميفته چون به خوبي فرمانهاي كليدي sql رو موقع كد نويسي فيلتر كردن بيخيال اين روش......


با خودم ميگم كافيه رو سيستم يكي از كاربرا يك اسنيفر نصب كنم و اطلاعاتي كه در لحظه ورود از سيستمش وارد شبكه ميشه بدست بيارم شايد بتونم كاري كنم...بعد از انجام اينكار يك مشت اطلاعات كد شده وبي معني رو دستم موند به احتمال زياد اطلاعات بين سرور و كلاينت به صورت كد شده جابجا ميشه و clear text نيست اينم بي خيال...


اي بابا چرا زودتر به فكرم نرسيد؟ يك كيلاگر نصب ميكنم پسوردشو ميزنم هه هه .... بعد از بدست آوردن پسورد وقتي ميخوام وارد شم پيغام ميده كلمه رمز اشتباه است! يعني چي شده؟ ممكن نيست كاربر فهميده باشه و پسوردشو عوض كرده باشه.. از طرفي كي لاگرم خيلي دقيقه و اشتباه نميكنه پس مشكل چيه؟ 2 تا علت داره يكي اينكه احتمالا برنامه يك آنتي كي لاگر داره كه وقتي ميخواد كلمه رمز رو دريافت كنه با هوك كردن كيبورد بعد از دريافت كاراكتر از كاربر يك كاراكتر ديگه رو جايگزينش ميكنه و به سيستم پاس ميده واسه همين كي لاگرم با اينكه درست كار كرده ولي كلمه نادرست رو ثبت كرده... ولي نه برنامه نويساش دانش بالايي ندارن كه بتونن همچين كاري كنن پس احتمالا از كلمه رمز متغير استفاده كردن... اينم پس بيخيال...


من به عنوان يك خرابكار توانستم جدول مربوط به كاربرها رو در ديتابيس پيدا كنم ولي همه چي غير عادي به نظر مياد نميتونم نام كاربري خودم رو توش پيدا كنم گرچه تونستم رديف نام و نام خانوادگي خودم رو پيدا كنم ولي چيزي شبيه كلمه رمز و نام كاربري خودم تو اون رديف وجود نداره فقط يك رشته بسيار طولاني ميبينم كه نامفهومه معلوم نيست با چي هش شده ! به خودم ميگم احتمالا يك الگوريتم هشينگه جديده يا من دراوردي پس به اين راحتي نميشه فهميد چيه شايد تركيبي از MD5 , SHA512 باشه كه اگه باشه ديگه بايد برم بميرم ...ياد قديما ميفتم كه چقدر پسورد MD5 رو با BF پيدا كرده بودم ولي يه روز يه پسورد SHA به تورم خورد دهنم سرويس شد تا تونستم تو اينترنت يه برنامه درست حسابي براي BF كردن SHA384 پيدا كنم و تازه اون برنامه هم كه در نوع خودش بي نظير بود به بدبختي تونسته بود يك پسورد 6 كاراكتري خيلي ساده رو در عرض 24 ساعت كار بي وقفه پيدا كنه اگه يه زماني مجبور باشم يك پسورد SHA512 رو BF كنم چي ميشه؟ هيچي بايد تا قيامت صبر كنم ! تازه اگه ابزار مناسبي براش پيدا بشه!!! ولي اين چيزي كه من ميبينم اصلا شبيه هيچكدوم از الگوريتمهايي كه ميشناسم نيست .... اي بابا بيخيال......
با خودم فكر ميكنم كه همين رشته رو با رشته مدير جايگزين ميكنم شايد بتونم با كلمه رمز خودم و كاربر مدير وارد شم خوب نام كاربري مدير رو هم نميدونم چيه چون ديده نميشه فقط نام و نام خانوادگيشو ميبينم خوب حدس ميزنم كه admin باشه ولي با پيغام كلمه رمز اشباه است برق از كلم ميپره!


چيكار كنم؟ يه رفيقي دارم كه ختم مهندسي معكوسه يك روز يواشكي ميارمش اداره ميگم برنامه رو برام ريورس كنه و بگه چيكار ميتونيم بكنيم شايد بتونه الگوريتم رمزنگاريشو پيدا كنه..... اهان اومد با اون فلش ديسك كذاييش كه هميشه همراشه و معلوم نيست چه گندايي به سيستماي ملت باهاش زده...وصلش ميكنه به دستگاه يه مشت برنامه عجيب غريب اجرا ميكنه ميوفته به جون برنامه.... با دات نت و سي شارپ نوشتنش... خوب چي شد؟ صبر كن....خوب چي شد؟!!! اه چقد حرف ميزني بابا يه قفل خفن روش گذاشتن نميتونم ديكامپايلش كنم! ااااا تو مگه نميگفتي اگه با دات نت نوشته باشنش سه سوت سورسشو برام در مياري دخلشو مياري؟!!! اره گفتم ولي اين يكي خيلي خفنه با دوتا پروتكتور خيلي خفن قفلش كردن : SmartAssembly , InteliLock هيچي از سورس برنامه معلوم نيست ميبيني كه تموم برنامه هامو روش تست كردم نميتونن....اي بابا چيكار كنيم؟ فقط تو كل ايران 3-4 نفر ميتونن اين قفلو باز كنن كه اونا هم اهل كار خلاف نيستن...فايل اصلي برنامه يك فايل exe هست كه 15 مگابايت حجمشه ميدوني حتي اگه سورسشو در بياريم از اون همه كد درهم برهم چي ميخواي بفهمي؟ چون با Obfuscator كاملا بهم ريختنش...دور من يكيو خيط بكش مارفتيم....


كلمه رمز متغير چيه؟ اين اصطلاحو خودم در آوردم چند سال پيش وقتي تو يه بانك نشسته بودم متوجه شدم يكي از كارمندا از پشت سيستمش از دوستش پرسيد پسوردت چي بود؟
اونم گفت اسم پسرم : Reza و من هم اتفاقي شنيدم تو دلم خنديدم گفتم به به اگه يه روز بتونم واسه چند لحظه پشت اون سيستم بشينم چي ميشه ههه... بعد فكر كردم كه چجوري ميشه كاري كرد كه حتي اگه من پسورد يه نفر رو بشنوم حتي با نشستن پشت سيستم نتونم ازش استفاده كنم؟ راهي كه به ذهنم رسيد همين روش بود گفتم اگه تو صفحه لوگين كاربر بعد از وارد كردن اسم خودش مجبور باشه يه محاسبه كوچيك انجام بده به اين هدف ميرسم مثل اين سيستماي ضد ربات كه در قسمت جستجوي سايت استفاده شده كاربر مجبوره يك عكس كه به صورت تصادفي توليد شده رو بخونه و محتوياتش رو وارد كنه تا كارش انجام شه... ولي ميشه با يكم فكر پيچيده ترش كرد جوري كه هم سخت تر شه هم كاربراي معمولي هم بتونن راحت بفهمن و يادشون بمونه مثلا يك عدد تصادفي توليد شه كه كاربر اون رو در يك عدد خاص كه فقط خودش ميدونه ضرب كنه يا جمع كنه جوري كه خيلي سخت نباشه و نتيجه رو به سيستم بده...اينجوري من با داشتن كلمه رمز هم نميتونم كاري بكنم... اينر روش رو بعدها تو چند برنامه ديگه هم ديدم و فهميدم چند نفر ديگه هم قبلا مثل من فكرشون به اينجا رسيده بوده...




خسته شدم.... اين داستان ادامه داره اگه خوشتون اومد ادامش ميدم.... اگه نه ببخشيد ديگه...فعلا.

[علیرضا مداح]

@FH_prg
از ذکر نکات بسیار مفید شما و شرکت شما در این بحث سپاسگزارم ،



پسورد هش شده حتما بايد يك رابطه رياضي با نام كاربري داشته باشه تا قابل جايگذاري نباشه (مثلا ميتونه يك رابطه رياضي ساده يا پيچيده با CRC نام كاربر داشته باشه)


بله ، در اینصورت با تغییر نام کاربری ، پسورد کاربر هم تغییر خواهد کرد ، پس نفوذگر نمیتواند در صورت یافتن پسورد یک کاربر ، پسورد کاربر دیگری را با آن جایگزین کند ، البته اگر نام کاربری هم Hash شده باشد که پیدا کردن نام کاربری نیز بسیاز دشوار خواهد بود ،



بهتره براي اينكه از تداخلها و توليد پترنهاي يكسان جلوگيري كنيم هميشه نام كاربري رو با يك مقدار تصادفي جمع كنيم البته اين عمل فقط يك بار و در لحظه تعريف كردن نام كاربر اتفاق ميفته...

به این روش هم Salted Hash گفته میشود که پیش از این راجع به آن بحث شد ، اما مجددا" بر به کارگیری آن تاکید میشود ،



چندتا كلمه رمز پيش فرض دارم كه هميشه اول اونا رو چك ميكنم

میتوانیم در هنگام ایجاد پسورد و چک کردن Password Strength به کاربر اجازه ندهیم تا یکسری واژگان خاص یا ترکیبات آنها را در پسورد خود وارد کند ،



نام كاربري شما دچار تخلف شده و هم اكنون تخلف شما به مدير گزارش شد

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




به عنوان خرابكار ميرم سراغ sql injection تجربه بهم ثابت كرده حتي برنامه هاي دسكتاپ و غير وب هم ميتونن اين ضعف بزرگ رو داشته باشن چندتا فرمان sql به جاي نام كاربر ميدم ولي اتفاقي نميفته چون به خوبي فرمانهاي كليدي sql رو موقع كد نويسي فيلتر كردن بيخيال اين روش......


SQL Injection هم از حملات شایع است که برای جلوگیری از آن باید از Parameterized Queries و Stored Procedure ها استفاده نمود و برای امنیت بیشتر دیتا را نیز باید پیش از پاس دادن به SP و همچنین در داخل SP و پیش از اجرای کوئری اعتبارسنجی نماییم ،
در ضمن فیلتر کردن واژگان کلیدی SQL به تنهایی کافی نیست ، چون ممکن است خرابکار از معادل هگزادسیمال این واژگان استفاده کند ، پس باید سیستم در مقابل Hexadecimal SQL Injection نیز ایمن گردد ،





با خودم ميگم كافيه رو سيستم يكي از كاربرا يك اسنيفر نصب كنم و اطلاعاتي كه در لحظه ورود از سيستمش وارد شبكه ميشه بدست بيارم شايد بتونم كاري كنم...بعد از انجام اينكار يك مشت اطلاعات كد شده وبي معني رو دستم موند به احتمال زياد اطلاعات بين سرور و كلاينت به صورت كد شده جابجا ميشه و clear text نيست اينم بي خيال...



البته بسیاری از نرم افزارهای Sniffer ممکن است توسط ابزارهای امنیتی شناخته شده و به کاربر اطلاع دهند ، برای تبادل دیتا بین سرور و کلاینت پیشنهاد میشود از SSL استفاده کنیم تا اطلاعات رد و بدل شده به صورت Plain-Text/Clear-Text نباشند ،



اي بابا چرا زودتر به فكرم نرسيد؟ يك كيلاگر نصب ميكنم پسوردشو ميزنم

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




فقط يك رشته بسيار طولاني ميبينم كه نامفهومه معلوم نيست با چي هش شده ! به خودم ميگم احتمالا يك الگوريتم هشينگه جديده يا من دراوردي پس به اين راحتي نميشه فهميد چيه شايد تركيبي از MD5 , SHA512 باشه


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



يك پسورد 6 كاراكتري خيلي ساده رو در عرض 24 ساعت كار بي وقفه پيدا كنه

به خاطر همین موضوع است که باید مبحث Password Strength جدی گرفته شده و از ایجاد پسوردهای Weak جلوگیری به عمل بیاید ،



تو مگه نميگفتي اگه با دات نت نوشته باشنش سه سوت سورسشو برام در مياري دخلشو مياري؟!!! اره گفتم ولي اين يكي خيلي خفنه با دوتا پروتكتور خيلي خفن قفلش كردن : SmartAssembly , InteliLock هيچي از سورس برنامه معلوم نيست ميبيني كه تموم برنامه هامو روش تست كردم نميتونن

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

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


پ.ن :




خسته شدم.... اين داستان ادامه داره اگه خوشتون اومد ادامش ميدم.... اگه نه ببخشيد ديگه...فعلا.



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

[razavi_university]

1)از ابزارهای Protector همانند XenoCode و ... استفاده کنیم ،
2)اسمبلی مورد نظر ... Encrypt کرده ...

الف)نظر شما در رابطه با امنیت این روش چیست؟
ب)کلید عمومی(Public Key) یا کلید خصوصی(Private Key) در چه مکانی ذخیره گردد؟

/
استفاده از ابزارهای Protector مثل XenoCode و Termida و ... درسته که امنیت نسبتا خوبی رو می تونن تامین کنند ولی باید توجه داشته باشیم که این ابزارها برای تمامی کراکرها شناخته شده اند و بسیاری از الگوریتمهایی که این ابزارها استفاده می کنند پس از مدتی از عرضه آنها مشخص می شوند.
استفاده از روشهایی دیگری که Fh_prg گفتند فکرمی کنم بهتر است.

می توان برای بالا بردن ضریب امنیتی کلید عمومی یا خصوصی را در قفلهای سخت افزاری ذخیره کرد.

[علیرضا مداح]

كلمه رمز متغير چيه؟
این راهکار با نام (OTP(One-Time Password شناخته میشود ،
میخواهیم کمی بر روی این ایده بحث کنیم ،
یک پسورد استاتیک در چه زمانی تغییر می یابد؟
الف)کاربر پسورد خود را فراموش کرده و باید آن را Reset کند ،
ب)پسورد Expire شده است ،
ج)کاربر خود اقدام به تغییر پسورد کرده است ،

خوب این پسورد ها بر روی هارد درایو ذخیره میشوند ، پس مستعد نفوذ و کرک شدن هستند ،
بر خلاف پسورد استاتیک ، OTP در هر بار که کاربر قصد لاگین به سیستم را دارد تغییر میکند ، و عموما" به دو گونه زیر پیاده سازی میشود و کاربر باید یک سخت افزار کوچک را جهت هماهنگ سازی با سرور با خود حمل کند :


Time-Synchronized : در این روش کاربر باید پسورد را در یک بازه زمانی مشخص و پیش از Expire شدن آن وارد کند ، در غیر اینصورت باید پسورد جدید تولید شود ، البته این روش مشکل Clock Skew را نیز در پی خواهد داشت ، یعنی اگر سرور و توکن کاربر هر دو حامل یک "زمان" نباشند ، پسورد مورد نظر تولید نشده و درنتیجه عملیات اعتبار سنجی کاربر شکست میخورد ،
Counter-Synchronized : در این روش ، یک شمارنده(Counter) بین سرور و دستگاه کلاینت Synchronize شده و در هر بار که یک OTP درخواست میشود ، مقدار آن افزوده میشود ، در این هنگام ، همانند روش پیشین ، کاربر باید OTP ی را که بر روی دستگاه مشاهده میکند را وارد نماید ،
البته توجه داشته باشید که در دو روش فوق ، کاربر باید یک مقدار از پیش تعریف شده مانند PIN Code را برای تولید OTP وارد نماید ،/
جهت اطلاع بیشتر و ادامه بحث میتوانید به لینک زیر مراجعه نمایید :
MSDN Magaznine - Safer Authentication with a One-Time Password Solution (http://msdn.microsoft.com/en-us/magazine/cc507635.aspx)

[multiTech]

باسلام
مواردی که در لاگین کردن به حساب بانکم تا حالا برایم پیش اومده رو میگم ، شاید ایده مفیدی داخلشون باشه:

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

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

اگر مدتی - مثلا دو ماه - از آخرین لاگین به حسابم گذشته باشه ، خودبخود پسوردم اکسپایر میشه . باید پسورد جدیدی از بانک درخواست کنم.

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

[hdv212]

با تشکر از همه ی دوستان در این بحث مفید.
یه سوال برام پیش اومده و اون اینکه برای ایجاد یک بستر امنیتی در این سناریو، حتما باید امنیت با Password بررسی بشه ؟
استفاده از سنسور های Finger Print هم میتونه امنیت یک سیستم رو به صورت قابل قبولی برای ما تصمین کنه، به دلایل زیر :
1. حجم پردازش پسوردها توسط سیستم یا برنامه بسیار کم میشه، در نتیجه باعث افزایش کارایی میشه.
2. دقت بالایی دارند (برای یک موردی که سه چهار سال پیش روش کار میکردن، دقت آن تا یک در میلیارد قابل افزایش بود!)
3. ضمن اینکه ترکیب سنسور تشخیص اثر انگشت (Finger Print) و پسورد، میتونه امنیت بسیار بالایی رو برای ما تضمین کنه.
تا ببینیم نظر دوستان چیه.
متشکرم.

[anubis_ir]

يك مطلب رو بايد هميشه مد نظر داشت. افراد مسن.
عموما همين‌ها رئيس اون شركتي هستند كه قرار است شما برنامه اتوماسيون براشون بنويسيد.
نمي‌تونيد وادارشون كنيد هر ماه پسورد عوض كنند.
نمي‌تونيد وادارشون كنيد پسوردهاي طولاني و سخت انتخاب كنند. (سن بالا و حافظه نامرتب)
و مواردي از اين دست.

[علیرضا مداح]

ضمن اینکه ترکیب سنسور تشخیص اثر انگشت (Finger Print) و پسورد، میتونه امنیت بسیار بالایی رو برای ما تضمین کنه.
ایده جالبیست و میتوان بر روی آن بحث کرد ، اثر انگشت بدلیل Unique بودن و دقت بالای آن میتواند امنیت بالایی را تضمین کند ، اما باید دید که این ایده در چه سناریو هایی کاربرد دارد ، چون نیاز به یک دستگاه جهت اعتبارسنجی میباشد که ممکن است در دسترس نباشد ، در سیستم پیشنهادی شما ، پسورد و اثر انگشت چگونه با یکدیگر ترکیب میشوند؟



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

[hdv212]

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

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

[razavi_university]

چرا بحث خوابیده !!!

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

جناب مداح لطفا بحث جدید رو مطرح کنین . . .

[علیرضا مداح]

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