Do we need a time delay after password failures?
Most programs that ask for a password will put in a delay if you get it wrong. They do this to stop password crackers from quickly trying lots of passwords. The delay makes brute force attacks impossible, in theory.
But what does it really do? There are two situations. In one situation, you have some state on the party entering the password, such as IP address, or a shell session, or terminal. So you can slow them down later. For example, you could let a user have 3 or 4 quick tries at a password with no delay, and then put in a very long delay on the 5th, even if they close off the login session and open another one. Put all the delay at the end of the 4 tries (or at the start of the next 4) rather than between each try. It's all the same to a cracking program.
Alternately, you have no way to identify them, in which case rather than sit through a delay, they can just open another session. But you can put a delay on that other session or any other attempt to log into that user. Once again you don't have to make things slow for the user who just made a typo. And of course, typos are common since most programs don't show you what you're typing. (This turns out to be very frustrating when logging in from a mobile device where the keyboards are highly unreliable and you can't see what you are typing!)
Comments
Tim Farley
Wed, 2007-10-17 05:26
Permalink
Can be source of security vulnerabilities too
If you're not careful how you implement the time delay, you can create a security vulnerability with this too.
There was an old version of Novell NetWare that would delay the reply packet if the request contained a bad password. However, it did NOT also do the same thing on bad username. As a result, you could brute-force a list of usernames for that server by simply watching for whether the delay occurred.
It's merely an information leak, but it could be an useful early step in an attack.
brad
Wed, 2007-10-17 12:44
Permalink
Yes, be careful
Yes, I don't say one should not be careful in design of these systems. I just rant about making a choice that frustrates the legitimate user as well as the attacker, when there could be choices to only frustrate the attacker.
Keeping usernames secret requires a tradeoff. Doing so can frustrate users, who may think they have got their password wrong (and keep retrying it until they get locked out) when actually they have their userid wrong. On the other hand, attackers may have various easy methods available to test usernames independently on many of today's sites, in which case hiding them helps nothing. (Many sites will let you enter usernames to get the password emailed without also asking for the email, for example, or put usernames in public web pages and URLs. In addition, it is very, very common for users to keep the same username over many systems.)
Charles Merriam
Thu, 2007-10-18 23:24
Permalink
My credit union has a simple
My credit union has a simple password. After three tries, you need to talk to the branch.
Sairy
Sat, 2007-10-20 01:44
Permalink
great Brad idea
I like this. It makes a lot of sense. And I think you're right on with the mobile point as well. I've run into that problem in the past especially when passwords have characters that aren't easy to find with mobile keyboard interfaces.
What irritates me (as a user) more than delays, FWIW, are the sites that assume your username is correct and default to telling you the password is wrong vs. noting that it could be either one. I've wasted much more time hammering on passwords when the username was incorrect than I have from typos in the passwords. (Not that the delays aren't a nuisance.)
Add new comment