To prevent brute-force attacks on a significant proportion of the password space, many computer systems limit login attempts on a per account or per host basis.  Traditional password protection systems permit three unsuccessful attempts before locking out the user from their account, either for a set period of time or until a system administrator resets the account.
This approach disincentivises users from choosing strong passwords that might be forgotten or mistyped, because approaching the Information Technology department to ask for a new password can be inconvenient or even embarassing.  Worse still, a naive and rigid implementation of such policies can make it much easier for an attacker to deny service by deliberately bombarding a server with spurious login attempts for known users, prompting the system to lock those users out of their accounts (see Section 2.5.1 in the 2^nd Edition of Professor Ross Anderson's text, “Security Engineering”).

A potential solution:

• Maintain a counter of consecutively failed login attempts,  n
• Implement a delay  L_n  in user-interface activity, after each and every attempt to log in.  (Using the low-resolution Real-Time Clock in this way might also help to frustrate high-resolution timing attacks.)  This delay might increase exponentially in  n:
  L_n = p × aⁿ
  • p is a proportional constant period of time in milliseconds, e.g.
    10ms ≤ p ≤ 500ms  (recommended value: p=25ms)
  • a controls the rate of increase in failed login timeout delay.
    1.4 ≤ a ≤ 2.5  (recommended value: a=1.75)
  • Values and limits for  a, p  may vary according to administrative discretion and according to the degree to which the server trusts the client's IP address & associated connection parameters (Bayesian learning might be applied to successively refine trust levels for different subtrees within a predefined hierarchy of possible client locations or client IP addresses).

This technique reduces the chances of legitimate users being locked out of their accounts by repeatedly mistyping their password, and reduces the inconvenience they are likely to face if they do so.  This improves system security by removing disincentives for the use of stronger passwords and by making it more difficult for an attacker to deny system service (which is sometimes done as a preliminary attack to force a system's administrators to drop layers of defence for the sake of their users' convenience).  The formula presented above has been tested informally by the author and found to work for the purposes described.
One drawback of this exponential method is that it increases the number of login attempts an attacker might be able to make before being effectively locked out of the system (especially where the attacker can muster login attempts appearing to originate from a broad range of potentially legitimate IP addresses).  This drawback might be mitigated by combining this method with other relevant techniques; such as:

• increasing the values of  a, p  and including additional factors in the formula so that login timeout delay  L_n  decays slowly with time elapsed since the most recent relevant unsuccessful login attempt
• Breaking n down into several appropriately weighted components:
  • Number of consecutive unsuccessful login attempts from a particular host
  • Numbers of consecutive unsuccessful login attempts from relevant subtrees within the predefined IP address hierarchy
• rejecting invalid system usage scenarios; e.g. by ensuring that a single user's credentials are not used in two geographically distant locations at the same time (to prevent a covert data channel where an outside attacker can discover by attempting to log in whether a particular user is already logged in at another location; you should implement the same exponentially increasing login timeout delays and failure messages regardless of the actual reason why a login attempt was rejected.)

With these improvements, the only remaining anticipated drawback is the additional processing power required to calculate timeout delays, and therefore to handle login attempts.  The increase in processing requirements might be minimised by indexing your database appropriately, and by structuring your IP address hierarchy according to the structure of IP addresses or otherwise by translating client IP addresses into a topologically relevant numerical format on INSERTion into your database.  Further mitigation of this increase in processing requirements, as well as other security advantages, might be obtained by putting the authentication database & functions onto a separate server.  Can anyone foresee any other potential problems in this plan, or suggest/ demonstrate other ways of improving the design?