On 11/15/2010 10:44 AM, Alex Peshkoff wrote:

>
>> As for NimbusDB, I think I'm happy with the client sending a session key
>> encrypted with the hash of the password. No additional round trips, no
>> expensive RSA encryption, decryption, no man in the middle issue, though
>> I'm still pondering the issue.
> Unfortunately this method has one limitation. You suppose that client
> sends to the server login (to make server know the hash of password) and
> knows password, entered by client. But firebird does not require only
> login/password authentication, it already has windows trusted
> authentication, where only security context from client is sent to
> server and CURRENT_USER name becomes known at server site from OS. With
> this schema (rather reliable, BTW, from security POV) client does not
> have something to crypt session key.
>

From the beginning of time, Interbase tried to mimic the host
platform's policies to the degree possible. Windows didn't exist at the
time, but we used /etc/passwd for user authentication (which is why
Firebird happens to have its own version of "crypt") and hosts.equiv.
This was -- and is -- still good policy. So I understand and agree that
exploiting Windows services when server and client are both Microsoft
platforms is appropriate.

That said, nobody in their right mind is going to run NimbusDB
production on Microsoft, even though we do fully support this. But even
a NimbusDB server on a Microsoft server has to co-exist with Linux
servers, so happily, I don't even have to make even a good faith effort
to layer on Microsoft services. Whew!


--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376