--- In firebird-support@yahoogroups.com, Noprianto <opennopri@...> wrote:
>
> Hello Paul
>
> Thank you very much for replies. I really appreciate
> it.
>
> --- Paul Vinkenoog <paul@...> wrote:
>
> > Hello Pri,
> >
> > > In my case, filesystem level permission is not
> > applicable.
> >
> > Do you mean that it will (also) be installed on
> > filesystems that don't
> > have access protection (like FAT) ?
> Yes :(
>
> > If so, anybody with access to the filesystem can
> > grab the database,
> > take it home and examine it. You can encrypt the
> > data, but since
> > that's done by an application on the same computer
> > (if you use
> > Embedded), malicious users could also copy the
> > application and
> > decompile it.
> Yeah. IMHO, Encrypting the data also make me harder
> deal with report generator (since report generator i
> use read directly from dataset dan display it; i have
> no chance to decrypt it before display).

Hmm, that is a very hard requirement to meet. You want it impossible
for a malicious person to gain access to your data yet you have
eliminated the possibility of protecting the private key on the file
system. You have also put restrictions on the data access that says
that the client application (report engine in this case) must have the
ability to run arbitrary queries and not have to decrypt it.

The best you can really do if those are your requirements is to not
tell the user their own password, hash whatever they use as a password
+ some private string with SHA-1 or MD5 etc, and make that their
password. Providing you give the user no file system access to the
database file, the only attack vector would be brute force.

> >
> > Metadata can't be encrypted, except that you can
> > delete the PSQL
> > source of your stored procedures and triggers (not
> > that it will help
> > you a lot - see the meta security article that Adam
> > referred you to).
> Thanks. I already read that manual and it help me a
> lot. I think, actually, we wont have many stored
> procedure and/or triggers.
>
>
> >
> > Also ask yourself - if you encrypt the data on an
> > unprotected
> > filesystem, how are you going to protect the key?
> > It's very very hard
> > to protect anything if you work on a filesystem
> > where you can't shield
> > data from unauthorized access.
> >
> Hehehe. Yes. It would be very hard. I think the key
> would be entered by user?

If the user knows the key, then why is any security required? After
all, if they are malicious, they can use the key that they know to
unlock it when they need to access or manipulate data.

>
> > If the database must be accessed from other
> > computers than the one it
> > lives on, you can't use Embedded. The database must
> > always be on the
> > same computer (physically! no network paths) as the
> > server, whether
> > it's an embedded or a regular server.
> Hmm. Seems as bad news to me :( I am stupid thinking
> of sharing database file using SMB or NFS. Thanks a
> lot for this information. I am little confused, why MS
> Access database doesnt have this problem? MS Access
> Database must be more simpler than FB.

Stupid is too strong a word, it is a common mistake when coming from
a desktop database to think that tables must be shared. Think of the
server as an agent. The client application is not allowed to read from
the file, nor is it allowed to write to the file, only the agent can
do that. All the client application can do is to ask the agent to do
something (via a SQL query). So the agent needs complete access to the
file, but the client application only needs access to the agent. You
can take this even further my developing a data abstraction layer, a
service that is allowed to connect to the agent and your client
application must then go through that data abstraction layer. (Like
having a client talking to an agent which talks to another agent which
finally reads or writes to the file.

Access doesn't have this problem?

Google for data recovery from MS Access if you think it is really
bullet proof. If you want it to be "as secure" as MS Access (but do
not confuse this with secure), then you should be able to emulate it
using some third party file system level encryption utility, of which
their are many.

I also wrote a paper a while back that actually started from a similar
question. It contains attack vectors that you may want to also consider.

http://www.fbtalk.net/viewtopic.php?id=290

Adam