من تو قسمت امنیت چیچک به یه مشکل برخوردم که پرس و جو از دوستان و استاد ها برام نتیجه ای در بر نداشت. مساله اینه: چیچک یه فایل Properties داره که اطلاعاتی مثل نوع Look And Feel و وضعیت System Tray توی اون ذخیره می شه. از جمله چیز های دیگه که توی این فایل ذخیره می شه User name و Password وبسایت هایی مثل Twitter هستش که از نظر امنیتی این وضع خوبی نیست. من باید بتونم Password ها رو با یه الگوریتم بازگشت پذیر (دقت کنید که توابع Hash مثل MD5 به کار نمیاد) این ها رو کد کنم و در موقع نیاز اون ها رو بازیافت.
پیشاپیش بگم که RSA بهم جواب نمی ده یا حد اقل نمی تونم راهی به دست بیارم که با RSA این وضع رو کنترل کنم.
فراموش نکنید که چیچک یه برنامه ی Open Source هم هست و از هر الگوریتمی که استفاده کنم، به راحتی می شه الگوریتم رو خوند و پیدا کرد.
منتظر نظراتتون هستم.
بعد نوشت:
خب مساله رو می شه یکم تغییر داد به این صورت که من یه data دارم به اسم d و یه کلید عمومی دارم به pubKey و یه کلید اختصاصی دارم به نام privKey. خب d رو با pubKey کد می کنم (حالا با هر الگوریتمی) و d کد شده رو که اسمش cd هست رو یه جایی ذخیره می کنم. کنار cd هم می تونم برای کد کردن های بعد به راحتی pubKey رو ذخیره کنم. مشکل جدید این privKey هستش به این معنی که هر جایی که این رو ذخیره کنم، امنیت به خطر میفته و اگه این privKey رو نداشته باشم، از cd نمی تونم به d برسم. نمی تونم از حافظه ی کاربر برای نگه داری این privKey استفاده کنم چون:
- ممکنه این privKey مقدار خوش قلقی برای حفظ کردن نداشته باشه.
- کاربر ممکنه privKey رو فراموش کنه که در این صورت d هم از بین می ره.
- privKey رو الگوریتم به من می ده و نمی تونم خودم اون رو تولید کنم.
این ها برای الگوریتم های asymmetric بود ولی دقیقا همین مشکل رو برای الگوریتم های symmetric هم دارم.
نظر شما چیه؟
بعد نوشت:
الگوریتم AES (لینک تکمیلی) هم بررسی شد، جزو symmetric الگوریتم هاست و مشکل بالا همچنان برقراره.
راه حل:
بعضی از دوستان متن باز بودن رو مغایر با امن بودن دونستن. اما بالا خره من یه راه حل برای سوالم پیدا کردم. من الگوریتم AES رو پیاده می کنم و کلید رو توی خود سورس کد به صورت امن ذخیره می کنم. اینطور بعد از کامپایل کلید جای امنی خواهد داشت. اما چون اپن سورس هست پروژه، هرکسی که می خواد از سورس کامپایل کنه، می تونه کلید خودش رو توی سورس کد قرار بده. به همین راحتی!
به زودی این مشکل امنیتی چیچک رو برطرف می کنم.









عحب بابا!
واقع امر اینه که بعضی برنامهها اینا رو بصورت متنی و خیلی راحت ذخیره میکنن! مثل Pidgin و مشکلی هم نیست توش! چون پوشهی خانگی شما یک مکان امن حساب میشه! و خیلیها از یک درایو کدشده(Encrypted) استفاده میکنن!
اما راه دیگه ای که وجود داره ابزارهایی بنام Wallet یا KeyRing است! که شما پسورد رو بهش میدی و اون واست بطور امن نگهداری میکنه!
دسکتاپ Gnome واسه خودش Keyring داره! KDE هم یه KWallet داره! که برنامهها میتونن ازشون استفاده کنن!
بهترین حالت اینه که شما یه Wallet رو در نظر داشته باشی، ولی اگر در دسترس نبود بصورت متنی و ساده ذخیره کنی! یا انتخابش رو به عهدهی کاربر بزاری! ;)
نیازی هم به اون ماجراهای خفن که گفتی نیست! یعنی هیچ کس نمیاد واسهی تکتک برنامهها از اینکارا کنه!
[...] به صورت ناامن ذخیره میکرد. خب برای رفع این ضعف من مدتی روی الگوریتمهای مختلف کار کردم تا در نهایت این مشکل رو حل [...]
امنترین راه برای ذخیرهسازی پسورد استفاده از shadow هست که توی همهٔ یونیکسهای جدید از جمله گنو/لینوکس، برای ذخیرهسازی پسورد کاربران از این روش استفاده میشه. ماجرا از این قراره که shadow کردن یک متن، یه جور crypt کردن هست که decrypt براش تعریف نمیشه! یعنی crypt هست اما نمیشه بهش گفت encrype چون الگوریتمی برا decrypt کردنش کشف نشده.
وقتی شما توی گنو/لینوکس، پسورد کاربر خودتون رو ست میکنید(یا تغییر میدید) این پسورد هیچ جایی ذخیره نمیشه(در واقع root هم نمیتونه پسورد شما رو نمیدونه. حتی خود لینوکس هم نمیدونه) بلکه فقط سایه یا shadow پسورد شما ذخیره میشه(توی فایل etc/shadow/) و از روی shadow پسورد هم نمیشه به خود پسورد پی برد(مگه با روشهای مبتنی بر آزمون و خطا، که مخ یه سیستم رو مدت زیادی کار میگیرن تا پسورد رو کشف کنن، اونم اگه پسورد امن باشه مثلاً بیشتر از هفت هشت کاراکتر باشه و از انواع کاراکتر هم استفاده شده باشه کشف کردنش تقریباً محاله!).
حالا وقتی میخواید با کاربر خودتون لاگین کنید، پسوردی که وارد میکنید ازش shadow گرفته میشه و بعد با shadow اصلی که توی فایل etc/shadow/ ذخیره شده مقایسه میشه اگه یکی بودن، validate میشه و شما لاگین میشید.
از این امنتر روشی وجود نداره.
نمیدونم چطوری از این روش توی برنامهٔ جاوا میشه استفاده کرد. ولی برای C و ++C بلدم. کافیه توی ترمینال بنویسید
man 3 crypt
اول برنامهٔ C اینا رو باید بنویسیم:
#ifndef _XOPEN_SOURCE
#define _XOPEN_SOURCE
#endif
#include
برای shadow گرفتن از یه رشته هم از تابع crypt استفاده میشه.
char *crypt(const char *key, const char *salt);
آرگومان salt هم یه رشتهٔ دو بایتی هست که زیاد مهم نیست چی باشه. در واقع همون دو بایت اول shadow خواهد بود.
برای جاوا هم اگه سرچ کنید حتماً طرز استفاده از این روش رو پیدا میکنید.
مرسی دوست عزیز. خیلی استفاده کردم.
البته همون طور که متوجه شدی این روش برای برنامهی من کاربرد نداشت چون باید اطلاعات برگردونده بشه.
این روش که شما میگین خب یه روش Hash کردنه مثل md5 یا sha هستش.
و مرسی که در موردش برام توضیح دادی.
البته اگرم میشد من نمیتونستم توی جاوا استفاده کنم چون جاوا مستقل از بستره. یعنی بعد از این که کامپایل شد روی هر بستری که ماشین مجازی نصب میشه، میشه اون رو نصب کرد. باید یا خودم اون الگوریتم رو پیاده میکردم یا این که یه library به زبون جاوا گیر میاوردم.
خب فکر کنم سوتی دادم! چون پسوردها اصلاً قرار نیست توسط برنامه validate بشه. بلکه باید سیو بشه و به سرور ارسال بشه. اما بازم میشه از این روش کمک گرفت. یعنی پسوردهای encrypt و decrypt بشه با همون پسوردی که خود کاربر وارد میکنه(master password) برای validate کردن این master password هم از همون روش shadow استفاده بشه. اینم یه روش هست.
دوست عزیز این لینک رو هم ببینید:
http://saarblog.wordpress.com/2009/04/15/a-question/#comment-442
سلام آقارامین
من دانشجوی ترم اول نرم افزار هستم .بادیدن این وبلاگ خیلی مشتاق شدم از تجربیات شما استفاده کنم .میشه ایمیلتون رو داشته باشم؟
سلام بله، موردی نیست. این هم ایمیل آدرس بندست. البته اگر از قسمت تماس با منوبلاگ هم استفاده کنید باز هم برای من ایمیل ارسال میشه. موفق باشید با احترام