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

Reply via email to