Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

What are recommendations, best practices and have-to-dos regarding handling connection strings in web applications? What things one should never, ever do?

share|improve this question
    
Most answers here assume the presence of Windows, SQL Server and ASP.NET. Since (at least) the OP doesn't mention any particular deployment environment it would be good with some answers regarding things like Linux+Apache+MySQL+PHP as well. –  Per Wiklander Nov 12 '10 at 14:04
    
@Per, He did mention (albeit in one of the comments) that he is on ASP.NET. However, you are correct, and the principles (should) still stand - hence in my answer I said "if possible" (yes, these are clear advantages to MS platforms). Note though that such a thing DOES exist on non-MS platforms, via Kerberos, and there is also a DPAPI library for Linux. But if you can't use that, than something similar (based on same principles) is right. –  AviD Nov 15 '10 at 7:09

4 Answers 4

up vote 4 down vote accepted

Best option: Don't use a password for the database, but instead employ (Windows) Integrated Authentication if it's possible, and of course isolate the application's identity that is authorized for the database. That way you have the OS/Webserver/SCM manage your identity, in a very secured manner.

If it's not possible to go the way of IWA, you'll need to securely encrypt the connstring, preferably using something like DPAPI (so you dont have to manage the encryption key), and store the encrypted value in a protected Registry key with strong ACLs.
If you are on ASP.NET (from your comments, but not OP), there are built-in tools to do this automatically (aspnet_setreg, aspnet_regiis, etc depending on version...)

share|improve this answer
    
Using your first method, how would you protect the connection strings from people who have access to the servers, or more importantly, from people who break into your servers? –  Kyle Rozendo Oct 6 '11 at 7:09
    
@KyleRozendo you don't need to, thats the whole point. If you're using integrated authentication, the connection string would not contain a password at all. The credentials are stored by the application server (IIS/ASP.NET), and authentication is by process identity. –  AviD Oct 10 '12 at 9:34
    
@AviD how do I store the password to decrypt the encrypted key? –  Neil McGuigan Oct 26 '13 at 8:48
    
@NeilMcGuigan if possible, as I said it is best to use DPAPI (or something like that) to protect the encryption key (or even better, the key-encrypting-key). –  AviD Oct 26 '13 at 18:31

things you should never do

  • putting connection string in a text file.
  • have configuration file in public accessible folder/directory.

things you should do.

  • create helper function that generates database password on fly.
  • frequently change database password and username.
  • check if your server is configured properly, that you are not serving excutable files as plain text.
share|improve this answer
1  
"things you should never do": haha, sounds like about every open source PHP project I've ever seen. But on a more serious note, what would you do if it is an interpreted language that has to have access to the credentials to be able to connect to the DB? –  Per Wiklander Nov 12 '10 at 14:00

I'd recommend storing your connection string outside of the website root directory.

If you're using ASP.NET, then your web.config file will be in the website root directory, but you can encrypt a section of your web.config file using the Data Protection API, which stores the decryption key securely.

Which framework are you using for your web application?

share|improve this answer
    
Thanks, KirkJ! I'm using ASP.NET MVC as a framework. For some parts of the webapp (admin) is used Silverlight. –  rem Nov 12 '10 at 8:47

As an option, try to use application role to access sql server

Benefits:

  • Regular network administrators can manage data access without needing to consult the database administrator (DBA), simply by controlling who has access to an application.
  • You don’t need to worry about keeping track of changing users with SQL Server itself. Set up an application role and you can delegate that back to the network level.
  • You can limit data availability to a single application. For example, a user might be able to modify accounting information only when using the general ledger application, and not when he connects directly to SQL Server.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.