نظر به اینکه بیشتر برنامه نویسان از security through obscurity برای تامین امنیت برنامه هاشون استفاده میکنن، گفتم تا این تاپیک رو در این باره استارت کنم.
-----------------------------------
security through obscurity یک اصطلاح تنزل دهنده است که به یک قاعده در مهندسی امنیت اشاره دارد که تلاش میکند از طریق محرمانگی طراحی یا پیاده سازی امنیت را تامین کند.
یک سیستم که بر security through obscurity اتکا دارد ممکن است آسیب پذیری های تئوریک یا عملی داشته باشد، اما مالکان یا طراحان اعتقاد دارند که اگر ضعفها دانسته نشوند، نامحتمل است که دشمنان آنها را بیابند.
یک سیستم ممکن است از security through obscurity بعنوان دفاع در عمق (defense in depth) استفاده کند؛ درحالیکه همهء آسیب پذیری های امنیتی از طریق راههای دیگر تخفیف داده میشوند، افشای عمومی محصولات و نسخه های درحال استفاده آنها را هدفهای اولیه برای آسیب پذیری های جدید کشف شده در آن محصولات و نسخه ها میسازد. قدم اول یک نفوذگر معمولا جمع آوری اطلاعات است؛ این قدم بوسیلهء security through obscurity به تاخیر انداخته میشود. این تکنیک در تضاد با امنیت بر اساس طراحی (security by design) و امنیت باز (open security) است، هرچند بسیاری از پروژه های دنیای واقعی عناصری از تمام استراتژی ها را دارند.
امنیت بر اساس تیرگی (Security through obscurity) هیچوقت بعنوان یک خط مشی برای تامین امنیت یک سیستم مورد پذیرش مهندسی واقع نشد، چراکه آن با قاعدهء «ساده نگه داشتن» (keeping it simple) در تضاد است. انستیتوی ملی استانداردها و فناوری ایالات متحده (NIST) بخصوص برضد آن در بیش از یک سند توصیه میکند. نقل قول از یکی از آنها: « امنیت سیستم نباید بر محرمانگی پیاده سازی یا اجزای آن متکی باشد ».
منبع: http://en.wikipedia.org/wiki/Security_through_obscurity
عموما، طراحی هایی بخوبی کار میکنند که بر امنیت از طریق تیرگی استوار نباشند. آن اجباری نیست، اما امنیت مناسب معمولا به معنای آنست که همه کس اجازه دارند تا طراحی را بدانند و بفهمند زیرا « آن امن است ». این مزیت این را دارد که افراد بسیاری به کد نگاه میکنند، و این شانس آنکه هر ضعفی زودتر کشف شود را افزایش میدهد (قانون لینوس). البته نفوذگران همچنین میتوانند کد را بدست بیاورند، که یافتن آسیب پذیری ها را برای آنها ساده تر میکند.
منبع: http://en.wikipedia.org/wiki/Security_by_design
هرچند اتکا بر امنیت از طریق تیرگی تقریبا همیشه یک تصمیم طراحی بسیار ضعیف است، محرمانه نگه داشتن بعضی از جزییات سیستمی که از قبل به خوبی طراحی شده است میتواند یک تاکتیک معقول بعنوان بخشی از استراتژی دفاع در عمق باشد. برای مثال، امنیت از طریق تیرگی ممکن است (اما نمیتواند تضمین شود) بعنوان یک سرعت گیر موقتی برای نفوذگران عمل کند درحالیکه یک تصمیمگیری برای یک مشکل امنیتی پیاده سازی میشود. اینجا هدف به سادگی کاهش دادن ریسک کوتاه مدت سوء استفاده از یک آسیب پذیری در اجزای اصلی سیستم است.
یک اجماع عمومی وجود دارد، حتی درمیان آنهایی که به طرفداری از امنیت از طریق تیرگی استدلال میکنند، که امنیت از طریق تیرگی هرگز نباید بعنوان یک راهکار امنیتی اصلی استفاده شود. آن در بهترین حالت یک راهکار ثانویه است؛ و فاش شدن تیرگی نباید منجر به نفوذ شود.
علاوه بر این، آسیب پذیری ها در نرم افزارها کشف شده و مورد سوء استفاده قرار گرفته اند، حتی وقتیکه جزییات داخلی محرمانه باقی مانده اند. این و دیگر مثالها نشان میدهند که محرمانه نگه داشتن جزییات سیستمها دشوار یا غیرموثر است.
اپراتورها و توسعه دهندگان/فروشندگان سیستمهایی که بر امنیت از طریق تیرگی اتکا میکنند ممکن است این واقعیت که امنیت سیستم شکسته شده است را محرمانه نگه دارند تا از نابودی اعتماد به سرویس یا محصول آنها و در نتیجه از بین رفتن قابلیت رقابت بازاری آن جلوگیری کنند، و این میتواند معادل کلاهبرداری براساس نادرست جلوه دادن امنیت محصولات آنها باشد. نمونه هایی از شرکتهایی که انتشار فیکس ها یا پچ ها را برای وفق یافتن با اولویت های شرکتی خودشان، بجای نگرانی ها یا ریسک های مشتریان، به تاخیر انداخته اند حداقل از دههء 1960 شناخته شده اند.
منبع: http://en.wikipedia.org/wiki/Security_through_obscurity
یک سیستم رمزنگاری باید امن باشد حتی اگر همه چیز دربارهء سیستم، بجز کلید، دانش عمومی باشد.
قانون کرکهف توسط کلود شانون (ریاضیدان، مهندس الکترونیک و رمزنگار معروف آمریکایی است که به عنوان پدر نظریه اطلاعات شناخته میشود) دوباره به شکل دیگری (احتمالا بطور مستقل) ارائه شد: « دشمن سیستم را میشناسد ». برخلاف امنیت از طریق تیرگی، این قانون بصورت گسترده توسط متخصصان رمزنگاری پذیرفته شده است.
یکی از اصول کرکهف درمورد سیستم رمزنگاری: « نباید نیاز باشد که سیستم محرمانه نگه داشته شود، و باید این امکان وجود داشته باشد که سیستم به دست دشمن بیفتد بدون اینکه باعث دردسر شود. »
فرض بر این است که استفاده از یک سیستم رمزنگاری امن مسئلهء دشوار محرمانه نگه داشتن پیامها را با یک مسئلهء بسیار قابل مدیریت تر محرمانه نگه داشتن کلیدهای نسبتا کوچک جایگزین میکند. یک سیستم که به محرمانگی طولانی مدت چیزی به بزرگی و پیچیدگی کل طرح یک سیستم رمزنگاری نیاز دارد واضحا نمیتواند به آن هدف برسد. آن فقط یک مسئلهء دشوار را با مسئلهء دشوار دیگری جایگزین میکند. اگر یک سیستم حتی وقتی دشمن همه چیز بجز کلید را دربارهء آن میداند امن باشد، سپس همهء چیزی که نیاز به مدیریت دارد محرمانه نگه داشتن کلیدها است.
Bruce Schneier (متخصص مشهور امنیت و رمزنگاری): « قانون کرکهف فراتر از کدها و رمزها به امنیت سیستمها در کل اعمال میشود: هر چیز محرمانه یک نقطهء شکست احتمالی را ایجاد میکند. به بیان دیگر، محرمانگی یک عامل اصلی شکنندگی است - و بنابراین چیزی است که یک سیستم را مستعد فروپاشی فاجعه بار میکند. برخلاف آن، باز بودن باعث انعطاف پذیری میشود. »
هر سیستم امنیتی بصورت حیاتی بر محرمانه نگه داشتن بعضی چیزها متکی است. اما قاعدهء کرکهف اشاره میکند که چیزهایی که باید محرمانه نگه داشته شوند آنهایی هستند که هزینهء تغییر آنها درصورتیکه بصورت غیرعمدی افشا شدند کمترین مقدار است.
برای مثال یک الگوریتم رمزنگاری ممکن است بوسیلهء سخت افزار و نرم افزاری که بصورت گسترده بین کاربران توزیع شده است پیاده سازی شود. اگر امنیت بر محرمانه نگه داشتن آن استوار باشد، سپس افشا شدن منجر به دشواری های بزرگ لجستیک در توسعه، تست و توزیع پیاده سازیهای یک الگوریتم جدید میشود. آن شکننده است. اما اگر محرمانه نگه داشتن الگوریتم مهم نباشد، فقط کلیدهای استفاده شده با الگوریتم باید محرمانه نگه داشته شوند، سپس درصورت افشا شدن کلیدها نیاز است تا عملیات ساده تر و کم هزینه تر تولید و توزیع کلیدهای جدید انجام شود.
الگوریتم های رمزنگاری استفاده شده برای حفاظت از اطلاعات طبقه بندی شدهء حکومتی یا نظامی اغلب محرمانه نگه داشته میشوند. اما نباید فرض شود که الگوریتم های رمز حکومت/ارتش برای حفظ امنیت باید محرمانه نگه داشته شوند. ممکن است درنظر گرفته شده باشد که آنها همانقدر از نظر رمزنگاری معقول باشند که الگوریتم های عمومی هستند، و تصمیم برای محرمانه نگه داشتن آنها در جهت یک دیدگاه امنیت لایه بندی شده باشد.
Eric Raymond: هر طراحی نرم افزار امنیتی که فرض نمیکند دشمن کد منبع را دراختیار دارد غیرقابل اعتماد است؛ بنابراین، هیچوقت به نرم افزار کدبسته اعتماد نکنید.
John Savard: اینکه امنیت یک الگوریتم رمز باید بر کلید و نه الگوریتم استوار باشد به یک حقیقت بدیهی در عصر رایانه تبدیل شده است، و این بیادماندنی ترین از گفته های کرکهف است. ... برخلاف یک کلید، یک الگوریتم میتواند بوسیلهء متخصصان برای تعیین اینکه آیا امن بودن آن محتمل است تحلیل شود. یک الگوریتم که شما خودتان اختراع کرده اید و محرمانه نگه داشته اید فرصت چنان بررسی ای را نداشته است.
Steve Bellovin: ... به بیان دیگر، سیستم خود را با این فرض که مخالفان شما آنرا با تمام جزییات میدانند طراحی کنید (یک مقام سابق مرکز امنیت ملی رایانه در آژانس امنیت ملی (NSA) به من گفت که فرض استاندارد در آنجا این بود که شماره سریال یک هر دستگاه جدید به کرملین تحویل داده شده است). پس از آن، هرچند، اینکه تلاش کنید آنرا محرمانه نگه دارید اشتباه نیست. آن یک فاکتور مانع دیگر برای دشمن است که باید بر آن غالب شود (یک مانع که بریتانیایی ها وقتی به سیستم انیگمای آلمانی حمله کردند با آن مواجه شدند ساده بود: آنها نگاشت سادهء بین کلیدهای کیبورد و ورودی به آرایهء روتور را نمیدانستند). اما، *بر سری بودن اتکا نکنید*.
منبع: http://en.wikipedia.org/wiki/Kerckhoffs%27_principle
-----------------------------------
خب این مطالب رو گذاشتم تا اطلاعات عمومی برنامه نویسان در این زمینه بالا بره. چون واضحا بصورت گسترده و شدیدی مشاهده میشه که برنامه نویسان بر امنیت از طریق تیرگی، یا الگوریتم ها/روشهای امنیتی که خودشون بدون دانش تخصصی و تحقیق کافی طراحی کردن، بعنوان اساس یا یکی از عوامل مهم امنیت برنامه اتکا میکنن.
درواقع این روشها و کدها اغلب وقتی از دید تخصصی بررسی بشن بسیار ناقص و ضعیف هم هستن.
حتی در خیلی از این موارد یک هکر با دانش و هوش و انگیزه/پشتکار کافی حتی بدون داشتن کدمنبع میتونه الگوریتم رو حدس بزنه و به کمک تستهای ساده کشف کنه و مورد سوء استفاده قرار بده.
درکل نباید بر محرمانه بودن الگوریتم اتکا کرد. همهء متخصصان باوجود اختلاف نظر در بعضی جزییات در یک مورد اجماع نظر دارن: سیستم باید اصولی و طوری طراحی بشه که اگر تمام جزییاتش بدست نفوذگر افتاد دچار فروپاشی نشه و همچنان امنیت معقولی داشته باشه. یعنی باید با این فرض که کدمنبع در دسترس همگان هست برنامه امن طراحی بشه.
طبیعتا ما روشهای اصولی کافی هم برای تمام سناریوهای متداول داریم. اما متاسفانه بیشتر برنامه نویسان ظاهرا از این روشها و علت و اهمیت استفاده از اونها اطلاع ندارن و همچنان میخوان به میانبر ساده اما غیراصولی و ضعیف «امنیت از طریق تیرگی» پناه ببرن.
بنده این مطالب رو دادم که حداقل کسانی که نمیدونن و بخاطر ندانستن اصول صحیح طراحی یک برنامهء حرفه ای از روش اشتباه استفاده میکنن مطلع بشن و به یادگیری و پیروی از روشهای اصولی رو بیارن.
بعد از اینکه سیستم اصولی و با استفاده از روشهای استاندارد و مورد بررسی و تست و تایید متخصصان طراحی شد، میشه در بعضی موارد مقداری تیرگی رو هم برای امنیت بیشتر/امنیت در عمق/امنیت چند لایه پیاده سازی کرد.
نمیدونم واقعا این برنامه های زیادی که تمام یا بخش مهمی از امنیت اونها بر پنهان نگه داشتن کد منبع و الگوریتم متکی هستن چه جایگاهی در دنیای امنیت واقعی و برنامه نویسی قابل قبول حرفه ای دارن. درواقع هیچ! این برنامه ها به هیچ وجه حرفه ای نیستن. این برنامه ها استانداردهای حداقلی رو رعایت نکردن. از کار زده شده. در خیلی موارد برنامه نویس اصلا سواد و توان لازم رو نداشته و نمیدونسته چنین چیزهایی هم وجود دارن و روش صحیح چیه.
در دنیای بازمتن هم که مسلما کلا نمیشه از این روش استفاده کرد.
اگر میخوایم حرفه ای باشیم و برنامه نویسی واقعی بکنیم، یک برنامه نویسی باکیفیت و قابل اعتماد، باید از روش اصولی پیروی کنیم. و بدیهی هست اول باید دانش تئوریک لازم رو بدست بیاریم. صرفا با کد زدن و تجربهء عملی نمیشه به خیلی چیزها رسید.
پاسخ با نقل قول