ذخیره کردن رشته اتصالی به دیتابیس، به صورت یک رشته مشخص در کدهای برنامه، کاری است مزموم. زیرا پس از هر بار تغییر این مورد، نیاز خواهد بود تا تمامی سورس*ها تغییر کنند و اگر از حالت 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 به دلیل اینکه باید نام کاربری و کلمه عبور را باز هم به صورت واضحی ذکر نمود اجتناب کنید.

ه)ایجاد application pool مجزا به ازای هر برنامه ASP.Net در ویندوزهای سرور
[برای نمایش لینک باید عضو شوید. ] که برای اولین بار در ویندوز سرور 2003 معرفی شده جهت ایزوله کردن برنامه*های ASP.Net بکار برده می*شود. به این صورت می*شود برای هر pool یک اکانت ویندوزی مجزا [برای نمایش لینک باید عضو شوید. ]. حال می*توان به این اکانت در اس کیوال سرور دسترسی داد. به این صورت برنامه*های مختلف تحت یک اکانت واحد (یوزر asp.net) کار نکرده (می*توانند هم کار کنند، اما امکان تعریف identity جدید برای کاربر آن در IIS* وجود دارد) و ضریب امنیتی بالاتری را تجربه خواهید کرد (در تکمیل روش (د))