Re: [SC-L] Credentials for Application use
"Gizmo" <[EMAIL PROTECTED]> wrote: > the efficacy of the encryption is of some question. > Basically, it keeps honest people honest. Sounds a little better than I thought, but I'd still be worried about the owner name leaking into less honest hands. > 1) The app is architected around the Btrieve DB, with uses a > proprietary API. We can argue the merits of that until the cows come > home, but it probably isn't relevant to this list. Right, though come to think of it, the whole question is borderline off-topic, seeing as this is *Secure* Coding, not *Security* Coding. :-)
RE: [SC-L] Credentials for Application use
At 9:39 AM -0400 5/12/05, Goertzel Karen wrote: >I'm wondering whether role-based credentials, vs. individual user >credentials, might not make more sense here. Could the database owner >key be issued to a role vs. an individual identity? That seems to get in the way of auditability. -- Larry Kilgallen
RE: [SC-L] Credentials for Application use
I'm wondering whether role-based credentials, vs. individual user credentials, might not make more sense here. Could the database owner key be issued to a role vs. an individual identity? In this way, your human users could be associated with a role that has a right to issue a query to the database via the middleware, but only the middleware would be associated with the role that had access to the key that could decrypt the data that satisfies the user's query. This does not, however, solve the problem of ensuring that the data remain secure once they are decrypted. You don't mention the assurance level of the encryption used in the database - i.e., does it exceed the strength of SSL or TLS with encryption based on AES and Class 3 X.509 certificates? Some interesting work doing on at INRIA in France that may be relevant: www-smis.inria.fr/Etheme_2._Data_confidentiality.html Also, some combination of the capabilities provided by nCipher may be of interest: www. ncipher.com -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703-902-6981 [EMAIL PROTECTED]
RE: [SC-L] Credentials for Application use
The Pervasive.SQL database has two access modes: native Btrieve and SQL. The native Btrieve mode has as it's major advantage that it is about 10 times faster than MSSQL on the same hardware. However, it is NOT SQL; it is a transactional database engine designed for applications that need a small footprint and a bad fast data storage and retrieval mechanism. To answer your questions, Btrieve does not allow a user to query the owner name of the DB. You have to know the owner name in order to access the db at all. Presumably that information is stored within the DB file somewhere, but without a hex editor you aren't getting at it, and if you use the owner name to encrypt the db, then even WITH a hex editor you aren't getting at it. Unfortunately, the owner name is only 8 chars, and is alpha-numeric only (case sensitive), so the efficacy of the encryption is of some question. Basically, it keeps honest people honest. As for the reason I don't use something else, well, there are a couple of reasons: 1) The app is architected around the Btrieve DB, with uses a proprietary API. We can argue the merits of that until the cows come home, but it probably isn't relevant to this list. 2) The performance of the application is very sensitive; speed is paramount. Believe it or not, there are applications where simply throwing more CPUs at a problem isn't really a valid response. It is probably valid to assert that, with HIPAA requirements coming onto the playing field, the Btrieve mode of access is not the best tool for the job, but that isn't a decision that I can make. My masters in Atlanta control my time. Later, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Aronson Sent: Wednesday, May 11, 2005 8:37 PM To: sc-l@securecoding.org Subject: Re: [SC-L] Credentials for Application use "Gizmo" <[EMAIL PROTECTED]> wrote: > 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. That sure doesn't sound secure to me! Does BTrieve make it easy, difficult, or impossible to see what users own what dbs? Does it make it easy/diff/imposs to see what users exist? Does it have well-defined syntax rules for the usernames, and maybe even a fairly short maximum length? Unless the names can be very long (as in, at least a few dozen chars), with very little restriction on content (as in, case sensitive, and including spaces and punctuation), and BT makes it *impossible* to see what users exist, let alone own what, then the entire "security" there is basically nothing more than one incredibly weak 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. Looks like BTrieve "security" is pretty much useless, except possibly for giving a tiny bit of protection to transmission of the entire db. > The only way can see to deal with this is something > similar to what I've done in my app: You probably don't need to get that fancy. The first question that both I and my wife thought of is, why not migrate to something with more useful security than BT? B-) But seriously, that brings up the very first question usually asked when developing a security strategy. Exactly what threat(s) are you trying to secure it *against*? Who will be doing what, how, maybe why, possibly even when and (from) where? > and the registry. ...which means you're running Windows, which means security isn't really much of a priority after all. B-)/2 -Dave
Re: [SC-L] Credentials for Application use
If you are just talking about a password to access a db, the 'typical' approach (at least the approach I use) is just to store that password in the code/config file. You may like to add a layer to that by encrypting it in some config file, and requiring a 'decryption' (initialisation) of the 'server' to take place, where the key is entered and the db password is kept in 'application' memory until the next reset, etc. But, if you want to use the db resource manage permissions for various users AS WELL as your app logic (i.e. some redundant security system; [which is good]) then you'll need to create sql/whatever accounts for each user, obviously. Depends what you want, I guess. I think the answer to your question is that the password is stored in a config file. -- Michael On 5/12/05, Mikey <[EMAIL PROTECTED]> wrote: > Chris, > > Your situation is a little unique in that you encrypt the data with the > password. The data backend I was referring to is simply a backend database > like an SQL Server, Oracle 8i or DB2 data repository. All users need to do > to get access to it is to authenticate to it and then have the right access > controls to its tables/rows. > > SSO may solve my problem but the problem I have right now is that SSO is > not here for us yet. What I like to understand is from people with > experience in this stuff who have not implemented enterprise SSO solutions > so that I can get that light bulb above my head to work. :-) > > Thanks. > > At 11:00 AM 11/05/2005 -0500, Gizmo wrote: > >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
RE: [SC-L] Credentials for Application use
Chris, Your situation is a little unique in that you encrypt the data with the password. The data backend I was referring to is simply a backend database like an SQL Server, Oracle 8i or DB2 data repository. All users need to do to get access to it is to authenticate to it and then have the right access controls to its tables/rows. SSO may solve my problem but the problem I have right now is that SSO is not here for us yet. What I like to understand is from people with experience in this stuff who have not implemented enterprise SSO solutions so that I can get that light bulb above my head to work. :-) Thanks. At 11:00 AM 11/05/2005 -0500, Gizmo wrote: >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
RE: [SC-L] Credentials for Application use
This is all well and good but we are talking different authentication and access control boundaries. Your references refer to Microsoft technologies that does not necessarily apply in a large scale enterprise scenario with heterogeneous systems. Sorry. At 10:20 AM 11/05/2005 -0500, Gunnar Peterson wrote: >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 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
Re: [SC-L] Credentials for Application use
"Gizmo" <[EMAIL PROTECTED]> wrote: > 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. That sure doesn't sound secure to me! Does BTrieve make it easy, difficult, or impossible to see what users own what dbs? Does it make it easy/diff/imposs to see what users exist? Does it have well-defined syntax rules for the usernames, and maybe even a fairly short maximum length? Unless the names can be very long (as in, at least a few dozen chars), with very little restriction on content (as in, case sensitive, and including spaces and punctuation), and BT makes it *impossible* to see what users exist, let alone own what, then the entire "security" there is basically nothing more than one incredibly weak 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. Looks like BTrieve "security" is pretty much useless, except possibly for giving a tiny bit of protection to transmission of the entire db. > The only way can see to deal with this is something > similar to what I've done in my app: You probably don't need to get that fancy. The first question that both I and my wife thought of is, why not migrate to something with more useful security than BT? B-) But seriously, that brings up the very first question usually asked when developing a security strategy. Exactly what threat(s) are you trying to secure it *against*? Who will be doing what, how, maybe why, possibly even when and (from) where? > and the registry. ...which means you're running Windows, which means security isn't really much of a priority after all. B-)/2 -Dave
RE: [SC-L] Credentials for Application use
At 11:28 AM -0400 5/11/05, Goertzel Karen wrote: >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); That depends on the security of the channel between the user and the entity authenticating the password. A fixed password used to unlock a token by entering it into keys on the token is not bad. Use the keyboard associated with a programmable computer, and you increase the risks monumentally. -- Larry Kilgallen
RE: [SC-L] Credentials for Application use
At 11:00 AM -0500 5/11/05, Gizmo wrote: >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. That is _one_ (relatively insecure) method of implementing single sign-on. The general definition of single sign-on is that a user only logs on once to access a variety of computer applications. For some applications, relying entirely on Microsoft's credentials is adequate. For some applications, relying on the TSO login is adequate. For some applications, relying on Kerberos credentials is adequate. etc. -- Larry Kilgallen
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 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? > > >
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.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 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? > > >
RE: [SC-L] Credentials for Application use
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 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? > > >
RE: [SC-L] Credentials for Application use
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 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 &
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 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?
