On 08/18/2015 12:22 AM, 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. >
Did you mean <login, hash> pair? If <password, hash> pair is known to attacker no more brute force, dictionary, etc attack is needed. > 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 What do you mean by 'immune to compromised' here? The main goal of using SRP as a default authentication method in FB3 was to avoid sending plain passwords over the wire. SRP verifiers are stored by default in separate security database not accessible remotely at all. The next step of verifiers protection is keeping them in SYSDBA-only readable table. But may be I understand 'compromised' wrong here? > (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. > Do you want to say that Stanford's paper is wrong? It begins with "The SRP protocol performs secure remote authentication of _short human-memorizable_ passwords". Probably all questions asked can be replaced with single - is the goal of suggestion keeping safe in a case when pairs <login, SRP verifier> become known to potential attacker? > 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. > In firebird3 - probably yes. In currently released versions sending that password over the wire in almost opened form seems to be much more serious vulnerability. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
