Neither impersonation nor delegation work for this environment: the DB itself is encrypted using the owner name as the key. It doesn't matter in the slightest what user rights you have to the server; if you don't have the owner name you can't decrypt the data in the DB (at least, not without a LOT of effort).
As I understand it, delegation and impersonation are of value in situations where you have multiple users directly accessing the same resources, or you wish to be able to log who accessed a resource and when. Ideally, in a client-server architecture only the server accesses the resources; therefore only the server needs access and the server can authenticate the client in whatever manner it chooses as well as logging who the access was for. Or am I missing your point? Later, Chris -----Original Message----- From: Gunnar Peterson [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 10:21 AM To: Gizmo Cc: SC-L@securecoding.org Subject: RE: [SC-L] Credentials for Application use Keith Brown has a good discussion of at least one of the design choices, namely delegation vs. impersonation: http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsDelegation.ht ml & http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsImpersonation .html -gp Quoting Gizmo <[EMAIL PROTECTED]>: > I have a similar situation in one of my applications. The customer wishes > to secure the database. Since we use a Btrieve database, the only way to do > this is be setting an owner name on the DB, and then encrypting using the > owner name as the password. However, once the DB is secured, you can't > access it unless you have the owner name, and giving out the owner name to > everyone who uses the app to access the DB pretty much defeats the whole > purpose of the exercise. > > The only way <I> can see to deal with this is something similar to what I've > done in my app: > > The user provides the management console with the password to secure the DB. > The app encrypts the password using the blowfish algorithm and a private > key. It then postpends a SHA1 hash, Base64 encodes the result, and stores > it in three places: a local configuration file, a remote configuration file, > and the registry. All three stores are secured using an ACL such that only > the user the main server app runs under has access to the data. In the > event that one of the stores is corrupted or tampered with (as determined by > the SHA1 hash) voting logic is used to determine which stored password is to > be discarded. > > I imagine that someone here has a better idea, and if so, I'd love to hear > it. > > Later, > Chris > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Mikey > Sent: Tuesday, May 10, 2005 6:49 PM > To: SC-L@securecoding.org > Subject: [SC-L] Credentials for Application use > > > This is a broad question around the current practices and recommendation of > what not to do when it comes to credentials used by applications to gain > access to a resource or data stored elsewhere. > > As an example, I have some middleware components that need to gain access > to a data repository that contains sensitive information. The middleware > components and data repository reside in separate, distinct security > boundaries protected by differing authentication and access control > mechanisms. > > Application developers insists the only way to gain access to the data > repository is to create a set of credentials for the repository that only > they can use. But because the middleware components are using it, there is > no requirement for a user to enter those credentials in order to > authenticate usage. I guess I wouldn't want the users to know the details > of this set of credentials either. > > Short of creating a user credential for each user accessing the application > on the data repository side, they insist that they need to store the userid > and password in a static format somewhere on the middleware server. For > example, a configuration file or some part of the operating system. > > Is there a best practice guideline for this scenario? What have other > people in the same situation been doing here? > > >
