--- 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.


> 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.
>

There is still a need to maintain a valid user profile database
somewhere, this isn't so bad a place (perhaps it will need a changed
format though) it can store the hash of the passwords, (if we keep
using passwords) or it can store their client certificate.

> 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.
>

I agree (SSLEAY is one I've used, (since Eric and Tim are Australians,
well Queenslanders) but they have moved on to form RSA/Australia, and
openssl has taken over their work. And there is now also the
opensource crypto modules for netscape. These are all good sources
not just of basic PKI but also a Certificate Authority and SSL.


> >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...).


> 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):

> 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.

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.


> 2. Passwords are stored in the target database using
> SHA (secure hash algorithm, which gives a 160 bit
> hash).

SHA/MD5 should be on salt + username + password,
avoids some problems with same passwords and pregenerated library
attacks.

> 3. On initial connect, the server gives the client the
> public encryption key.

Server should also give timestamp, msg seq number, some Server-random
data + cert and a signature of all the previous contents it sends to
the client.

Client checks signature (optionally checks cert with CA cert). Check
timestamp, and msg seq number.

Basically to stop man in the middle, or replay attacks.

> 4. The client uses the server public key to encrypt the
> password.

Client creates message client-random data block + msg seq + timestamp
+ server random + password.

encrypts using server public key.

> 5. Server uses private key to decrypt password, SHA to hash
> it, and checks against database.
>
Decrypt message
Check server random is same,
Check timestamp,
Check sequence,
Hash password salt + username + password


> 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.
>

On linux, solaris, PAM (pluggable authentication module) provides most
of this.(Im not too familure with it, but I've had a quick look).

> >
> >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).
> >
>

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.

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

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.


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

The computing world is a less trusting place than it was on a private
lan 10-15 yrs ago. In todays world, I think this stuff has to be done
correctly and carefully. Also many eyes, here will probably help make
it work better.

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.


Cheers


Mark