محافظت از رشته های حیاتی در زبانهای دات نت

[OHidden]

سلام دوستان

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

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

[Securebit]

شما باید از مبهم سازهای خصوصی (Private) استفاده کنید برای مبهم سازهای خصوصی Deobfuscator وجود ندارد.

[OHidden]

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

[pswin.pooya]

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

این در مورد زبانهای دیگه هم صادقه اما با یکم تغییرات میشه کد رو از دست ۹۹ درصد کرکر ها مخفی کرد و کاری کرد که بهش نرسن.

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

[Securebit]

یکی از دوستان پیشنهاد دادن رشته های حیاتی رو در قفل سخت افزاری ذخیره کنیم و هر موقع که لازم شد از اونها استفاده کنیم.این کار برای نرم افزارهایی که دارای قفل نرم افزاری هستند جوابگو نیست
به نظر شما استفاده از dllی که به زبان C++‎ نوشته شوند و رشته ها رو داخل اون کریپت کنیم چطوره؟ آیا امنیت این رشته ها تا حدودی حفظ خواهد شد؟

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

[pswin.pooya]

به نظر شما استفاده از dllی که به زبان C++‎ نوشته شوند و رشته ها رو داخل اون کریپت کنیم چطوره؟ آیا امنیت این رشته ها تا حدودی حفظ خواهد شد؟

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



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

قفلهای سخت افزاری به راحتی قابل شبیه سازی هستن و اکثر قفلها رو راحت می شکست به جز یه تعداد محدود که قیمت های زیادی دارن چند سال پیش حدود ۱۴۰ تومن اینا بودن (هر عدد)

[OHidden]

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



دقیقا; همونطور که فرمودید یکی از مشکلات این کار دسترسی به dll ساخته شده هست
وقتی کاربر سورس نرم افزار رو ببینه طبیعتا می تونه توابع فراخوانی شده dll رو ببینه و از اونها استفاده کنه

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

اما به چه طریقی یا راهکاری میشه کارکرد صحیح dll رو منوط به اجرا شدن نرم افزار ما برنامه نویسی کرد؟

[ali ahwaz top]

سلام:
1-چرا پسو
رد بانک اطلاعاتی و یوزر و پسورد وب سرویس ارسال پیامک و... رو مستقیم توی نرم افزار قرار میدید؟
2-قفل سخت افزاری هیچوقت نمیتونه مشکل شما رو در رابطه با لو نرفتن این قبیل اطلاعات حل کنه.
3-چرا یک سیستم حساب کاربری راه اندازی نمیکنید؟

[OHidden]

سلام:
1-چرا پسو
رد بانک اطلاعاتی و یوزر و پسورد وب سرویس ارسال پیامک و... رو مستقیم توی نرم افزار قرار میدید؟
2-قفل سخت افزاری هیچوقت نمیتونه مشکل شما رو در رابطه با لو نرفتن این قبیل اطلاعات حل کنه.
3-چرا یک سیستم حساب کاربری راه اندازی نمیکنید؟



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


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

[ali ahwaz top]

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

[negative60]

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


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

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

[OHidden]

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

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

[cmsdqq2]

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


دوستان سلام، میدونی تاپیک قدیمی هست اما مسئله ای هست که حل نشده. بنده هم سوال ایشون رو داشتم میخواستم بدونم برای این موضوع چه راه حلی هست؟

این روش به نظر من زمانی پاسخگو هست که موارد شخصی باشه؛ اما اگر از یک سری شرکت ها / وب سایت های وب سرویس گرفته شد، چه باید کرد؟