One advantage of a randomly machine-generated password created in-memory at setup time and stored using the DPAPI, is that *no-one* knows the password.
M > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Tracy Vanas > Sent: 09 December 2004 17:03 > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] How and where to store securely a database > connection string > > If you develop locally, you have a copy of the udl file to connect to the > development database. However, you have no access to view the qa and > production passwords (assuming you have a qa and production database > server). > > > Tracy Vanas > Application Services > Ph: 989-496-6551 Fax: 989-496-8017 > Email: [EMAIL PROTECTED] > > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Eddie Lascu > Sent: Thursday, December 09, 2004 11:45 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] How and where to store securely a database > connection string > > Tracy, > > This is a most excellent idea. A little bit of work, but a flexible > solution > that can be reused over and over. What do you mean by "the developer at > most > only knows the development password"? > > Cheers, > Eddie > > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] Behalf Of Tracy Vanas > Sent: Thursday, December 09, 2004 11:03 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] How and where to store securely a database > connection string > > > You could store the connect string in udl files in a secure directory on > your servers. The DBAs only could have access to these files to change > the > passwords periodically. You could then write a common method > (YourCompany.Data dll or something) to retrieve and parse the udl file and > return in connection string format the caller. This way the developer at > most only knows the development password. > > This is one method. Hope it helps. > > Tracy Vanas > Application Services > Ph: 989-496-6551 Fax: 989-496-8017 > Email: [EMAIL PROTECTED] > > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Eddie Lascu > Sent: Thursday, December 09, 2004 10:54 AM > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] How and where to store securely a database > connection string > > I would like to hear about different options to securely store a database > connection string. In the past we used to hard code it but that meant that > we will never be able to change it unless we were ready to recompile the > hole application/system (or at least parts of it). With .NET the > app.config > file is an easy place to put it. It's convenient because you can change it > with a simple text editor (Notepad). You don't need to recompile your > application, a restart would be enough (ASP.NET doesn't even need that). > However, it's not really secure because everyone can have access to it. Is > there a way to encrypt the app.config or at least parts of it? I guess I > could encrypt the connection string and store it in the app.config. I > could > include the decryption algorithm in my app but then I would need a > different > application to be able to decrypt the string, change it and encrypt it > back > into the app.config. > I am really curious about what are different options here. > > All the best, > Eddie > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET > courses you may be interested in: > > Essential .NET: building applications and components with C# November 29 - > December 3, in Los Angeles http://www.develop.com/courses/edotnet > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET > courses you may be interested in: > > Essential .NET: building applications and components with C# November 29 - > December 3, in Los Angeles http://www.develop.com/courses/edotnet > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET > courses you may be interested in: > > Essential .NET: building applications and components with C# November 29 - > December 3, in Los Angeles http://www.develop.com/courses/edotnet > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > Some .NET courses you may be interested in: > > Essential .NET: building applications and components with C# > November 29 - December 3, in Los Angeles > http://www.develop.com/courses/edotnet > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with C# November 29 - December 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
