> Not so. Here is a simple scheme that works:

<...>

> It is never necessary to store a key anywhere other than
> in the server process memory.

The scheme you described works for passwords because the keys in this
instance only need to be valid while the server is running. I did not
realise that Interbase did not already implement something along the
lines of what you have described - I am glad to have that
misconception cleared.

I am not sure why the solution you described cannot be incorporated
into the ISC4 database. Care to elaborate?

> >So the question becomes: Do you really want to spend time
> >on a half-baked security solution?
>
> There is no reason, ever, to build a half-baked security system.
> It must be done right.

I agree, but the system you have described only covers the way to
manage passwords. It is definitely worth improving the password
management if it is as weak as you describe. However it does not
cover the scenario to which I was responding.

The earlier posting was looking for a way to "hide" the database
structure details from the customer. In the past, others have
complained that a person with access to the server (having the server
admin password) can copy the database and install on a different
system where they know the SYSDBA password.

It is acceptable to store passwords has a hash, because it is never
necessary to actually decrypt a password used in this way. It is not
an acceptable method of storage for customer or structural data. It
must either be stored plain, or with encyption (to which the key
remains constant between server instances).

Can you think of a system that works in this situation?

Geoff Worboys
Telesis Computing