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
> >
> >
>
>



Relevant Pages

  • Re: Database Security - Where to store?
    ... We'll actually support DPAPI in V2. ... >> the LSA secret mechanism of NT 4. ... >> will also be in memory at some point, and can suffer from the same ...
    (microsoft.public.dotnet.security)
  • Re: Database Security - Where to store?
    ... of Michael Howard and David LeBlanc's Writing Secure Code book is dedicated ... the LSA secret mechanism of NT 4. ... will also be in memory at some point, and can suffer from the same attack. ... decrypted data as soon as you no longer need them. ...
    (microsoft.public.dotnet.security)
  • Re: JLA 119: Identity Crisis Retcon (#1 In A Series...)
    ... moral wrong of wiping a bad guy's memory of your secret id. ... OK, there ARE two instances I can think of, both involving Superman ... Clark, Jimmy, and Lois are all tied up together and a bomb is about to ...
    (rec.arts.comics.dc.universe)
  • Re: What is the best way to do this in Delphi?
    ... access time issues are not the most significant factor in determining ... because you can access any memory location whenever you like - ... There's no secret at all - *you* just don't know the facts ... Now they can fit multiple cpus on reasonably small bits of silicon ...
    (alt.comp.lang.borland-delphi)
  • JLA 119: Identity Crisis Retcon (#1 In A Series...)
    ... One of the biggest arguments about Identity Crisis had to do with the ... moral wrong of wiping a bad guy's memory of your secret id. ... It's not really a spoiler that the JLA wins and defeats the Secret ... The Wizard: So now you're going to do to us what youd did to Dr. ...
    (rec.arts.comics.dc.universe)