> 2) Is this even a legitimate security risk? Are we correct in our
> assumptions (strings stored in plain text in memory, persisted after
> use)? You may argue against the likely hood of this type of memory
> attack, but that's not the position I want to start from. Ideally, I
> want to be as secure as possible without have to write custom DAL's
> for every little page. Is this a trade-off we have to live with?

> Simply put, best practices say to:
>
> 1) Put ConnectionString info in to web.config for easier editing (and
> disallow the need to recompile code if settings change).
>
> 2) Encrypt the ConnectionString section using the aspnet_setreg.exe
> utility.
> This encrypts the data on the IIS/OS level disallowing someone with
> file
> level access the ability to read the plain text .xml.
> 3) In memory variables of secure data should be encrypted, and only
> decrypted when needed. You should then dispose of the decrypted
> string in memory to minimize a memory dump exposure of said sensitive
> strings.
>
> However, it is my understanding that the web.config is read in to
> memory at application start-up, and even if the contents are
> encrypted, they are stored in plain text in memory (see "Security
> Note" here:
> http://msdn2.microsoft.com/en-us/library/hh8x3tas(vs.80).aspx). Our
> security guys are telling us that a buffer-overflow attack on our web
> app would expose these connection strings. They are then asking us to
> use a custom encrypt/decrypt routine to read these variables when
> needed.
>
> My problem is that:
>
> 1) While that's fine if you write custom Data Access Layers and build
> all your connection and data objects from scratch in code, you'll
> loose some of the cool "automagic" stuff you get by dragging and
> dropping objects in VS 2005. For instance, how do I tell my wizard
> created DataSet TableAdapter to use my custom encrypt/decrypt routine
> when looking for a connection string? Can you easily extend some base
> class? How easy is it to modify the generated code? I've read blogs
> warning against this for various reasons.
>
> 2) Is this even a legitimate security risk? Are we correct in our
> assumptions (strings stored in plain text in memory, persisted after
> use)? You may argue against the likely hood of this type of memory
> attack, but that's not the position I want to start from. Ideally, I
> want to be as secure as possible without have to write custom DAL's
> for every little page. Is this a trade-off we have to live with?
>
> Thoughts?
>
> Thanks in advance for any guidance you may provide.
>