At 10:34 PM 1/9/01 +1100, Geoff Worboys wrote:

>> Let us suppose I have a completely pre-configured solution
>> and I don't want customers to have full access to the database.
>
>A curious scenario in the brave new world of open source :-)
>
>It was previously suggested that the ISC4.GDB was a well know
>"weakness". I would suggest that it is really a design decision made
>a long time ago. So it is not a weakness or a bug, but working as
>designed.
>

Virtually everything about ISC4.GDB is flawed -- the concept, the
design, and the implementation. An example of the bad thinking
is the idea of client side encryption of passwords. They were
obviously worried about someone sniffing the packets and discovering
the password. So they sent the encrypted password. What didn't
occur them was that an intercepted encrypted password was just
as good as an unencrypted password. Either will give you access.

Trying to fix ISC4.GDB is hopeless. It was designed by folks
profoundly clueless about security and encryption. It would be
much better to excise the porker and replace it with something
robust.

A barrier to good encryption in the past was the RSA patent. It
expired last September. Public key encryption code is available
essentially license free. Use it.

>AFAIK any further security will require some form of encryption, and
>the only way this would be properly secure is if the key was provided
>manually every time the server restarts - which is rather impractical
>for a database distributed to many customers that dont know the key.
>(And there are existing solutions to support the manually entered key
>scenario.)

Not so. Here is a simple scheme that works:

1. Server generates a public key encyption key pair at startup
time.
2. Passwords are stored in the target database using
SHA (secure hash algorithm, which gives a 160 bit
hash).
3. On initial connect, the server gives the client the
public encryption key.
4. The client uses the server public key to encrypt the
password.
5. Server uses private key to decrypt password, SHA to hash
it, and checks against database.

Storing authentication information outside of the database requires
that the repository has exactly the access privileges as the
database server itself. Virtually major system on Unix (login,
httpd, cvs, etc) use a variant. These systems dependend on the
Unix file security semantics (simplistic but robust). Trying
to achieve the same level with ISC4.GDB is going to be very, very
difficult.

>
>Other suggestions require that the key is stored somewhere. Cant put
>it in the registry, the customer will have access. Could put it in
>the ISC4 database but then we just copy that database somewhere and
>extract independantly (it is just a GDB after all).
>

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

>So the question becomes: Do you really want to spend time on a
>half-baked security solution? Some say "keep honest people honest" -
>they are always the ones we stick it to, because they make it so easy.
>;-)

There is no reason, ever, to build a half-baked security system.
It must be done right.



Jim Starkey