|Subject||Re: [IB-Architect] Re: Nailing down the external file problem.|
> Not so. Here is a simple scheme that works:<...>
> It is never necessary to store a key anywhere other thanThe scheme you described works for passwords because the keys in this
> in the server process memory.
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
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 timeI agree, but the system you have described only covers the way to
> >on a half-baked security solution?
> There is no reason, ever, to build a half-baked security system.
> It must be done right.
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?