On 11/18/2010 10:04 AM, Alex Peshkoff wrote:

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

A NimbusDB connection is a two step process. The client initially
connects to a connection broker (which can server many databases) with
the database name and maybe other information. The connection broker
picks a transaction node then sends the ip, port, and database uuid to
the client. The client then has the information needed to encrypt the
random session key.

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

It means that the stored hash of { account, uuid, password } will be
different for different accounts on the same database and the same
account and password on different databases. This may make dictionary
attacks more expensive (I'm not sure that it's relevant if the server
notices that it is under attack), but I really hate storing passwords in
clear, even if, in theory at least, they are inaccessible.

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

Good point, but it doesn't help against a distributed dictionary attack.

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