RE: Credentials for Application use

["Gizmo" <gizmo () digistar com>]

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: [EMAIL PROTECTED]
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