Re: Encrypting connection strings in .Net
From: Alek Davis (alek_xDOTx_davis_xATx_intel_xDOTx_com)
Date: 06/05/04
- Next message: Shawn Farkas: "RE: protect secrets on Win98"
- Previous message: Joe Kaplan \(MVP - ADSI\): "Re: Encrypting connection strings in .Net"
- In reply to: Joe Kaplan \(MVP - ADSI\): "Re: Encrypting connection strings in .Net"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 4 Jun 2004 15:14:10 -0700
You are absolutely right about this. I am not arguing. ;-)
Alek
"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
in message news:%23$mkx7nSEHA.3020@TK2MSFTNGP10.phx.gbl...
> I was agreeing with you. I think you basically restated my larger point
> that you have to know what the threat is that is causing you to want to
> encrypt something. What I was trying to suggest is that different types
of
> threats require different levels of protection, that's all. I certainly
> wouldn't argue that storing a key in plain text is a very secure thing to
> do, but it still might be secure enough, especially if the file's ACL only
> allows admins and the worker process to read it. It all comes back to
what
> you are trying to defend against.
>
> That was the only point I was trying to make.
>
> Joe K.
>
> "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
> news:%23iGwYXmSEHA.3140@tk2msftngp13.phx.gbl...
> > I am not talking about a threat from an admin per se (although, in
certain
> > cases it should be considered). What I am saying is this. If you choose
to
> > go through the motions of encrypting a secret instead of storing it in
> > plaintext (in config file or registry), I assume that your intention is
to
> > prevent a hacker from being able to see this secret. A hacker in this
case
> > can be someone who intentionally tries to breach security or
accidentally
> > gets access to the system (which does not necessarily mean an admin). In
a
> > corporate environment, there are so many potentials for different types
of
> > hacking, that it would take me a while to describing at least some of
> them.
> > Anyway, if you encrypt the secret, but store the encryption key in plain
> > text along with it (in config file or registry), if the system is
> > compromised, the hacker can just make a copy of the encrypted value and
> the
> > key and decrypt data on his machine. Yes, it requires some work (on the
> > hacker's part), but not a lot of work. Unlike the efforts you mentioned
> > (attaching to debugger, getting memory dumps, etc), which I believe are
> not
> > very likely (at least, for the majority of applications), the threat I
am
> > describing is not that unreal. Maybe I am speaking from a position of a
> > person who had to go through way to many security audits, but to me
> storing
> > encryption key in plain text along with encrypted value is not an
> acceptable
> > practice (and, by the way, it would not pass a security audit in my
> > organization). Yes, it is better than storing secrets in plaintext, but
so
> > is using XOR as "encryption" method: marginally better. (I am a bit
> > exaggerating, of course.) If your application or data are not important
> > enough to justify the hacking effort, it may be OK, but at least you
must
> be
> > aware of the vulnerability, and I am afraid that many developers do not
> > realize it.
> >
> > Alek
> >
> > "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com>
wrote
> > in message news:e3$KABmSEHA.1308@TK2MSFTNGP10.phx.gbl...
> > > The underlying point here is what is the actual threat you are trying
to
> > > mitigate?
> > >
> > > If you are just trying to provide some protection of connection
strings
> > from
> > > casual inspection, then a plain text key might be sufficient to
prevent
> > > casual snooping. Thus CMAB might be fine. However, if you really
can't
> > > trust your administrators, then you will have to work much harder
> > (although
> > > it is basically impossible to store secrets from an admin on the box;
it
> > is
> > > just a matter of will and skills on their part). For example, if they
> can
> > > attach a debugger to your process, they can probably find the
> unencrypted
> > > string sitting in memory and don't even have to bother with looking
for
> > the
> > > key.
> > >
> > > Joe K.
> > >
> > > "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
> > > news:ORXgpBlSEHA.3040@TK2MSFTNGP09.phx.gbl...
> > > > You should be aware, though, that when CMAB uses a symmetric key
> > (without
> > > > DPAPI), it keeps the key in plain text, which is not secure.
> > > >
> > > > Alek
> > > >
> > > > "richlm" <rich_lm@h0tmai1.com> wrote in message
> > > > news:DA63A45F-343A-48CD-A7FF-B2288C0ADE4D@microsoft.com...
> > > > > You might also want to look at Microsoft's "Configuration
Management
> > > > Application Block" (CMAB). It provides an easy interface to
> > configuration
> > > > data (which can be stored in an XML file), with support for both
> > > encrypting
> > > > and signing the data.
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Shawn Farkas: "RE: protect secrets on Win98"
- Previous message: Joe Kaplan \(MVP - ADSI\): "Re: Encrypting connection strings in .Net"
- In reply to: Joe Kaplan \(MVP - ADSI\): "Re: Encrypting connection strings in .Net"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
