I'm thinking that, architecturally, you might want to head in a slightly different direction.
Storing of common data related to an application might require a network sub folder restricted to a security group, rather than going for an encryption (and an implementation of isolated storage?) Domain | v Site | v Group | v User Also, applications can run under a separate user account too, if you want to head down that path, with a network home drive. HTH, Chay Harley -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Mont Rothstein Sent: Friday, March 28, 2008 9:25 AM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Storing shared secrets Chris and Erik, thank you for the additional thoughts. The problem with impersonating a specific user, is that you then have to have the password for that user. Storing a salt or other key value in my assembly is what I am trying to avoid. Unless I am missing something there just doesn't seem to be a way to create a secure path between an app and stored data without something key (salt, password, etc.) being stored in a readily available format. I consider in-the-assembly to be readily available. -Mont =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of any entity within the KBC Financial Products group of companies (together referred to as "KBC FP"). This message does not create any obligation, contractual or otherwise, on the part of KBC FP. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC FP would enter into a transaction, or prices at which similar transactions may be carried on KBC FP's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
