Maybe I don't fully understand the concept of Single Sign-On. As I understand it, SSO allows a user to login to an application portal, and all of the applications that user accesses via that portal know who the user is and what rights they have within their respective application realms. As such, it is a front-end technology; the back-end applications don't know anything about this. Since my application is a server in a client-server architecture, it is a back-end app. In any case, SSO wouldn't help the situation where the data are encrypted by the password, if the data are accessed by more than one user. The idea behind this implementation is to ensure that even if a bad guy gains access to the server and the data files of the DB, he still can't get at the actual data without the key.
Or am I missing something? Later, Chris -----Original Message----- From: Goertzel Karen [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 10:29 AM To: Gizmo; SC-L@securecoding.org Subject: RE: [SC-L] Credentials for Application use 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: SC-L@securecoding.org > 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: 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? > > >
