Hi,

> Hi Jim et al.
>
> --- In IB-Architect@egroups.com, Jim Starkey <jas@n...> wrote:
>
> >
> > 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.
> >
>
> Yes this particularly points to not really understanding it. It
> implies trust in all possible client processes by the server. Not
> really acceptable nowadays.
>
>

Nowadays, before you give your mother a kiss you have to present her a few
chalenges from your childhood to see if it's really her and not an
impersonator. :-)

> > >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.)
> >
>
> This is basically the case in most server environments, that run
> unattended. The private key sits somewhere or the password to acess
> the encrypted key does (host name or something). If you are serious
> then you have hardware boards where the private key never leaves it.
>
> It is important the realise that if the server is compromised then the
> local programs can be manipulated and then basically you are stuffed
> (Ok there are some cases with hardward crypto and both client and
> server certificates...).
>
>

I'd leave open an alternative that is not too complex to store the private
key on the server. Considering that no system is safe, Phil Zimmerman
(creator of PGP), repeatedly points out in his PGP documentation that you
are responsible for the safety of your computer. PGP trusts that the system
is free of virus and trojans and so makes
no effort to defend itself from these aggressors.

I've been working in a PKI related project for over 3 years now. Only
recently I've come to understand that you are never paranoid enough to stop
everyone and that there is a point where you might actualy stop yourself and
your system with too much security complexity without actually achieving
your goal of stopping invasion.

> > Not so. Here is a simple scheme that works:
> >
>
> I know you said simple, but it's basically points the right way to go,
> so here are my comments on what can be added (Im going for a complete
> PKI solution with a CA not just generate a RSA keypair on the fly):
>

A complete PKI solution is cartainly the way to go, once you start down this
path. This would, also, vault InterBase right to the top of the stack of
dabase servers, where PKI enabled solutions are required. It seems that
Oracle started down this path but in a road full of bumps. (I've heard
several serious security problems related, including one where you are
allowed to upload Java code that will have complete access to the data in
the database and can so return such data to you, even though you do not
access previleges to that data.

> > 1. Server generates a public key encyption key pair at startup
> > time.
>
> Server generates install or at user discression a root CA certificate.
> The Ca cert private key is held encrypted (usually 3DES) and requires
> a user entered password to be used.
>

From what I've heard Blowfish or TwoFish might be better options of
symmetric algorithms. I've heard that there are known attacks that can be
used in most variants of DES, including 3DES, that significantly reduce the
work involved in a brute force attack, while no such attacks have been
discovered for Blowfish (TwoFish is after all younger, but also with no
known vulnerabilities.)

> A server certificate and private key is generated, the server private
> key is stored on disk accessible only to the server process, perhaps
> encrypted with a local password.
>
> Having a PKI CA structure leaves open the option then that the client
> can authenticate that the server is valid (handy across the internet).
> And the possibility of generating client certificates at some stage as
> well which is a bit tougher login process than just a password and is
> also useful.
>
>

Specially if it is possible, but not required that you use a certificate
from an authority such as Verisign. I believe however that you should be
able to create your own CA and sign your own certificates without having to
pay for it.

>
> Usually the private key is stored in 3DES encrypted format on the
> server somewhere (or in a smartcard). the password needs to be stored
> somewhere, but there is an assumption that the server box is secure,
> since if that fails, then someone could knock off the server process
> anyway and replace it.
>

One cheap alternative hardware nowadays is the mini-key.

> I think the PKI works well, since it would allow the client to
> authenticate the server avoiding man in the middle, attacks.
>

Couldn't agree more. It would also be very good marketing-wise. It would
associate InterBase with a technology that considered "state of the art" at
this time. Even though I know from direct experience that many offerings in
the PKI market are riddled with holes.

> Also it is fairly easy to extend the above into an true SSL session,
> if the client has a certificate generated by the same CA. The
> possibility of sharing the CA amongst several servers is also
> possible.
>
>

Very good addition, SSL would give us standards complient encryption between
client and server which would be a very nice marketing touch too. After
all, people need good reasons to move from other DBs to InterBase and a free
DB that offers better support for market standards is a very atractive
alternative, from my point of view.

>
> Because if you are deluded into thinking you have a secure system,
> that probably places you in a worse position than having an insecure
> system in the first place.
>
>

I've watched a commercial PKI solution be torn to pieces over the period of
3 months by a person working on it on his spare time.

Imagine how incorrectly safe the users of such solution must feel...

Best regards,

Mauricio Longo