On 11/17/10 22:42, Jim Starkey wrote:

> On 11/17/2010 5:34 AM, Milan Babuskov wrote:
>> Jim Starkey wrote:
>>> 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
>> Hi Jim,
>>
>> 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.
> You're right about the man in the middle vulnerability. Perhaps a more
> serious problem, however, is authentication of the server to the
> client. I've pretty much given up on this approach.
>
> I think my requirements are these:
>
> * Client is authenticated to the server
> * Server is authenticated to the client.
> * Immunity to man in the middle attacks
> * Resistance to dictionary attacks
> * No requirement for either server or client certificates
> * Database / account / password based authentication.
>
> My current thinking is this:
>
> 1. An authentication key is form by the SHA-1 of the concatenation of
> user name, database uuid, and password.
> 2. The client generates a random session key
> 3. The client encrypts the session key with AES and send it to the server

If I understand correctly - key used for this encryption is SHA-1 of the
concatenation of user name, database uuid, and password?

If yes - how does client know database UUID in advance? Or this is
something like replacement of database name in nimbus?

And last problem. If user name and db uuid must anyway travel to the
server over network, and algorithm of concatenation is probably known to
attacker - how does it make hash better? Or is it a method to avoid same
keys for same passwords?

> 4. The server decrypts the session key and uses it for subsequent
> communication (RC4 by default)
>
> The server will stop responding to an account after n successive
> failures for an account for progressively increasing time to thwart
> dictionary attacks.
>

Taking into an account IPs having too many failures is also useful.