On 2010-11-14, at 2:06 PM, Jim Starkey wrote:

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

Well SRP is a way to get the security from MITM without needing certificates which is why I mentioned 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.

The original SRP was 3 round trips but you can trivially get it down to 2 so you are only paying for one more round trip to get mutual authentication. If you really want to save the latency, you can get it down to 1.5 round trips so you are only paying for one extra message but this only gives you one-way authentication of the client to the server. To me the added latency of one extra round trip isn't much of an issues when it's only needed at the start and it gives you mutual authentication and a secure session key.

Here is a good link on SRP including the round-trip optimization:

http://srp.stanford.edu/ndss.html

--
Brad