The theoretical basis of computer security and mutual authentication is
the concept of shared secrets. The most common implementations use
passwords. In Firebird, there are at least two implementation of
password based authentication, SRP verifiers and irreversible hash
algorithms. Each can be made secure unless the collections of
<password, hash> pairs is compromised, in which case the hash can be
attacked with brute force, a dictionary attack, or a related key attack.
There are two approaches to hardening password hashes to defeat various
attacks. The more secure is use only large, randomly generated keys.
Unless there is a weakness in the hash mechanism, a 20 byte key will
require, on average, 2^119 probes to break a key, an inconceivable
task. The problem with long, randomly generated keys is that they are
unusable by human beings.
The less secure approach is to increase the cost a probe to make an
iterative attack infeasible. The pbkdef2-hmac-sha1 algorithm uses
iterative rounds of hashing, where each round requires two sha1 hashes.
The recommended number of iterations in 2000 was 1000. Now, a more
common number is 10,000 iterations. Unfortunately, however, increasing
the cost of a probe for an attacker also increases the cost of a
validation, leaving a server that implements such a hash wide open to
denial of service attacks. And where increasing the size of a password
by a byte has an exponential increase in the computational power
necessary for a successful attack, increasing the number of rounds in
pbkdf2 has only a linear effect.
So we have two techniques, one secure but unusable and one usable,
moderately secure, but with an unavoidable side effect of loading a
server with limited computing power with a vast amount of unnecessary
computation.
A potential workaround is to combine the two techniques with a client
side password vault, itself protected by a pbkdf2 type algorithm for a
human friendly password, containing long randomly generated connection
password. The computational cost of opening the vault is unavoidable
but is on the client side, sparing the server.
To use a password vault, one additional parameter would have to be added
to the connection request in the API, which is the filename of the
password vault (obviously, even this can be eliminated by a client
configuration file). As part of the connection request, the client
decrypts the vault using the given password, looks up the connection
long, randomly generated password given the account string, then uses
the long, randomly generated password for the actual database connection.
Any example of a password vault is:
<Vault cipher="aes128" hash="pbkdf2-hmac-sha1" salt="20a12845d9b84"
rounds="10">
15C/CZvPPDWDdYuoL8BJMRH/I.fLcqP5pHzONcOdwFXNjJ/62uEg18eXE5h/
VJixUH1P8kNmfe1dJHs6EEBcAn5WARGGxoy1kW9QC6J0s.PXTtMqRRzw7Kai
i1hT1WvvHjjv4DZN7CdGNCep55/TJE**
</Vault>
The base64 gook is an XML document containing, possibly among other
things, a list of accounts and associated passwords encrypted with
AES-128. The vault decryption key is derived with PBKDF2 (password
based key derivative function, version 2), HMAC (a message digest) using
SHA1. Obvious there is provide to change algorithms. In this case the
number of PBKDF2 iterations is 10, which is hopeless secure but good
enough for debugging.
Unless it can be guaranteed that SRP verifiers in Firebird are immune to
compromised (and daily headlines tell of the large number of government
agencies that incorrectly though likewise), it is close to folly to use
a robust authentication algorithm like SRP using human chosen passwords.
In the final analysis, hardening any computing systems requires that the
most vulnerable links be addressed first. In Firebird, that is the use
of human chosen passwords.
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel