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

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

I suggest that folks stop whining about cryptographic weaknesses of
AES-256 and instead ponder the problems of transmitting lightly
obfuscated passwords (with a published obfuscation algorithm, no less)
in the clear.




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



[Non-text portions of this message have been removed]