Encrypted Connections Strings not safe in memory?

Discussion in 'ASP .Net Security' started by Rick M., Oct 22, 2007.

  1. Rick M.

    Rick M. Guest

    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.
    Rick M., Oct 22, 2007
    #1
    1. Advertising

  2. > 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?


    Well - against whom do you wanna protect this data?

    To read random process memory you need to run win32 code in the context of
    your app - or attach a debugger to the process.

    Debugging requires quite high OS privileges.

    Separate your apps into different process (the IIS application pool feature)
    to isolate memory from other code running on that server (if that is a concern).
    I wouldn't bother encrypting stuff in memory. If someone is able to read
    your memory - you got a much bigger problem.

    -----
    Dominick Baier (http://www.leastprivilege.com)

    Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp)

    > 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.
    >
    Dominick Baier, Oct 24, 2007
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Kyle

    Encrypted Strings

    David Kyle, Nov 17, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    456
    David Kyle
    Nov 17, 2004
  2. jobs
    Replies:
    2
    Views:
    873
  3. Gabriel Rossetti
    Replies:
    0
    Views:
    1,294
    Gabriel Rossetti
    Aug 29, 2008
  4. Aredridel

    Not just $SAFE, but damn $SAFE

    Aredridel, Sep 2, 2004, in forum: Ruby
    Replies:
    19
    Views:
    225
  5. John Nagle
    Replies:
    5
    Views:
    449
    John Nagle
    Mar 12, 2012
Loading...

Share This Page