Here are the options for storing database connection strings securely:
- Encrypted with DPAPI
- Clear text in Web.config or Machine.config
- Custom text files
- Registry
Using DPAPI
Windows 2000 and later operating systems provide the Win32® Data Protection
API (DPAPI) for encrypting and decrypting data. DPAPI is part of the
Cryptography API (Crypto API) and is implemented in Crypt32.dll. It consists
of two methods-CryptProtectData and CryptUnprotectData.
DPAPI is particularly useful in that it can eliminate the key management
problem exposed to applications that use cryptography. While encryption
ensures the data is secure, you must take additional steps to ensure the
security of the key. DPAPI uses the password of the user account associated
with the code that calls the DPAPI functions in order to derive the
encryption key. As a result the operating system (and not the application)
manages the key.
If you use the machine store (and call the DPAPI functions with the
CRYPTPROTECT_LOCAL_MACHINE flag) you can call the DPAPI functions directly
from an ASP.NET Web application (because you don't need a user profile).
However, because you are using the machine store, any Windows account that
can log on to the computer has access to the secret. A mitigating approach
is to add entropy but this requires additional key management.
Using Web.config and Machine.config
Storing plain text passwords in Web.config is not recommended. By default,
the HttpForbiddenHandler protects the file from being downloading and viewed
by malicious users. However, users who have access directly to the folders
that contain the configuration files can still see the user name and
password.
Machine.config is considered a more secure storage location than Web.config
because it is located in a system directory (with ACLs) outside of a Web
application's virtual directory. Always lock down Machine.config with ACLs.
Using Custom Text Files
Many applications use custom text files to store connection strings. If you
do adopt this approach consider the following recommendations:
a.. Store custom files outside of your application's virtual directory
hierarchy.
b.. Consider storing files on a separate logical volume from the operating
system to protect against possible file canonicalization and directory
traversal bugs.
c.. Protect the file with a restricted ACL that grants read access to your
application's process account.
d.. Avoid storing the connection string in clear text in the file.
Instead, consider using DPAPI to store an encrypted string.
Using the Registry
You can use a custom key in the Windows registry to store the connection
string. This information stored can either be stored in the
HKEY_LOCAL_MACHINE (HKLM) or HKEY_CURRENT_USER (HKCU) registry hive. For
process identities, such as the ASPNET account, that do not have user
profiles, the information must be stored in HKLM in order to allow ASP.NET
code to retrieve it.
If you do use this approach, you should:
a.. Use ACLs to protect the registry key using Regedt32.exe.
b.. Encrypt the data prior to storage.
Hope this helps.
"Guadala Harry" <gh****@aol.com> wrote in message
news:O8****************@TK2MSFTNGP11.phx.gbl...
What are my options for *securely* storing/retrieving the ID and password
used by an ASP.NET application for accessing a SQL Server (using SQL
Server authentication)? Please note that this ID and password would be different
than the one the user enters for ASP.NET forms authentication. The
ID/password in question is used by the application, itself, for accessing
the SQL Server.
Thanks in advance.
