Re: Database Security - Where to store?

From: Marcelo J. Birnbach (mbirnbac@online.microsoft.com)
Date: 02/13/03


From: "Marcelo J. Birnbach" <mbirnbac@online.microsoft.com>
Date: Thu, 13 Feb 2003 14:28:56 -0800


You'll see managed support for DPAPI in V1.1

That leverages the Windows DPAPI to store secrets but it's only available in
Win2K and higher OS's

"Shawn Farkas [MS]" <shawnfa@online.microsoft.com> wrote in message
news:#IiCy#v0CHA.1636@TK2MSFTNGP12...
> Hi Zack,
>
> Storing secrets is a very difficult problem. In fact, an entire
chapter
> of Michael Howard and David LeBlanc's Writing Secure Code book is
dedicated
> to this problem. You can attempt to solve it different ways depending on
> your target operating system.
>
> * Win 98/ME : There is no secure way to store a key on these operating
> systems. Since they do not support ACL's, you cannot lock malicious users
> away from your key.
> * WinNT 4+ with NTFS: Since Windows NT4 and higher support NTFS and
NTFS
> supports ACLs, you can use ACLs to protect your data. The most
> straightforward way to store a secret here is to put it in the registry
and
> set an ACL so that only your application can access it. You can also use
> the LSA secret mechanism of NT 4.
> * Windows 2000+: Windows 2000 supports the Data Protection API
(DPAPI),
> which can be used to store secret information. You can use the
> CryptProtectData() and CryptUnprotectData() API calls to use this feature.
>
> Unfortunately there is not yet a native .NET method of storing a
secret
> securely. You'll have to resort to P/Inovoke, to at least get the secret
> stored.
>
> No matter how you choose to solve the problem however, you need to
> remember that at *some* point, the key needed to do the decryption will be
> in memory, so an attacker with a debugger can attach to your process and
> theoretically find the key. Along those same lines, your decrypted data
> will also be in memory at some point, and can suffer from the same attack.
> For these reasons, you should scrub the memory where you store the key and
> decrypted data as soon as you no longer need them. This will minimize the
> window of time that your application is vulnerable. However, scrubbing
data
> within .Net is also problematic, since the garbage collector may have
moved
> your object several times (creating several instances of your secret left
> behind in memory) without your knowledge. Also, strings in the CLR are
> immutable, so you have no way of writing over the contents of the string
in
> memory with some other value.
>
> -Shawn
>
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Please do not send email directly to this alias, this alias is for
newsgroup
> purposes only.
>
>
> "Zachary Burns" <zacharyburns@hotsmail.com> wrote in message
> news:ur$BGHg0CHA.1752@TK2MSFTNGP10...
> > I'm currently storing Database connection information in a
> "xxx.exe.config"
> > file, but think it's a poor choice. I don't want to place connection in
> my
> > code (poor design), or in the registry (per Microsoft), or in a
> > "xxx.exe.config" file because of poor security. I've heard about
placing
> > the connection information into a .resx (resource file). Is this the
> > preferred method?
> >
> > Zack
> >
> >
>
>