As a youngster I remember going out to dinner with my family one night, where they had an all-you-can-eat special. Naturally I decided to do my part to see that I ate my fair share but by the third reorder, we were getting increasingly frustrated with the long waits and smaller portions. My dad explained it: "You see, that's what they do so you won't eat as much. They keep taking longer and longer to come out with the food, and they give you' less of it." I don't know how true that was, but after a while it certainly was not worth waiting around forty minutes just to shovel down another plateful of food.
The techniques used to thwart brute force at-tacks work on the same principle as that all-you-can-eat restaurant. As mentioned earlier, if one is persistent enough then it is really only a matter of time before a legal
username/password is hacked by guesswork or by chance. Therefore, the way to prevent such an attack from succeeding is to struc-ture the system prompts to frustrate the hacker into quitting early.
The most common defense is allowing only a few login attempts before disconnecting. The computer may then refuse to allow a reconnection within a certain period of time. The drawback to this is that a legitimate user might be inconvenienced - though having to wait a few minutes is much less of an inconvenience than logging on to find one's files have been tampered with by some cracker.
Another method is to increasingly slow the re-sponse time to each successive login attempt. A prospective hacker might find himself waiting thirty seconds for a response from the remote com-puter... Then a minute... Then two minutes... The long waiting periods wouldn't start until the first three or four login attempts were
tried and found unsuccessful. Then the computer would say to it-self, "Gosh, no real user would spell his name wrong that many times. Must be a hacker!" Another trick is the dummy login prompt. After a certain number of unsuccessful login attempts the system continues asking for login information, but returns an error message no- matter what the input is.
The moral of this story is, if you write a pass-word-cracking program, be sure you monitor its progress. Don't just set it to run overnight and leave it unless you've first determined that such security measures are not in place. When you wake up the next morning you may find it's been taking forty minutes for the computer to
respond to your inputs. Or you may find that every possible combi-nation has been tried to no avail, and so you know that you've been wasting time responding to dummy login prompts.
