ذخيره كردن رشته اتصالي به ديتابيس، به صورت يك رشته مشخص در كدهاي برنامه، كاري است مزموم. زيرا پس از هر بار تغيير اين مورد، نياز خواهد بود تا تمامي سورس‌ها تغيير كنند و اگر از حالت web application استفاده كرده باشيد، مجبور خواهيد شد يكبار ديگر برنامه را كامپايل و دايركتوري bin روي سرور را به روز كنيد. به همين جهت، استاندارد برنامه‌هاي ASP.Net اين است كه اين رشته اتصالي را در فايل web.config ذخيره كنيم تا با هر بار تغيير پارامترهاي مختلف آن (مثلا تغيير نام سرور، يا تعويض ماهيانه پسوردها)، مجبور به كامپايل مجدد برنامه نشويم. شبيه به همين مورد در برنامه‌هاي PHP هم رايج است و عموما اين مشخصات در فايل config.php و يا با اسامي شبيه به اين صورت مي‌گيرد.
در ASP.Net 1.x قسمت خاصي براي كانكشن استرينگ وجود نداشت اما از ASP.Net 2 به بعد ، قسمت ويژه‌اي مخصوص اين كار در فايل web.config در نظر گرفته شده است.
خيلي هم خوب! اما اين تجربه تلخ كاري را (كه يكبار براي من رخ داد) هم همواره در نظر داشته باشيد:
امكان خوانده شدن محتواي فايل كانفيگ، توسط همسايه شما در همان هاست اشتراكي كه الان از آن داريد استفاده مي‌كنيد. عموما هاست‌هاي اينترنتي اشتراكي هستند و نه dedicated و نه فقط مختص به شما. از يك سرور براي سرويس دهي به 100 ها سايت استفاده مي‌شود. يكبار در يكي از سايت‌ها ديدم كه فايل machine.config سرور را هم محض نمونه خوانده بودند چه برسد به فايل متني كانفيگ شما! يا تصور كنيد كه وب سرور هك شود. عموما اس كيوال سرور بر روي سرور ديگري قرار دارد. به همين جهت رمزنگاري اين رشته باز هم ضريب امنيت بيشتري را به همراه خواهد داشت.
به همين منظور رمزنگاري قسمت كانكشن استرينگ فايل وب كانفيگ الزامي است، چون آن‌هايي كه به دنبال اطلاعاتي اينگونه هستند دقيقا مي‌دانند بايد به كجا مراجعه كنند.
راه حل‌ها:
الف) از وب كانفيگ براي اينكار استفاده نكنيد. يك فايل class library درست كنيد (يك dll مجزا) و ارجاعي از اين فايل را به پروژه خود اضافه كنيد و از رشته اتصالي قرار گرفته در آن استفاده كنيد. اين فايل را هم مي‌توان با روش‌هاي obfuscation محافظت كرد تا امنيت اطلاعات داخل آن‌را تا حد قابل قبولي بالا برد. همچنين مي‌توان براي اين فايل كتابخانه، امضاي ديجيتال درنظر گرفت. زيرا امضاي ديجيتال سبب مي‌شود تا تغيير فايل dll رشته اتصالي، با يك كپي و paste معمولي قابل انجام نباشد (تمامي dll ها و اسمبلي‌هاي ديگري كه ارجاعي از آن‌را در خود دارند بايد يكبار ديگر هم كامپايل و به سرور منتقل شوند). اين يك نوع اطمينان خاطر است اما در بلند مدت شايد تكرار اينكار خسته كننده باشد.
ب)استفاده از روش استاندارد رمزنگاري قسمت‌هاي مختلف كانكشن استرينگ فايل web.config
براي مشاهده نحوه انجام اينكار با برنامه نويسي به اين مقاله مراجعه نمائيد.
مزيت: نيازي به كد نويسي براي رمزگشايي و استفاده از آن نيست و اينكار به صورت خودكار توسط ASP.Net انجام مي‌شود.
ايراد:فايل حاصل قابل انتقال نيست. چون رمزنگاري بر اساس كليدهاي منحصربفرد سرور شما ايجاد مي‌شوند، اين فايل از يك سرور به سرور ديگر قابل انتقال و استفاده نخواهد بود. يعني اگر بر روي كامپيوتر برنامه نويسي شما اينكار صورت گرفت، برنامه در سرور كار نخواهد كرد. البته شايد ايراد آنچناني نباشد و فقط بايد يكبار ديگر روي هاست نيز اين كار را تكرار كرد. اما بايد درنظر داشت كه همسايه محترم شما نيز مي‌تواند بر روي همان هاست به سادگي فايل شما را رمزگشايي كند! بنابراين نبايد اصلا به اين روش در هاست‌هاي اشتراكي دل خوش كرد.
ج)بكارگيري روش‌هاي غيراستاندارد رمزنگاري
منظور از غيراستاندارد، حالت‌هاي ديگر استاندارد رمزنگاري و رمزگشايي نسبت به روش استاندارد ارائه شده توسط مايكروسافت است (كه همه از آن مطلع هستند). به شخصه از اين روش در هاست‌ها استفاده مي‌كنم. (مثلا، البته با كمي تغيير و پيچ و تاب بيشتر)
الگوريتم‌هاي رمزنگاري و رمزگشايي در يك فايل dll به برنامه اضافه مي‌شوند (بنابراين اين فايل قرار نيست تغيير كند). رشته رمزنگاري شده در فايل web.config قرار مي‌گيرد. بديهي است در هر بار اتصال به ديتابيس اين رشته بايد رمزگشايي شود اما سربار آن بسيار كم است و اصلا مشهود نيست. در هر حال اين هزينه‌اي است كه بايد پرداخت شود. بدست آوردن ساده كانكشن استرينگ يعني امكان پاك كردن سريع كل اطلاعات شما.
د)اگر سرور dedicated است حتما از روش windows authentication استفاده كنيد
براي مثال يك سرور dedicated مخصوص كار ويژه‌اي تهيه كرده ايد يا در شبكه اينترانت يك شركت برنامه شما نصب شده است.
روش اعتبار سنجي از نوع ويندوزي براي اتصال به اس كيوال سرور نسبت به حالت sql server authentication امن تر است، زيرا نيازي نيست تا در وب كانفيگ نام كاربري يا پسوردي را مشخص نمائيد و همچنين در اين حالت پسوردها در شبكه منتقل نمي‌شوند (در حالت sql server authentication اينطور نيست). اما عموما در هاست‌هاي اشتراكي براي ساده تر كردن كار ، از اين روش استفاده نمي‌كنند.
بنابراين در اينجا حتي اگر شخصي به رشته اتصالي شما دسترسي پيدا كند، كار خاصي را نمي‌تواند انجام دهد چون هيچگونه نام كاربري يا پسوردي در آن لحاظ نشده است.
در اين روش به صورت پيش فرض از اكانت ASP.Net استفاده مي‌شود. يعني تمام برنامه‌ها محدود به يك اكانت خواهند شد.
براي تغيير اين مورد دو كار را مي‌توان انجام داد : استفاده از impersonation يا مطالعه قسمت بعد (ه)
توصيه: از روش impersonation به دليل اينكه بايد نام كاربري و كلمه عبور را باز هم به صورت واضحي ذكر نمود اجتناب كنيد.
ه)ايجاد application pool مجزا به ازاي هر برنامه ASP.Net در ويندوزهاي سرور
Application pool كه براي اولين بار در ويندوز سرور 2003 معرفي شده جهت ايزوله كردن برنامه‌هاي ASP.Net بكار برده مي‌شود. به اين صورت مي‌شود براي هر pool يك اكانت ويندوزي مجزا تعريف كرد. حال مي‌توان به اين اكانت در اس كيوال سرور دسترسي داد. به اين صورت برنامه‌هاي مختلف تحت يك اكانت واحد (يوزر asp.net) كار نكرده (مي‌توانند هم كار كنند، اما امكان تعريف identity جديد براي كاربر آن در IIS وجود دارد) و ضريب امنيتي بالاتري را تجربه خواهيد كرد (در تكميل روش (د))
