Secure Coding mailing list archives
RE: Credentials for Application use
From: "Goertzel Karen" <goertzel_karen () bah com>
Date: Wed, 11 May 2005 21:07:09 +0100
Isn't a Single Sign-on System supposed to address exactly this kind of problem? Users need to be authenticated individually. Also, they don't want to have to deal with multiple sets of credentials and different login procedures for different apps/systems. Login requirements for various apps and backend systems vary. The SSO system deals with the discrepancies. Of course, and SSO is only as secure as (1) the assurance of the credential on which it bases its authentication decisions (a static password with an SSO is a really STUPID idea); (2) its own trustworthiness and assurance. An SSO a piece of highly trusted software in any environment - essentially "the keys to the kingdom". Thus it needs to be highly trustworthy and very strongly protected against compromise. To my mind, that means (1) rigorous security testing before acquisition and before deployment (not just relying on Common Criteria EAL, because that doesn't indicate the real security of anything); (2) a higher-assurance platform than Linux, UNIX, Windows, or OS X - at the very least, a "hardened", minimized operating system like those used to host firewalls. Better yet, correctly-configured TSol. -- Karen Goertzel, CISSP Booz Allen Hamilton 703-902-6981 [EMAIL PROTECTED]
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gizmo Sent: Wednesday, May 11, 2005 10:52 AM To: [EMAIL PROTECTED] Subject: RE: [SC-L] Credentials for Application use 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?
Current thread:
- Credentials for Application use Mikey (May 11)
- RE: Credentials for Application use Gizmo (May 11)
- RE: Credentials for Application use Gunnar Peterson (May 11)
- RE: Credentials for Application use Gizmo (May 11)
- RE: Credentials for Application use Mikey (May 12)
- RE: Credentials for Application use Gunnar Peterson (May 11)
- <Possible follow-ups>
- RE: Credentials for Application use Goertzel Karen (May 11)
- RE: Credentials for Application use Gizmo (May 11)
- RE: Credentials for Application use ljknews (May 11)
- Re: Credentials for Application use Dave Aronson (May 12)
- RE: Credentials for Application use Gizmo (May 12)
- Re: Credentials for Application use Dave Aronson (May 13)
- RE: Credentials for Application use Gizmo (May 11)
- RE: Credentials for Application use Mikey (May 12)
- Re: Credentials for Application use Michael Silk (May 12)
- RE: Credentials for Application use Gizmo (May 11)
- RE: Credentials for Application use ljknews (May 12)