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 I 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
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
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
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 I 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
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]
