By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,363 Members | 3,622 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,363 IT Pros & Developers. It's quick & easy.

Where/How to Securely Store ID and Password?

P: n/a
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.
Nov 18 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
You can encrypt it and store it in the web.config file. Since .config is not
a servable file by IIS, it is as secure as your DB is.

"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.

Nov 18 '05 #2

P: n/a
there is no real secure way, all other web sites have the same dir/registry
access as yours. the best you can do is some encryption, but the key will be
hardcoded in your app, and thus available to all sites on the server (they
can open you assembly and look for the key).

hopefully someday MS will solve this, as the solution requires a change to
the IIS or the OS.

-- bruce (sqlwork.com)

"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.

Nov 18 '05 #3

P: n/a
See Chris Falter's article on our site here:

http://www.eggheadcafe.com/articles/20021211.asp

Note that there may have been some improvements to this
scheme since the article was originally published.

--Peter

"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.

Nov 18 '05 #4

P: n/a
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.

Nov 18 '05 #5

P: n/a
Thanks for the comprehensive answer - it helps a lot.

G

"Martha[MSFT]" <ma******@online.microsoft.com> wrote in message
news:u7****************@TK2MSFTNGP10.phx.gbl...
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.


Nov 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.