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