On 11/14/2010 3:14 PM, Brad Pepers wrote:

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

That is pretty much the province of certificates. Slightly
oversimplified, a certificate is an electronic document signed by
somebody you trust (as in trust, but verify) that the server is what it
claims to be. I'm not aware of anything else that works. If you know
of anything less cumbersome, I'd like to hear about it.

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

On the plus side, it verifies that both client and server are in
possession of the password without revealing the password. That's nice,
and it makes it difficult to operate a counterfeit server to collect
passwords. On the minus side, it takes a lot of round trips to do it.

The MySQL password algorithm also allows a client password to be
verified on the server without exposing the passwords, but does nothing
to establish the bona fides of the server to the client.

To my taste, I wouldn't want to pay the latency for the additional round
trips, but other people may reasonably differ.

> --
> Brad
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>