Re: Help encrypt conn string - no ASP, no server, can't protect keys, can't use Windows Authentication
- From: "Joe Kaplan \(MVP - ADSI\)" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 19 Jul 2006 09:04:35 -0500
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
.
- Prev by Date: Re: Decryptionfailed to bring original text back....
- Next by Date: Re: SMIME Decryption
- Previous by thread: Decryptionfailed to bring original text back....
- Next by thread: Re: Help encrypt conn string - no ASP, no server, can't protect keys, can't use Windows Authentication
- Index(es):
Relevant Pages
|
