RE: Credentials for Application use

[Gunnar Peterson <gunnar () arctecgroup net>]

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.html
&
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: [EMAIL PROTECTED]
> 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?