Help encrypt conn string - no ASP, no server, can't protect keys, can't use Windows Authentication

microsoft.public.dotnet.security

17 Jul 2006 8:03 PM

David Lee Conley

I've seen several questions posted since October regarding the encryption of
connection strings, but none of them seem to address my particular need.

I want to deploy a .NET 2.0 Windows Forms application that uses an MS Access
2003 database. The database has been encoded and password protected to
prevent direct manipulation. The database is used to store
application-related data, and access is controlled by the application, which
reads information from a user table in the database. The application
provides all authentication and authorization for database activities. The
application can't be used unless the user authenticates with information
stored in the user table in the database.

I need a way to encrypt the connection string, which includes the password,
without hard-coding it in the application.

The application is targeted for Windows XP for use at home, but could also
be used on a machine connected to a network, such as an active directory
domain. This particular app isn't being designed to interact with AD or a
network environment.

The samples I've seen on the Internet use DPAPI and other encryption schemes
that seem to require keys, but, unless I didn't see it or don't understand
it, I don't see a way to generate encryption keys during design time that
can be deployed with any way of protecting the keys.

I can't use Windows Authentication/Integrated Security because, given the
potential environments this application would be used in, there's no
guarantee that the person booting up and signing on the computer is the
actual intended user.

The example I've seen that uses ProtectedData clearly won't work because
once the connection string is encrypted, it can only be decrypted on the
machine it's being used on.

My understanding is that I can't use hashing because it creates a 1-way
encryption, and I need to be able to decrypt it to connect to the database.

I've been able to "encrypt" the connection string using AsnEncodeData and
put the results in the app.config file, and could probably do the same thing
with CryptoAPITransform, but it occurs to me that someone that knows how to
program in .NET could implement they're own AsnEncodeData or
CryptoAPITransform decoders to read the connection string.

Is there any way to encrypt the connection string so it can't be hacked in
this situation?

Or do I need to create a second app that runs as a Custom Action during
deployment that encrypts the connection string for that machine only?

TIA.

Dave

17 Jul 2006 8:21 PM

Dominick Baier

Hi,

you are right, there is no way to accomplish this - at least not with a mainstream
operating system like Windows.

You will always hit the problem that if the application is able to decrypt
the data (running in the users context), the user is able too.

You can try to set up all kinds of obstacles and raise the bar by making
it harder to decrypt the data, but there is no bulletproof solution to this.

dominick

Show quoteHide quote

> I've seen several questions posted since October regarding the
> encryption of connection strings, but none of them seem to address my
> particular need.
>
> I want to deploy a .NET 2.0 Windows Forms application that uses an MS
> Access 2003 database. The database has been encoded and password
> protected to prevent direct manipulation. The database is used to
> store application-related data, and access is controlled by the
> application, which reads information from a user table in the
> database. The application provides all authentication and
> authorization for database activities. The application can't be used
> unless the user authenticates with information stored in the user
> table in the database.
>
> I need a way to encrypt the connection string, which includes the
> password, without hard-coding it in the application.
>
> The application is targeted for Windows XP for use at home, but could
> also be used on a machine connected to a network, such as an active
> directory domain. This particular app isn't being designed to
> interact with AD or a network environment.
>
> The samples I've seen on the Internet use DPAPI and other encryption
> schemes that seem to require keys, but, unless I didn't see it or
> don't understand it, I don't see a way to generate encryption keys
> during design time that can be deployed with any way of protecting the
> keys.
>
> I can't use Windows Authentication/Integrated Security because, given
> the potential environments this application would be used in, there's
> no guarantee that the person booting up and signing on the computer is
> the actual intended user.
>
> The example I've seen that uses ProtectedData clearly won't work
> because once the connection string is encrypted, it can only be
> decrypted on the machine it's being used on.
>
> My understanding is that I can't use hashing because it creates a
> 1-way encryption, and I need to be able to decrypt it to connect to
> the database.
>
> I've been able to "encrypt" the connection string using AsnEncodeData
> and put the results in the app.config file, and could probably do the
> same thing with CryptoAPITransform, but it occurs to me that someone
> that knows how to program in .NET could implement they're own
> AsnEncodeData or CryptoAPITransform decoders to read the connection
> string.
>
> Is there any way to encrypt the connection string so it can't be
> hacked in this situation?
>
> Or do I need to create a second app that runs as a Custom Action
> during deployment that encrypts the connection string for that machine
> only?
>
> TIA.
>
> Dave
>

17 Jul 2006 8:45 PM

Joe Kaplan (MVP - ADSI)

That said, per machine DPAPI encryption of the connection string is probably
the way to go. That would allow all users on the machine to read the data
programmatically, while not leaving the data sitting out in plain text. You
would probably want to write a custom action for your installer that does
this.

Of course, the CA will have the plain text data, so then you need to figure
out how to hide the data in the CA. Additionally, a smart user will be able
to get the plain text data as your program can do it. Essentially, you are
only raising the bar.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Show quoteHide quote

"Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in
message news:4580be6354f38c87806803f5559@news.microsoft.com...
> Hi,
> you are right, there is no way to accomplish this - at least not with a
> mainstream operating system like Windows.
>
> You will always hit the problem that if the application is able to decrypt
> the data (running in the users context), the user is able too.
>
> You can try to set up all kinds of obstacles and raise the bar by making
> it harder to decrypt the data, but there is no bulletproof solution to
> this.
>
> dominick
>
>> I've seen several questions posted since October regarding the
>> encryption of connection strings, but none of them seem to address my
>> particular need.
>>
>> I want to deploy a .NET 2.0 Windows Forms application that uses an MS
>> Access 2003 database. The database has been encoded and password
>> protected to prevent direct manipulation. The database is used to
>> store application-related data, and access is controlled by the
>> application, which reads information from a user table in the
>> database. The application provides all authentication and
>> authorization for database activities. The application can't be used
>> unless the user authenticates with information stored in the user
>> table in the database.
>>
>> I need a way to encrypt the connection string, which includes the
>> password, without hard-coding it in the application.
>>
>> The application is targeted for Windows XP for use at home, but could
>> also be used on a machine connected to a network, such as an active
>> directory domain. This particular app isn't being designed to
>> interact with AD or a network environment.
>>
>> The samples I've seen on the Internet use DPAPI and other encryption
>> schemes that seem to require keys, but, unless I didn't see it or
>> don't understand it, I don't see a way to generate encryption keys
>> during design time that can be deployed with any way of protecting the
>> keys.
>>
>> I can't use Windows Authentication/Integrated Security because, given
>> the potential environments this application would be used in, there's
>> no guarantee that the person booting up and signing on the computer is
>> the actual intended user.
>>
>> The example I've seen that uses ProtectedData clearly won't work
>> because once the connection string is encrypted, it can only be
>> decrypted on the machine it's being used on.
>>
>> My understanding is that I can't use hashing because it creates a
>> 1-way encryption, and I need to be able to decrypt it to connect to
>> the database.
>>
>> I've been able to "encrypt" the connection string using AsnEncodeData
>> and put the results in the app.config file, and could probably do the
>> same thing with CryptoAPITransform, but it occurs to me that someone
>> that knows how to program in .NET could implement they're own
>> AsnEncodeData or CryptoAPITransform decoders to read the connection
>> string.
>>
>> Is there any way to encrypt the connection string so it can't be
>> hacked in this situation?
>>
>> Or do I need to create a second app that runs as a Custom Action
>> during deployment that encrypts the connection string for that machine
>> only?
>>
>> TIA.
>>
>> Dave
>>
>
>

17 Jul 2006 9:03 PM

Dominick Baier

and also add a hardcoded entropy when you are using the machine key. raises
the bar a *little* bit more.

dominick

Show quoteHide quote

> That said, per machine DPAPI encryption of the connection string is
> probably the way to go. That would allow all users on the machine to
> read the data programmatically, while not leaving the data sitting out
> in plain text. You would probably want to write a custom action for
> your installer that does this.
>
> Of course, the CA will have the plain text data, so then you need to
> figure out how to hide the data in the CA. Additionally, a smart user
> will be able to get the plain text data as your program can do it.
> Essentially, you are only raising the bar.
>
> Joe K.
>

17 Jul 2006 9:24 PM

David Lee Conley

Thanks for the info Dominick and Joe.

So it sounds like I'll need a custom action application that processes the
connection string using multiple encryption schemes in succession during
installation and then hard code the decryption process in my app. What a
pain.

Dave

17 Jul 2006 10:50 PM

Joe Kaplan (MVP - ADSI)

I don't think it has to be that bad. If your CA creates the protected data
with the optional entropy, then the CA can update a Windows Installer
property with the result and your installer can then just write the data to
a known registry key.

Then, your app can read the known registry key, unprotect the data with the
..NET ProtectedData class and use it.

You'd probably want to round trip the encrypted binary data as Base64 to
make it easier to integrate with Windows installer and store in the registry
as a string. You could also write the data to a file with a different CA.

The CA would need to have knowledge of the plain text data, but you might as
well include that in the compiled binary. If you run the CA from a binary
in the binaries table, it would never be installed on the file system.
Someone who knew what they were doing could pull that binary out of your MSI
and reverse engineer it, but they'd probably just use a simple DPAPI call to
hack you instead. But remember, we are just raising the bar. :)

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Show quoteHide quote

"David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
news:neTug.783$bP5.72@newsread1.news.pas.earthlink.net...
> Thanks for the info Dominick and Joe.
>
> So it sounds like I'll need a custom action application that processes the
> connection string using multiple encryption schemes in succession during
> installation and then hard code the decryption process in my app. What a
> pain.
>
> Dave
>

17 Jul 2006 11:48 PM

David Lee Conley

I don't have access to a CA because I'm building this (as a demo project to
show prospective employers) on my home machine, which is running XP Media
Center. I could install Windows 2003 Server on a virtual machine, but I
wanted to avoid that if it wasn't necessary.

Dave

Show quoteHide quote

"Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
in message news:OdGW3NfqGHA.4492@TK2MSFTNGP05.phx.gbl...
>I don't think it has to be that bad. If your CA creates the protected data
>with the optional entropy, then the CA can update a Windows Installer
>property with the result and your installer can then just write the data to
>a known registry key.
>
> Then, your app can read the known registry key, unprotect the data with
> the .NET ProtectedData class and use it.
>
> You'd probably want to round trip the encrypted binary data as Base64 to
> make it easier to integrate with Windows installer and store in the
> registry as a string. You could also write the data to a file with a
> different CA.
>
> The CA would need to have knowledge of the plain text data, but you might
> as well include that in the compiled binary. If you run the CA from a
> binary in the binaries table, it would never be installed on the file
> system. Someone who knew what they were doing could pull that binary out
> of your MSI and reverse engineer it, but they'd probably just use a simple
> DPAPI call to hack you instead. But remember, we are just raising the
> bar. :)
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services
> Programming"
> http://www.directoryprogramming.net
> --
> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
> news:neTug.783$bP5.72@newsread1.news.pas.earthlink.net...
>> Thanks for the info Dominick and Joe.
>>
>> So it sounds like I'll need a custom action application that processes
>> the connection string using multiple encryption schemes in succession
>> during installation and then hard code the decryption process in my app.
>> What a pain.
>>
>> Dave
>>
>
>

18 Jul 2006 1:31 AM

Joe Kaplan (MVP - ADSI)

Sorry, when I said CA, I meant Windows Installer custom action, not a
certificate authority. I spend a fair amount of time these days goofing
around with both and knew what I meant, but I can see how it wasn't clear.
I thought I remembered you mentioning custom action before, so I figured
that's what you'd assume too.

You don't need a certificate server or certificates of any kind to do what
we were talking about. DPAPI does all the actual crypto for you.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Show quoteHide quote

"David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
news:0lVug.5768$vO.1344@newsread4.news.pas.earthlink.net...
>I don't have access to a CA because I'm building this (as a demo project to
>show prospective employers) on my home machine, which is running XP Media
>Center. I could install Windows 2003 Server on a virtual machine, but I
>wanted to avoid that if it wasn't necessary.
>
> Dave
>
> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
> in message news:OdGW3NfqGHA.4492@TK2MSFTNGP05.phx.gbl...
>>I don't think it has to be that bad. If your CA creates the protected
>>data with the optional entropy, then the CA can update a Windows Installer
>>property with the result and your installer can then just write the data
>>to a known registry key.
>>
>> Then, your app can read the known registry key, unprotect the data with
>> the .NET ProtectedData class and use it.
>>
>> You'd probably want to round trip the encrypted binary data as Base64 to
>> make it easier to integrate with Windows installer and store in the
>> registry as a string. You could also write the data to a file with a
>> different CA.
>>
>> The CA would need to have knowledge of the plain text data, but you might
>> as well include that in the compiled binary. If you run the CA from a
>> binary in the binaries table, it would never be installed on the file
>> system. Someone who knew what they were doing could pull that binary out
>> of your MSI and reverse engineer it, but they'd probably just use a
>> simple DPAPI call to hack you instead. But remember, we are just raising
>> the bar. :)
>>
>> Joe K.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> --
>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
>> news:neTug.783$bP5.72@newsread1.news.pas.earthlink.net...
>>> Thanks for the info Dominick and Joe.
>>>
>>> So it sounds like I'll need a custom action application that processes
>>> the connection string using multiple encryption schemes in succession
>>> during installation and then hard code the decryption process in my app.
>>> What a pain.
>>>
>>> Dave
>>>
>>
>>
>
>

18 Jul 2006 2:11 AM

David Lee Conley

OK. I assumed CA was certificate authority only because of my background
with Windows server.

Thanks for the help.

Dave

19 Jul 2006 1:27 PM

David Lee Conley

Is there any reason I couldn't bury the string in HKEY_CLASSES_ROOT\CLSID
and under the GUID generated for my app? Would it violate a best practice
or convention?

Dave

Show quoteHide quote

19 Jul 2006 2:04 PM

Joe Kaplan (MVP - ADSI)

That's a good question that I can't really answer. I'm not an expert on
registry usage and conventions.

It seems somewhat wrong to me to stick application data in the COM
registration info, but I don't really know. Based on what I've observed, it
would seem like the more conventional thing would be to stick the data in
HKLM\Software\<Your Company/Product>. I think the ultimate decision is up
to you. You could stick it in an ini file just as well and have the same
affect.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Show quoteHide quote

"David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
news:arqvg.293$gF6.190@newsread2.news.pas.earthlink.net...
> Is there any reason I couldn't bury the string in HKEY_CLASSES_ROOT\CLSID
> and under the GUID generated for my app? Would it violate a best practice
> or convention?
>
> Dave
>
> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
> in message news:OdGW3NfqGHA.4492@TK2MSFTNGP05.phx.gbl...
>>I don't think it has to be that bad. If your CA creates the protected
>>data with the optional entropy, then the CA can update a Windows Installer
>>property with the result and your installer can then just write the data
>>to a known registry key.
>>
>> Then, your app can read the known registry key, unprotect the data with
>> the .NET ProtectedData class and use it.
>>
>> You'd probably want to round trip the encrypted binary data as Base64 to
>> make it easier to integrate with Windows installer and store in the
>> registry as a string. You could also write the data to a file with a
>> different CA.
>>
>> The CA would need to have knowledge of the plain text data, but you might
>> as well include that in the compiled binary. If you run the CA from a
>> binary in the binaries table, it would never be installed on the file
>> system. Someone who knew what they were doing could pull that binary out
>> of your MSI and reverse engineer it, but they'd probably just use a
>> simple DPAPI call to hack you instead. But remember, we are just raising
>> the bar. :)
>>
>> Joe K.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> --
>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
>> news:neTug.783$bP5.72@newsread1.news.pas.earthlink.net...
>>> Thanks for the info Dominick and Joe.
>>>
>>> So it sounds like I'll need a custom action application that processes
>>> the connection string using multiple encryption schemes in succession
>>> during installation and then hard code the decryption process in my app.
>>> What a pain.
>>>
>>> Dave
>>>
>>
>>
>
>

19 Jul 2006 2:33 PM

David Lee Conley

I thought about using external files, but putting human unreadable text in
an external file is an invitation for someone to try to decipher it. I also
considered putting it in the normal location in the registry as you
suggested, but I figured this would be the first place someone trying to
hack the database would look. That's why I considered the GUID approach in
the CLSID section because no one would no where to look, and I could use a
key name that is unobtrusive.

It wouldn't be a problem if this were a client/server, smart client, or web
app/service, but given the information you and Dominick have provided in
consideration of the scenario I've proposed, it seems necessary to raise the
bar as high as I can.

Do you know any newsgroup or individual to which I can pose the question
about the registry?

Thank you again for your help.

Dave

Show quoteHide quote

"Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
in message news:%23EKkDxzqGHA.5012@TK2MSFTNGP03.phx.gbl...
> That's a good question that I can't really answer. I'm not an expert on
> registry usage and conventions.
>
> It seems somewhat wrong to me to stick application data in the COM
> registration info, but I don't really know. Based on what I've observed,
> it would seem like the more conventional thing would be to stick the data
> in HKLM\Software\<Your Company/Product>. I think the ultimate decision is
> up to you. You could stick it in an ini file just as well and have the
> same affect.
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services
> Programming"
> http://www.directoryprogramming.net
> --
> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
> news:arqvg.293$gF6.190@newsread2.news.pas.earthlink.net...
>> Is there any reason I couldn't bury the string in HKEY_CLASSES_ROOT\CLSID
>> and under the GUID generated for my app? Would it violate a best
>> practice or convention?
>>
>> Dave
>>
>> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com>
>> wrote in message news:OdGW3NfqGHA.4492@TK2MSFTNGP05.phx.gbl...
>>>I don't think it has to be that bad. If your CA creates the protected
>>>data with the optional entropy, then the CA can update a Windows
>>>Installer property with the result and your installer can then just write
>>>the data to a known registry key.
>>>
>>> Then, your app can read the known registry key, unprotect the data with
>>> the .NET ProtectedData class and use it.
>>>
>>> You'd probably want to round trip the encrypted binary data as Base64 to
>>> make it easier to integrate with Windows installer and store in the
>>> registry as a string. You could also write the data to a file with a
>>> different CA.
>>>
>>> The CA would need to have knowledge of the plain text data, but you
>>> might as well include that in the compiled binary. If you run the CA
>>> from a binary in the binaries table, it would never be installed on the
>>> file system. Someone who knew what they were doing could pull that
>>> binary out of your MSI and reverse engineer it, but they'd probably just
>>> use a simple DPAPI call to hack you instead. But remember, we are just
>>> raising the bar. :)
>>>
>>> Joe K.
>>>
>>> --
>>> Joe Kaplan-MS MVP Directory Services Programming
>>> Co-author of "The .NET Developer's Guide to Directory Services
>>> Programming"
>>> http://www.directoryprogramming.net
>>> --
>>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in
>>> message news:neTug.783$bP5.72@newsread1.news.pas.earthlink.net...
>>>> Thanks for the info Dominick and Joe.
>>>>
>>>> So it sounds like I'll need a custom action application that processes
>>>> the connection string using multiple encryption schemes in succession
>>>> during installation and then hard code the decryption process in my
>>>> app. What a pain.
>>>>
>>>> Dave
>>>>
>>>
>>>
>>
>>
>
>

19 Jul 2006 4:27 PM

Joe Kaplan (MVP - ADSI)

I wouldn't worry about trying too hard to hide the data. Anyone using
filemon or regmon will quickly figure out where you are storing the
encrypted data no matter where you store it, so I don't think it is worth it
to try to hide it too much. Also, unless you use obfuscation, they will
easily reverse engineer your .NET code and figure out exactly how you are
decrypting the data. A smart user with a debugger will simply attach to
your process and read the decrypted data directly out of memory. You don't
have much chance of stopping this. You might be able to confuse a simple
hacker by using your COM GUID as the random entropy you introduce into the
protection. Sometimes hiding the data somewhere obvious can be effective.

Remember, we are just trying to raise the bar here. The only way you have a
chance of making this "really" secure is by storing the data on a machine
the user doesn't have access to.

That said, if you want to try a little harder to hide it, that's fine by me.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Show quoteHide quote

"David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
news:Morvg.1368$bP5.472@newsread1.news.pas.earthlink.net...
>I thought about using external files, but putting human unreadable text in
>an external file is an invitation for someone to try to decipher it. I
>also considered putting it in the normal location in the registry as you
>suggested, but I figured this would be the first place someone trying to
>hack the database would look. That's why I considered the GUID approach in
>the CLSID section because no one would no where to look, and I could use a
>key name that is unobtrusive.
>
> It wouldn't be a problem if this were a client/server, smart client, or
> web app/service, but given the information you and Dominick have provided
> in consideration of the scenario I've proposed, it seems necessary to
> raise the bar as high as I can.
>
> Do you know any newsgroup or individual to which I can pose the question
> about the registry?
>
> Thank you again for your help.
>
> Dave
>
> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
> in message news:%23EKkDxzqGHA.5012@TK2MSFTNGP03.phx.gbl...
>> That's a good question that I can't really answer. I'm not an expert on
>> registry usage and conventions.
>>
>> It seems somewhat wrong to me to stick application data in the COM
>> registration info, but I don't really know. Based on what I've observed,
>> it would seem like the more conventional thing would be to stick the data
>> in HKLM\Software\<Your Company/Product>. I think the ultimate decision
>> is up to you. You could stick it in an ini file just as well and have
>> the same affect.
>>
>> Joe K.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> --
>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
>> news:arqvg.293$gF6.190@newsread2.news.pas.earthlink.net...
>>> Is there any reason I couldn't bury the string in
>>> HKEY_CLASSES_ROOT\CLSID and under the GUID generated for my app? Would
>>> it violate a best practice or convention?
>>>
>>> Dave
>>>
>>> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com>
>>> wrote in message news:OdGW3NfqGHA.4492@TK2MSFTNGP05.phx.gbl...
>>>>I don't think it has to be that bad. If your CA creates the protected
>>>>data with the optional entropy, then the CA can update a Windows
>>>>Installer property with the result and your installer can then just
>>>>write the data to a known registry key.
>>>>
>>>> Then, your app can read the known registry key, unprotect the data with
>>>> the .NET ProtectedData class and use it.
>>>>
>>>> You'd probably want to round trip the encrypted binary data as Base64
>>>> to make it easier to integrate with Windows installer and store in the
>>>> registry as a string. You could also write the data to a file with a
>>>> different CA.
>>>>
>>>> The CA would need to have knowledge of the plain text data, but you
>>>> might as well include that in the compiled binary. If you run the CA
>>>> from a binary in the binaries table, it would never be installed on the
>>>> file system. Someone who knew what they were doing could pull that
>>>> binary out of your MSI and reverse engineer it, but they'd probably
>>>> just use a simple DPAPI call to hack you instead. But remember, we are
>>>> just raising the bar. :)
>>>>
>>>> Joe K.
>>>>
>>>> --
>>>> Joe Kaplan-MS MVP Directory Services Programming
>>>> Co-author of "The .NET Developer's Guide to Directory Services
>>>> Programming"
>>>> http://www.directoryprogramming.net
>>>> --
>>>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in
>>>> message news:neTug.783$bP5.72@newsread1.news.pas.earthlink.net...
>>>>> Thanks for the info Dominick and Joe.
>>>>>
>>>>> So it sounds like I'll need a custom action application that processes
>>>>> the connection string using multiple encryption schemes in succession
>>>>> during installation and then hard code the decryption process in my
>>>>> app. What a pain.
>>>>>
>>>>> Dave
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

19 Jul 2006 11:21 PM

David Lee Conley

Thanks for the info, Joe. Just one more question. Wouldn't I be able to
hide the in-memory representation by using the ProtectedMemory class?

I do plan on using the "Dotfuscator" that comes with VS until I can afford a
more complete solution.

Dave

Show quoteHide quote

"Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
in message news:%23fbdLB1qGHA.3380@TK2MSFTNGP04.phx.gbl...
>I wouldn't worry about trying too hard to hide the data. Anyone using
>filemon or regmon will quickly figure out where you are storing the
>encrypted data no matter where you store it, so I don't think it is worth
>it to try to hide it too much. Also, unless you use obfuscation, they will
>easily reverse engineer your .NET code and figure out exactly how you are
>decrypting the data. A smart user with a debugger will simply attach to
>your process and read the decrypted data directly out of memory. You don't
>have much chance of stopping this. You might be able to confuse a simple
>hacker by using your COM GUID as the random entropy you introduce into the
>protection. Sometimes hiding the data somewhere obvious can be effective.
>
> Remember, we are just trying to raise the bar here. The only way you have
> a chance of making this "really" secure is by storing the data on a
> machine the user doesn't have access to.
>
> That said, if you want to try a little harder to hide it, that's fine by
> me.
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services
> Programming"
> http://www.directoryprogramming.net
> --
> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
> news:Morvg.1368$bP5.472@newsread1.news.pas.earthlink.net...
>>I thought about using external files, but putting human unreadable text in
>>an external file is an invitation for someone to try to decipher it. I
>>also considered putting it in the normal location in the registry as you
>>suggested, but I figured this would be the first place someone trying to
>>hack the database would look. That's why I considered the GUID approach
>>in the CLSID section because no one would no where to look, and I could
>>use a key name that is unobtrusive.
>>
>> It wouldn't be a problem if this were a client/server, smart client, or
>> web app/service, but given the information you and Dominick have provided
>> in consideration of the scenario I've proposed, it seems necessary to
>> raise the bar as high as I can.
>>
>> Do you know any newsgroup or individual to which I can pose the question
>> about the registry?
>>
>> Thank you again for your help.
>>
>> Dave
>>
>> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com>
>> wrote in message news:%23EKkDxzqGHA.5012@TK2MSFTNGP03.phx.gbl...
>>> That's a good question that I can't really answer. I'm not an expert on
>>> registry usage and conventions.
>>>
>>> It seems somewhat wrong to me to stick application data in the COM
>>> registration info, but I don't really know. Based on what I've
>>> observed, it would seem like the more conventional thing would be to
>>> stick the data in HKLM\Software\<Your Company/Product>. I think the
>>> ultimate decision is up to you. You could stick it in an ini file just
>>> as well and have the same affect.
>>>
>>> Joe K.
>>>
>>> --
>>> Joe Kaplan-MS MVP Directory Services Programming
>>> Co-author of "The .NET Developer's Guide to Directory Services
>>> Programming"
>>> http://www.directoryprogramming.net
>>> --
>>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in
>>> message news:arqvg.293$gF6.190@newsread2.news.pas.earthlink.net...
>>>> Is there any reason I couldn't bury the string in
>>>> HKEY_CLASSES_ROOT\CLSID and under the GUID generated for my app? Would
>>>> it violate a best practice or convention?
>>>>
>>>> Dave
>>>>
>>>> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com>
>>>> wrote in message news:OdGW3NfqGHA.4492@TK2MSFTNGP05.phx.gbl...
>>>>>I don't think it has to be that bad. If your CA creates the protected
>>>>>data with the optional entropy, then the CA can update a Windows
>>>>>Installer property with the result and your installer can then just
>>>>>write the data to a known registry key.
>>>>>
>>>>> Then, your app can read the known registry key, unprotect the data
>>>>> with the .NET ProtectedData class and use it.
>>>>>
>>>>> You'd probably want to round trip the encrypted binary data as Base64
>>>>> to make it easier to integrate with Windows installer and store in the
>>>>> registry as a string. You could also write the data to a file with a
>>>>> different CA.
>>>>>
>>>>> The CA would need to have knowledge of the plain text data, but you
>>>>> might as well include that in the compiled binary. If you run the CA
>>>>> from a binary in the binaries table, it would never be installed on
>>>>> the file system. Someone who knew what they were doing could pull that
>>>>> binary out of your MSI and reverse engineer it, but they'd probably
>>>>> just use a simple DPAPI call to hack you instead. But remember, we
>>>>> are just raising the bar. :)
>>>>>
>>>>> Joe K.
>>>>>
>>>>> --
>>>>> Joe Kaplan-MS MVP Directory Services Programming
>>>>> Co-author of "The .NET Developer's Guide to Directory Services
>>>>> Programming"
>>>>> http://www.directoryprogramming.net
>>>>> --
>>>>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in
>>>>> message news:neTug.783$bP5.72@newsread1.news.pas.earthlink.net...
>>>>>> Thanks for the info Dominick and Joe.
>>>>>>
>>>>>> So it sounds like I'll need a custom action application that
>>>>>> processes the connection string using multiple encryption schemes in
>>>>>> succession during installation and then hard code the decryption
>>>>>> process in my app. What a pain.
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

20 Jul 2006 12:49 AM

Joe Kaplan (MVP - ADSI)

Sure, that's what its for. You might also want check out SecureString. You
are sort of at the mercy of what the unmanaged code (that you didn't write)
does with the data, but it won't hurt.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Show quoteHide quote

"David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
news:y7zvg.483$gF6.365@newsread2.news.pas.earthlink.net...
> Thanks for the info, Joe. Just one more question. Wouldn't I be able to
> hide the in-memory representation by using the ProtectedMemory class?
>
> I do plan on using the "Dotfuscator" that comes with VS until I can afford
> a more complete solution.
>
> Dave
>
> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
> in message news:%23fbdLB1qGHA.3380@TK2MSFTNGP04.phx.gbl...
>>I wouldn't worry about trying too hard to hide the data. Anyone using
>>filemon or regmon will quickly figure out where you are storing the
>>encrypted data no matter where you store it, so I don't think it is worth
>>it to try to hide it too much. Also, unless you use obfuscation, they
>>will easily reverse engineer your .NET code and figure out exactly how you
>>are decrypting the data. A smart user with a debugger will simply attach
>>to your process and read the decrypted data directly out of memory. You
>>don't have much chance of stopping this. You might be able to confuse a
>>simple hacker by using your COM GUID as the random entropy you introduce
>>into the protection. Sometimes hiding the data somewhere obvious can be
>>effective.
>>
>> Remember, we are just trying to raise the bar here. The only way you
>> have a chance of making this "really" secure is by storing the data on a
>> machine the user doesn't have access to.
>>
>> That said, if you want to try a little harder to hide it, that's fine by
>> me.
>>
>> Joe K.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> --
>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in message
>> news:Morvg.1368$bP5.472@newsread1.news.pas.earthlink.net...
>>>I thought about using external files, but putting human unreadable text
>>>in an external file is an invitation for someone to try to decipher it.
>>>I also considered putting it in the normal location in the registry as
>>>you suggested, but I figured this would be the first place someone trying
>>>to hack the database would look. That's why I considered the GUID
>>>approach in the CLSID section because no one would no where to look, and
>>>I could use a key name that is unobtrusive.
>>>
>>> It wouldn't be a problem if this were a client/server, smart client, or
>>> web app/service, but given the information you and Dominick have
>>> provided in consideration of the scenario I've proposed, it seems
>>> necessary to raise the bar as high as I can.
>>>
>>> Do you know any newsgroup or individual to which I can pose the question
>>> about the registry?
>>>
>>> Thank you again for your help.
>>>
>>> Dave
>>>
>>> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com>
>>> wrote in message news:%23EKkDxzqGHA.5012@TK2MSFTNGP03.phx.gbl...
>>>> That's a good question that I can't really answer. I'm not an expert
>>>> on registry usage and conventions.
>>>>
>>>> It seems somewhat wrong to me to stick application data in the COM
>>>> registration info, but I don't really know. Based on what I've
>>>> observed, it would seem like the more conventional thing would be to
>>>> stick the data in HKLM\Software\<Your Company/Product>. I think the
>>>> ultimate decision is up to you. You could stick it in an ini file just
>>>> as well and have the same affect.
>>>>
>>>> Joe K.
>>>>
>>>> --
>>>> Joe Kaplan-MS MVP Directory Services Programming
>>>> Co-author of "The .NET Developer's Guide to Directory Services
>>>> Programming"
>>>> http://www.directoryprogramming.net
>>>> --
>>>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in
>>>> message news:arqvg.293$gF6.190@newsread2.news.pas.earthlink.net...
>>>>> Is there any reason I couldn't bury the string in
>>>>> HKEY_CLASSES_ROOT\CLSID and under the GUID generated for my app?
>>>>> Would it violate a best practice or convention?
>>>>>
>>>>> Dave
>>>>>
>>>>> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com>
>>>>> wrote in message news:OdGW3NfqGHA.4492@TK2MSFTNGP05.phx.gbl...
>>>>>>I don't think it has to be that bad. If your CA creates the protected
>>>>>>data with the optional entropy, then the CA can update a Windows
>>>>>>Installer property with the result and your installer can then just
>>>>>>write the data to a known registry key.
>>>>>>
>>>>>> Then, your app can read the known registry key, unprotect the data
>>>>>> with the .NET ProtectedData class and use it.
>>>>>>
>>>>>> You'd probably want to round trip the encrypted binary data as Base64
>>>>>> to make it easier to integrate with Windows installer and store in
>>>>>> the registry as a string. You could also write the data to a file
>>>>>> with a different CA.
>>>>>>
>>>>>> The CA would need to have knowledge of the plain text data, but you
>>>>>> might as well include that in the compiled binary. If you run the CA
>>>>>> from a binary in the binaries table, it would never be installed on
>>>>>> the file system. Someone who knew what they were doing could pull
>>>>>> that binary out of your MSI and reverse engineer it, but they'd
>>>>>> probably just use a simple DPAPI call to hack you instead. But
>>>>>> remember, we are just raising the bar. :)
>>>>>>
>>>>>> Joe K.
>>>>>>
>>>>>> --
>>>>>> Joe Kaplan-MS MVP Directory Services Programming
>>>>>> Co-author of "The .NET Developer's Guide to Directory Services
>>>>>> Programming"
>>>>>> http://www.directoryprogramming.net
>>>>>> --
>>>>>> "David Lee Conley" <conley3500@earthlink.net.nospam.com> wrote in
>>>>>> message news:neTug.783$bP5.72@newsread1.news.pas.earthlink.net...
>>>>>>> Thanks for the info Dominick and Joe.
>>>>>>>
>>>>>>> So it sounds like I'll need a custom action application that
>>>>>>> processes the connection string using multiple encryption schemes in
>>>>>>> succession during installation and then hard code the decryption
>>>>>>> process in my app. What a pain.
>>>>>>>
>>>>>>> Dave
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>