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

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
--
"David Lee Conley" <conley3500@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:y7zvg.483$gF6.365@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote
in message news:%23fbdLB1qGHA.3380@xxxxxxxxxxxxxxxxxxxxxxx
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