Subject | Re: [Firebird-Architect] RC4 |
---|---|
Author | Milan Babuskov |
Post date | 2010-11-17T10:34:20Z |
Jim Starkey wrote:
while this kind of architecture is completely reasonable for
public-facing systems, it is not appropriate for Firebird. Any kind of
public key mechanism like this one is susceptible to man-in-the-middle
attacks. The only thing that makes it work is that you have a hierarchy
of CAs and digital signatures covering all the trusted keys. That scheme
is perfect for a SSL web server that requires the client to be online
anyway, and also expects access from anonymous clients.
Establishing a common CA which would provide digital signature for keys
of every Firebird installation worldwide does not seem likely.
However, it is assumed that when deploying your Firebird applications,
you have control (or access) to both client and server side. Why not
simply use a scheme like SSH or ZeBeDee?
This means that you would create a public/private key pair for each
client and have something like authorized_keys on the server, similar to
SSH or ZeBeDee. You distribute private keys to clients and keep the
public keys on the server. Upon connection, the server generates a
symmetrical key (that uses some quick algorithm) which will be used for
further communication. The server encrypts this key using client's
public key and sends it. Since the client is the only party being able
to decrypt that message, it prevents from man-in-the-middle attach.
--
Milan Babuskov
==================================
The easiest way to import XML, CSV
and textual files into Firebird:
http://www.guacosoft.com/xmlwizard
==================================
> Here is the architecture:Hi Jim,
>
> 1. Servers generate RSA key pairs at startup time. They may, if they
> wish, generate new key pairs anytime they wish.
> 2. On first connection to a server, the client is given the server's
> public key and a list of supported encryption algorithms.
> 3. The client selects an algorithm, generates a one-time session key
> using a secure random number generator, encrypts the algorithm
> type and session key using the server's public key, and sends the
> gook to the server
> 4. The server decrypts the gook with its private key.
> 5. Passwords are stored in the database as SHA-1 hashes
while this kind of architecture is completely reasonable for
public-facing systems, it is not appropriate for Firebird. Any kind of
public key mechanism like this one is susceptible to man-in-the-middle
attacks. The only thing that makes it work is that you have a hierarchy
of CAs and digital signatures covering all the trusted keys. That scheme
is perfect for a SSL web server that requires the client to be online
anyway, and also expects access from anonymous clients.
Establishing a common CA which would provide digital signature for keys
of every Firebird installation worldwide does not seem likely.
However, it is assumed that when deploying your Firebird applications,
you have control (or access) to both client and server side. Why not
simply use a scheme like SSH or ZeBeDee?
This means that you would create a public/private key pair for each
client and have something like authorized_keys on the server, similar to
SSH or ZeBeDee. You distribute private keys to clients and keep the
public keys on the server. Upon connection, the server generates a
symmetrical key (that uses some quick algorithm) which will be used for
further communication. The server encrypts this key using client's
public key and sends it. Since the client is the only party being able
to decrypt that message, it prevents from man-in-the-middle attach.
> Guys, this is not plugin stuff.Agreed.
--
Milan Babuskov
==================================
The easiest way to import XML, CSV
and textual files into Firebird:
http://www.guacosoft.com/xmlwizard
==================================