On 11/11/10 20:50, Jim Starkey wrote:

> On 11/11/2010 10:08 AM, Alex Peshkoff wrote:
>> On 11/11/10 17:36, Jim Starkey wrote:
>>> How does the current Firebird implementation transmit passwords to the
>>> server from the client?
>> 2.5 has no changes compared with InterBase6.
>> The only new feature works only for windows - MS API is used for trusted
>> authentication.
> That was my understanding. If I remember correctly, it used the glib
> function "crypt" to both transmit and store the password. This is
> brain-dead since an intercept of the packet would reveal the encrypted
> password, which is every bit as good as the password itself. This is a
> classical case of obscurity (and not even much) rather than security.
>
> To avoid an potential embarrassment on the scale of the
> politically/correct fiasco, I suggest that though be given to a
> defensible security architecture sooner rather than latter. Line and
> file level encryption is one thing, but giving out passwords to anyone
> on the LAN with a board in promiscuous mode is really quite feeble.
>
> The scheme used by MySQL for password authentication works like this:
>
> 1. The server stores only the SHA-1 hash of user passwords.
> 2. On the initial connection, the server sends the client a session
> specific random byte string
> 3. The client first hashes a password with SHA-1, concatenates the
> service supplied random string to the result of the pasword hash,
> then hashes that with SHA-1. The resulting hash is then sent to
> the server.
> 4. To authenticate, the server concatenates the session specific
> random string to the stored SHA-1 hash of the password, hashes the
> result, and compares it to the client supplied hash.
>
> This is cheap, easy, and secure.

Definitely yes. This may become the default builtin schema for FB3. It
has one more big plus - client remains independent from external crypt
libraries. There is one technical issue with current SHA1 hash in
security database. To make hashes look different for same passwords it
contains random data, not available to client side, but this can be
solved by sending that data to client together with random byte string.

> A more general mechanism is:
>
> 1. The server generates an RSA key pair at server start up.
> 2. The server send the client the public key on initial connect
> 3. The client generates a session key, encrypts it with the server's
> public key, and sends the encrypted session key to the server
> 4. Either the password (or, better, the SHA-1 hash of password) are
> encryption or, alternatively, all subsequent communication are
> encrypted with the session key.
>
> If the you give the hashed/encrypted password a separate DPB item
> number, the protocol can be made backwards compatible.
>

This is even not a requirement for backward compatibility - both
passwords will never coexist in same DPB. Sending new-style encrypted
password to old servers makes no sense, sending old-style together with
new one breaks the core of idea under discussion. Server also knows very
well what form of password does it expect depending upon protocol number.

> The randomized session string and/or server public key can be passed by
> an extension to the initial connect protocol (some fine fellow made
> provision for this sort of thing 26 years ago -- use it).

Yes - this saves roundtrip.

The bad problem is to let or not to let old clients (with almost plain
password in DPB) connect to server. But looks like this problem can be
solved only for each particular installation - what is more important,
ability to use old clients or security.