آموزش امنيت در پايگاههاي داده اي - بخش اول امنيت سرور

[moein_13 528]

امنيت در پايگاههاي داده اي - بخش اول

امنيت سرور

مقدمه

 

با گسترش استفاده از تکنولوژي وب و توسعه برنامه هايي که براي کارکرد درين بستر توليد ميشوند مباحث مربوط به امنيت پايگاههاي داده اي بعد جديدتري پيدا کرده اند. هر چند از آغاز پيداش پايگاههاي داده همواره امنيت و تامين آن يک دغدغه مهم و پياده سازي مناسب و کاراي آن يک خصوصيت بنيادي در پايگاههاي داده بوده است اما بهر روي بحث امنيت (Security)همواره در سايه مقولاتي همچون عملکرد مناسب (Functionality) ، کارايي (Performance) و قابليت اطمينان (Reliability) قرار ميگرفت. به عبارتي هنوز هم چندان عجيب نيست اگر ببينيم يک برنامه رده سازماني (Enterprise Level) با تعداد زيادي Client بدون هيچگونه ملاحظه امنيتي توليد شده و مورد استفاده باشد. حتي ميتوان درين زمينه مثالهاي جالبتري يافت. اغلب برنامه هاي Client-Server با نام کاربري sa(System Administrator) به پايگاههاي داده متصل ميشوند. از ديد امنيتي اين مطلب يک فاجعه محسوب ميشود. هيچ تغيير و يا خرابکاري اي قابل رديابي نيست، همه کاربران به همه اطلاعات دسترسي دارند و الي آخر.

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

اين وضعيت شايد در دنياي برنامه هاي مبتني بر تکنولوژي هاي Mainframe يا Client-Server قابل تحمل بود اما در شرايط فعلي که برنامه ها با سرعت زيادي به سمت بهره گيري از بستر وب ميروند ادامه اين روند فاجعه بار است. در حال حاضر ديگر کاربران يک برنامه به صورت بالقوه تنها کارمندان يک سازمان نيستند. هر فردي ميتواند به سادگي باز کردن يک مرورگر وب به پايگاه داده شما متصل شود و مطمئن باشيد اگر مکانيزمهاي امنيتي را رعايت نکرده باشيد ، حذف تمامي داده هاي شما حتس از عهده يک نفوذگر عادي هم بر مي آيد.

اجازه دهيد يک فرض اساسي را مطرح کنيم. مديران IT يک سازمان بر دو دسته اند: مديران نوگرايي که به صورت داوطلبانه سازمان را به سمت ارائه خدمات عمومي و گسترده هدايت ميکنند و به همين دليل تکنولوژي وب را به عنوان تنها بستر موجود براي ارائه اين خدمات ميپذيرند و مديران سنتي محافظه کاري که قابليت اطمينان و کارايي سيستم جاري را تحت هيچ شرايطي حاضر نيستند در معرض خطر قرار دهند. وب از نظر اين گروه دوم کماکان يک تکنولوژي مشکوک غير قابل اطمينان است. در واقع دلايل فني اين گروه دوم هنوز هم چشمگير و قابل اعتناست، به خصوص گروهي که از mainframe ها صحبت ميکنند. قابليت اطمينان 0.99999 هنوز هم در دنياي غير Mainframe يک روياست.

زماني که بحث امنيت در بستر وب مطرح ميشود به صورت عمده سه جزء زير مد نظر است:

 

• امنيت سرور(Server Security)
  
• امنيت در تصديق اعتبار(Authentication Security)
  
• امنيت محاوره(Session Security)
  

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

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

معماري امن شبکه با نگاه به پايگاه داده

الف. در نظر گرفتن سخت افزار جداگانه جهت سرور وب و سرور پايگاه داده

 

بسياري از سرويسهاي کنوني وب و حتي شبکه هاي داخلي (Intranet) به گونه اي طراحي شده اند که سرور اصلي پايگاه داده (Back End Server) را روي همان سروري در نظر ميگيرند که سرويس وب روي آن راه اندازي شده است. البته براي اين کار چندين توجيه وجود دارد :

 

• توجيه اقتصادي: در نظر گرفتن هر دو سرويس بر روي يک ماشين از جهت هزينه کل سازمان يک صرفه جويي محسوب ميشود. بايد توجه داشت که براي ارايه هر دوي اين خدمات ماشينهاي با قدرت پردازش بالا بايد در نظر گرفته شوند.
  
• توجيه فني: عده اي برين عقيده اند که ارائه اين دو خدمت بر روي يک ماشين سبب بهبود کلي کارايي ميشود. استدلال اصلي محدوديت سرعت بر روي شبکه است. اين استدلال نيز توجيه چنداني ندارد زيرا حداقل سرعت شبکه هاي محلي فعلي ۱۰۰Mb/s است که بسيار بالاتر از حداکثر سرعت شبکه هاي WAN در حال حاضر است.
  

بنابراين از دو توجيه بالا تنها استدلال مبتني بر صرفه جويي اقتصادي کماکان ميتواتند مطرح باشد. اما خطرات اجراي اين دو سرويس بر روي يک مکاشين به حدي ست که بهتر است سازمان به جاي پذيرش اين ريسکها، هزينه اضافي مربوطه را متحمل شود. تا کنون روشهاي متعددي براي نفوذ به سرورهاي وب طراحي و اجرا شده است. بسياري از ويروسهاي کامپيوتري و نيز کرمهاي اينترنتي (Code Redو Nimda) نيز اساسا بر پايه همين ضعفها عمل ميکنند. صرف نظر از نوع سرور وبي که در نظر ميگيريد (Apache،IIS يا هر سرور ديگر) هميشه بايد اين احتمال را بدهيد که در صورت وجود يک شکاف امنيتي در سرور مربوطه، شما در مجموع کمترين ضرر را متحمل شويد.

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

ب. قرار ندادن پايگاه داده در DMZ:

در صورتي که از يک معماري امن براي پياده سازي شبکه خود استفاده کرده باشيد به احتمال زياد شبکه شما داراي يک بخش DMZ(Don’t Militarized Zone) خواهد بود. معمولا ارائه دهندگان خدمات عمومي را درين بخش از شبکه قرار ميدهند. بعنوان مثال سرورهاي وب، سرورهاي ميل ... که همگي جهت خدمات عمومي بکار ميروند درين بخش از شبکه قرار دارند.

ايده عمومي داشتن يک بخش DMZ ساده ست: سرورهايي که خدمات عمومي بيرون سازماني ارايه ميدهند نيازمند سطح کمتري از امنيت هستند. در واقع همه ميتوانند به آنها دسترسي داشته باشند. اين دسترسي همگاني به هيچ وجه لازم نيست در مورد تمامي منابع شبکه اعمال شود. بنابرين منابع عمومي شبکه را در بخشي از شبکه قرار ميدهند که حساسيت امنيتي کمتري نسبت به آن وجود دارد. اين همان بخش DMZ است. با توجه به مطالب بالا بسيار بديهي به نظر ميرسد سرور پايگاه داده را بايد در همان بخش DMZ قرار دهيم زيرا که عموما اين سرور نيز مسئوليت ارائه خدمات همگاني را بعهده دارد. اما قضيه در باره سرور پايگاه داده تا حدي متفاوت است. اين سرور گرچه خدمات همگاني نيز عرضه ميکند اما تنها بخشي از داده هاي آن ممکن است جنبه همگاني داشته باشد در حالي که عمده آن در اغلب اوقات سري ست. بعنوان مثال سروري که اطلاعات مربوط به کارت اعتباري افراد را نگهداري ميکند از اهميت فوق العاده اي برخوردار است و هرگونه دسترسي به کل داده هاي آن ميتواند فاجعه بار باشد.

بنابراين بر خلاف ديد اوليه به اين نتيجه ميرسيم که پايگاه داده نميتواند و نبايد که در بخش DMZ قرار گيرد. اما راهکار جداسازي آن ازين بخش چيست؟

شکل ۱: پايگاه داده و DMZ

راه حل ايده آل براي اين جداسازي به شرح زير است: به صورت عام از يک فايروال اصلي براي ايمني کل شبکه و جداسازي آن از دنياي بيرون استفاده ميشود. اين فايروال در قسمت بيروني DMZ قرار دارد و داراي قواعد خاص خود است. بدلايلي که در بخش پيش ذکر شد که کلا عبارت بود از نياز به ارائه خدمات عمومي ،اين فايروال نميتواند کل ترافيک ورودي را محدود کند و ناچار است يک سياست (Policy) حداکثري را اعمال کند.

اما در داخل خود شبکه ، مابيت LAN داخلي و DMZ از فايروال دومي استفاده ميشود. اين فايروال دوم در حالت ايده آل تمامي ترافيک ورودي را سد ميکند بجز ترافيک ورودي از وب سرور به پايگاه داده. با اين تمهيد خاص هم پچايگاه داده خدمات عمومي خود را ارائه ميدهد و هم دستيابي عموم را به آن سد کرده ايم. درين صورت يک نفوذ گر حتي پس ازينکه کنترل کامل سرور وب را در اختيار گرفت ناچار است از قواعد سختگيرانه فايروال دوم نيز عبور کند و تازه پس ازان بايد بتواند به سرور پايگاه داده نيز نفوذ کند که انجام اين هر دو کار بسيار دشوار ميباشد و ريسک چنين شبکه اي عملا پايين مي باشد.

اما شايد در مقابل روش ما استدلالي اينچنين ارائه شود: ميتوان تنها با استفاده از يک فايروال امنيت را تامين کرد. روش آنهم اينست که براي سرورهاي پايگاه داده از IP مجازي استفاده کنيم. در واقع اين سرورها پشت يک NAT قرار داشته باشند. درين صورت نفوذگر اساسا از وجود پايگاه داده خبر ندارد تا بخواهد به آن نفوذ کند. اين استدلال يک ابراد عمده دارد و آنهم اينست که اگر نفوذ گر بتواند کنترل سرور وب را در اختيار بگيرد عملا در همان شبکه اي قرار گرفته است که سرور پايگاه داده دران قرار دارد و داراي همان رنج IP ميشود. بنابراين پس ازينکار در واقع تمهيد قبلي ما بلااثر ميشود و نفوذ گر ميتواند بسادگي مانند يک کاربر داخلي شبکه ما عمل کند.

حال که استدلالات فوق را پذيرفته ايم ميتوانيم کمي ايده آل تر باشيم و شبکه را ايمن تر کنيم. فرض کنيد که يک نفوذگر بتواند از لايه اول امنيتي شما عبور کرده وارد DMZ شود. اگر اين نفوذ به دليل نقص قواعد امنيتي فايروال شماره يک باشد احتمال نفوذ همين شخص به لايه دوم بسيار پايين است. اما اگر اين نفوذ به دليل وجود شکاف امنيتي خاصي بر روي فايروال باشد چطور؟ فرض کنيد به عنوان مثال هردو فايروال شما Check Point است. آنوقت نفوذگر بهمان سادگي که از لايه اول عبور کرده از لايه دوم امنيتي شما نيز خواهد گذشت چون هر دو فايروال ما از يک نوع است و طبيعتا شکاف امنيتي هردو يکسان است. بنابراين ميتوان پيشنهاد داد که فرضا اگر فايروال لاه اول شما Check Point است در لايه دوم بهتر است از PIX استفاده کنيد. اين مطلب باعث امنيت بالاتر شبکه شما خواهد شد.

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

راه حل ديگري که ميتوان براي جداسازي بخش امن شبکه ارائه داد استفاده از بيش از يک کارت شبکه در فايروال است (شکل ۲)

شکل ۲: استفاده از دو کارت شبکه براي جداسازي DMZ

همانطور که مشخص است درين روش توسط يک فايروال، DMZ از بخش امن شبکه جداسازي ميشود. تنها ترافيکي که حق عبور از اينترفيس اول (eth1) به اينترفيس امن (eth2) را دارد ترافيک ورودي از وب سرور به سرور پايگاه داده ميباشد. اين روش بسيار ارزان تر از روش قبلي ست اما مشخصا امنيت آن در حد امنيت روش قبل نيست و علاوه برآن ممکن است فايروال موجود ما عملا از چندين کارت شبکه پشتيباني نکند.

علاوه بر دو راهي که در فوق براي جداسازي پايگاه داده از مابقي شبکه ارائه داديم راه حل سومي هم وجود دارد: اينکه اساسا پايگاه داده را از مابقي شبکه جدانکنيم! دقت کنيد که با توجه به هزينه و نيز اندازه سازمان ممکن است جداسازي امکان پذير نباشد و حتي مجبور شويم که اين دو سرور را برروي يک ماشين اجرا کنيم. حتي درين صورت نيز بهتر است حداقل کارهايي که جهت ايمني مضاعف پايگاه داده از دستمان بر مي آيد انجام دهيم. بعنوان مثال ميتوانيم از يک فايروال نرم افزاري ارزان قيمت جهت ايمني بيشتر استفاده کنيم. بهر حال اين راه حل توصيه نميشود مگر در شرايط اجبار.

ج. رمز نگاري اطلاعات مابين سرور وب و سرور پايگاه داده

 

براي جلوگيري از سرقت اطلاعات در بين راه(Sniffing) عموما از روشهاي رمز نگاري استفاده ميشود. متداول ترين روش تحت وب براي انجام اين منظور استفاده از پروتکل SSL است. عموم اطلاعات امن که بر روي اينترنت منتقل ميشوند از همين پروتکل استفاده ميکنند . بعنوان مثال انتقال اطلاعات شناسايي با سرورهاي معروف ايميل، انتقال اطلاعات مربوط به کارت اعتباري و غيره.

تا بدينجا اين پروتکل که اغلب سرورهاي وب و نيز مرورگرها ازان پشتيباني ميکنند سطحي از امنيت را تامين ميکند. اما آيا همين کافي ست؟

اغلب اين اشتباه پيش مي آيد که همين سطح از رمز نگاري را در مقابل حمله Sniffing کافي ميدانند. بايد دقت کرد که SSL به صورت عام تنها براي رمزنگاري اطلاعات مابين Client و سرور وب به کار ميرود و به صورت عادي اطلاعات مابين وب سرور و سرور پايگاه داده به صورت عادي و بدون رمزنگاري (Plain Text) منتقل ميشوند. بنابراين حتي اگر همه جوانب را در شبکه بيروني رعايت کرده باشيم، يک نفوذگر داخلي به سادگي ميتواند اطلاعات در حال انتقال مابين اين دو سرور را شنود کند. اين مطلب زماني بسيار جدي ميشود که بدانيم بر اساس داده هاي موجود، بالاتر از ۶۰٪ حملات موجود حملات درون سازماني مي باشد.

چاره کار استفاده از يک روش رمز نگاري مابين سرور وب و سرور پايگاه داده است. اغلب سرور هاي پايگاه داده امروزه از SSL حمايت ميکنند. MS SQL Server2000 ، Oracle،Sybase ازين جمله اند. البته استفاده از SSL براي ارتباط مابين اين دو سرور لازمه اش اينست که برنامه اصلي شما (Web Application) با همين ملاحظه طراحي و پياده سازي شده باشد.

اما در صورتي که برنامه شما از قبل موجود باشد يا از SSL پشتيباني نکند يا به هر صورت شما مايل به ايجاد هزينه اضافي نباشيد چه؟ آيا راه حل ديگري براي رمزنگاري مابين دو سرور وجود دارد؟ خوشبختانه چنين راه حلي وجود دارد: استفاده از SSH يا يک برنامه مشابه.

اصولا SSH برنامه اي شبيه Telnet است اما نسخه امن آن. يکي از قابليتهاي SSH ايجاد يک تونل امن است. به اين صورت که ميتوان برنامه SSH را به گونه اي اجرا کرد که بر روي يک پورت شنود کند کل اطلاعات آن را رمز کرده به کامپيوتر مقصد ارسال کند و آنجا پس از تبديل به حالت عادي به پورت مقصد تحويل دهد. با استفاده از اين روش (SSH Port Forwarding) يک تونل امن به صورت شفاف مابين دو سرور ايجاد شده است(شکل ۳).

شکل ۳: استفاده از SSH براي برقراري تونل امن

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

د. عدم استفاده از Hub و بهره گيري از Switch

به صورت عادي زماني که از Hub استفاده ميکنيم تمامي اطلاعات عبوري در هريک از سيستمهاي موجود در شبکه داخلي قابل شنود است. يک نفوذ گر معمولي با استفاده از يکي از ابزارهاي Sniffing ميتواند اينترفيس شبکه با به حالت Promiscuous برده ، تمامي اطلاعات در حال جابجايي بر روي LAN را دريافت کند. البته استفاده از رمز نگاري خطر بالقوه بهره گيري ازين روش را کم ميکند اما هيچگاه نميتوان مطمئن بود که کل اطلاعات رمز نگاري شده است. بنابراين بهتر است حتي المقدور امکان بهره گيري از Sniffing را بر روي شبکه کاهش دهيم. استفاده از سوپيچها به جاي هاب يکي از روشهاي حل اين مساله است. با استفاده از سوئيچ در واقع يک مدار مجازي (Virtual Circuit) مابين دو نود در حال مکالمه ايجاد ميشود و ديگران به اطلاعات در حال انتقال مابين آن دو دسترسي ندارند.

۲-۶. ارائه امن اطلاعات

از ديد کلي امنيت اطلاعات براي ارائه خدمات اطلاع رساني بر روي وب به صورت عمده دو راه وجود دارد:

 

• توليد اطلاعات به صورت استاتيک
  
• توليد اطلاعات به صورت ديناميک
  

 

۱-۲-۶. توليد اطلاعات به صورت استاتيک و مسائل امنيتي آن

 

معمولترين نوع دسترسي به اطلاعات در اينترنت استفاده از صفحات HTML است. هنوز هم بسياري از متخصصين، اين روش در دسترس گذاري اطلاعات (Web Publishing) را به روشهاي ديگر ترجيح ميدهند. البته دلايل اصلي آنها بيشتر مربوط به سادگي و قابليت انعطاف اين روش است.

درين روش اطلاعات يک بار توليد ميشود. توليد اطلاعات (صفحات HTML) ميتواند به صورت دستي يا به صورت اتوماتيک توسط برنامه هاي معمولي Client-Server انجام شود. پس از انجام اين فاز کليه اطلاعات بر روي سايت و سرور اصلي قرار ميگيرد (Upload).

امنيت اين روش به سادگي تامين ميشود. کافيست که اشخاص نام فايلهاي HTML را ندانند، درين صورت هرگز به آنها دسترسي نخواهند داشت. اينکار با استفاده از مکانيزم ساده اي صورت ميگيرد. عموم وب سرورها براي دايرکتوريهاي مختلف حق دسترسي تعريف ميکنند که يکي ازين حقوق دسترسي حق مشاهده محتويات يک دايرکتوري است. در صورتي که کاربري اين حق را نداشته باشد از اسامي فايلها بي خبر خواهد بود و در نتيجه قادر به مشاهده آنها نيست.

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

۲-۲-۶. توليد اطلاعات به صورت ديناميک

 

اين روش متداول ترين شيوه ايست که امروزه جهت ارائه خدمات بر بستر وب مورد استفاده قرار ميگيرد. درين روش صفحات موجود بر روي سرور وب عملا داراي هيچ اطلاعاتي نميباشند يا داراي حداقل اطلاعات هستند. تمامي اطلاعات در پايگاه داده است. به محض دريافت هر تقاضايي توسط سرور وب ، صفحات مورد درخواست او به صورت ديناميک از طريق جستجوي (Query) مناسب در پايگاه داده توليد ميشود.

براي پياده سازي اين روش طيف وسيعي از تکنولوژيها وجود دارد. ASP،JSP،PHP،CGI،ISAPI... و چندين روش ديگري که عم��ما حول همين توليد�ديناميک اطلاعات ��ر محيط�وب طراحي شده اند. �منيت هريک ازين زبانها و روشها خود � موضوع ب�ث مفصل و جداگانه �يست اما از ديد بح� حاضر چند نکته مه� را با�د مد نظر داشت:

 

�

• � تا ک��ون شکافهاي � جدي امنيتي در مورد هر يک ازين �وشها شناخته شده ��ست و با وجود � حل اغلب آن��ا هنوز هم هيچکدام�آنها امنيت بالاي�� را به تنهايي � تضمين نميکنند. �
  
• � با و�ود نکته � بالا، چون هدف ��صلي ارائه خدمت يا�سرويس است در بسيا�ي موارد � چاره اي بجز اس��فاده از يکي ازين ��وشها نداريم.
  
• هنگام انتخ��ب هري� ازين روشها بايد �لاحظات امنيتي مر�وط به ابزارهاي مديريت � توسعه را نيز لحاظ کنيم. �
  

� � طي بخش گذشته عموما توجه ما معطوف به اين مطلب بود که چگونه جلوي دستيابي افراد غير مجاز به سيستم و اطلاعات گرفته شود. اما هيچ گاه به اين مطلب اشاره نکرديم که مجاز يا غير مجاز بودن افراد را چگونه تشخيص ميدهيم. در واقع روش شناسايي افراد در يک سيستم امن چگونه ميتواند باشد.

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

· تمامي اطلاعات در بين راه قابل شنود هستند.

 

 

• بند بالا به خصوص شامل خود نام کاربري و کلمه عبور هم ميشود. به عبارتي اين دو هم به سادگي ميتوانند توسط شخص ثالثي در بين راه شنود شده و بعدا مورد استفاده قرار گيرند.
  
• در شرايطي که نام کاربري و کلمه عبور لو رود کل امنيت سيستم دچار اخلال خواهد شد.
  

در واقع اين روش تنها تضمين کننده حداقل غير قابل قبولي از امنيت در تصديق اعتبار افراد است. بنابراين بايد به دنبال روشهاي جايگزيني بود که معايب فوق را نداشته باشند.