On 17-8-2015 23:22, Jim Starkey wrote: > 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.
Using a client-side password vault is an interesting idea, but it does not really have an impact on server-side security, except that it allows you to use more random keys, a similar effect can be achieved by using significantly longer passwords and a better hashing algorithm (one that generates more bits and generates a cryptographically stronger hash, for example SHA-384 or SHA-512), maybe combined with PBKDF2 (using it as a key-derivation algorithm) which allows you to generate even more bits. A client-side password vault should be just that, purely client-side and it should not reflect in any way in the protocol or handshake. I think it provides a false sense of security though, as you protect a big secret with a smaller secret, and as such you don't add any real protection over using the smaller secret 'directly' (through some kind of key derivation algorithm as above). Mark -- Mark Rotteveel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
