14

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

Improve this question
2
  • 1
    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, 2010 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, 2010 at 7:09

5 Answers 5

Reset to default
6

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 Integrated Windows Authentication (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...)

Improve this answer
5
  • 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 Rosendo
    Oct 6, 2011 at 7:09
  • 1
    @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, 2012 at 9:34
  • @AviD how do I store the password to decrypt the encrypted key?
    – Neil McGuigan
    Oct 26, 2013 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, 2013 at 18:31
  • Can't you just find out the connection string at run-time using a little bit of code anyways? At some point the connection has to be decrypted. It seems that the process that has the data layer would have to be under wraps as well and that that account would be the only one that has access to the database. Then you could safely decrypt and use the connection string.
    – jwize
    Sep 7, 2019 at 1:14
3

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.
Improve this answer
2

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.
Improve this answer
1
  • 2
    "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, 2010 at 14:00
2

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?

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

You can also store your connection string as a secret in an Azure Key Vault. You can create a free Azure account (preferably the same account you use for Visual Studio). Learn more at https://docs.microsoft.com/en-us/azure/key-vault/general/vs-key-vault-add-connected-service

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .