When pressed... Delay, delay, delay

So most of us developers have pride in coding an application that gets a user his answer as fast as possible. I would like you to consider slowing things down a bit. I'm not simply talking about tweaking users to make them mad, I'm talking about adding real delay when you know you are being attacked.

For most web applications this is easy to do. After you detect the attack just do this.

//lets pause for a bit.  this will force a scripted attack to take much longer.
   // remember in extreme cases a regular user can get this so we don't want to    
   // make it take too long. 
   try 
   {
      Thread.sleep(genRandomTimeMS(10000, 20000));  
   } catch (InterruptedException e) {
      e.printStackTrace();
   } 

Another application of this technique is when an attacker is trying to brute force a password.  Modern GPU cracking algorithms can try ~4 billion per second.  However, if you add some delay (just 1 second) to the password checking algorithm then the 4 billion attempts take ...  126 years.  The extra second for the user to log in is fairly imperceptible.   Now I realize this is a special instance.  Most web applications will lock the user out after 3 - 5 wrong attempts.  It's really not applicable here, or is it?  If an attacker has your list of user names, they can DDoS your entire list of users quite easily and quickly.  What if we take this limit off? In it's place we place a 1-2 second delay.   The impact to my valid users is trivial.  The attacker will never have enough time to brute force a password, my user accounts cannot be DDoSed, and the number of support calls is reduced because users do not lock themselves out as quickly.   I understand the nature of parallelization will gnaw at this technique.  Any attacker with a botnet or cloud resources can pound my site, but instead of getting the answer almost immediately,  I now have a measure of time for my app security to lock out the IPs trying to brute force me.

Now lets consider my wrapped keystore algorithm from previous post(s). A keystore is quite a portable thing.  Most attackers will scoop up this gem and "take it back to my workshop" (sorry could not resist the Grinch reference).  Once in then the attacker would be free to parallelize his hardware and software and eventually gain access to the keys.   My supposition in creating the keystore with wrapped keys was that the attacker could fairly trivially brute force the keystore's PBE once he had it in his own environs.  But what if we throw some delay in the decryption for the wrapped keys algorithm, or better yet, get java to add it to the PBE?   A extra second or two won't hurt my users... 

I absolutely understand that my code can be reversed, and the code for delay taken out.  But what if the actual decryption algorithm could be altered to have real delay induced?  Some sort of actual work that takes 1-2 seconds of time to resolve when the password hash is created?  I believe bcrypt already does something like this. Then this delay would be intrinsic to the algorithm.

Wow.  Mick and the Stones were right, time really is on my side.