> I'm going to describe the security architecture I'm using in NimbusDB as
> a starting point. The key element is that clients generate one-time
> session keys that are securely transmitted to server. Whether the key
> only encrypts authentication credentials, all communications, or the
> database file at page level can be discussed separately.
>
> Here is the architecture:
>
> 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
>
> At the moment, the algorithms supported are RC4, AES-128, and AES-256.
> I have not built in support for certificates, but as all initial
> connection messages are XML, adding them would be trivial. RSA is
> hardwired. The default RSA keysize is 1024 bits, but this is
> non-architectural and could be changed or made an option. I may switch
> over to the MySQL strategy of sending the SHA-1 hash of the SHA-1 hash
> of the password concatenated with a server supplied value.

I'm not a big crypto guy but isn't this subject to man in the middle attacks? Perhaps I'm wrong or perhaps it's not considered an important point but I think it a good idea to discuss what any architecture gives you as well as what it won't handle.

It may also be worth while to look at the Secure Remote Password protocol (SRP). Not sure if it completely applies to what Firebird needs but it has some pretty desirable properties.

--
Brad