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

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@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:Morvg.1368$bP5.472@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote
in message news:%23EKkDxzqGHA.5012@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:arqvg.293$gF6.190@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:OdGW3NfqGHA.4492@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:neTug.783$bP5.72@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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











.

Relevant Pages