2010/11/11 Jim Starkey <jstarkey@...>:

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

We do the same thing in Red Database, but with different crypto
algorithms. It's also known as CHAP protocol.

> This is cheap, easy, and secure.  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.

I think it's more better solution because it allows us to encrypt new
or changes user password. AFAIU when user changes password it is
sending as is to the server. Session key can be used to encrypt it.


--
Roman Simakov