DISQUS

Nate Lawson · 10 months ago

Exponential backoff -- you don't really want that unless you want to wait 4 billion seconds after 32 bad tries. It would be the same as a lockout. So let's assume you cap it at some amount that still allows valid users to log in while their account is under attack (15 seconds?)

You definitely have to do the same thing for both valid and invalid attempts, otherwise it creates a side channel as Dave mentions in a comment above.

I think the Unix /bin/login program solved all of these a long time ago. That is, unless you have a wtmp smasher! Elite!

Dave G. · 10 months ago

yah, exponential is definitely not what you want. Did a quick look at what I think was opensolaris login.c. It looks like it defaults to 4 second delays per failed login, and after 5 tries it will sleep an additional 20 seconds.

Great. Now I need a fancy avatar. Thanks for making me get all web 1.5.

anonymous · 10 months ago

Just in response to the "Failed Login Delays" option, would this still be valid if an attacker were to exploit the fact failed logins take longer in response versus successful logins? Or is what you're saying that even upon successful login, it takes the delay to authenticate but will then reset the counter..

Tolaris · 10 months ago

I suppose a delay in authentication for that user would leak the fact that the user exists. So you'd have to track every invalid username and delay on it as well.

Even with that info leak, this seems a very good way to deal with distributed brute-forcing, because it is no longer concerned with source IP.

Thanks for this idea, Dave. Do you know if such a thing has been implemented for PAM? That way individual daemons need not be modified.

anonymous · 10 months ago

My original concern was really about the effectiveness of such a delay, if a valid username/password combination is used and permitted instant login. As such you can assume that any previous combination with a response time greater then x is failed (bypassing the exponential login delay).

But my question was aimed at, if a valid username/password combination is used, are they still subject to a delay before authentication. I suppose the obvious answer is yes, but I was just wondering if this was the original proposal.

Tolaris · 10 months ago

I would expect that a valid user/pass would be authenticated immediately. There is no benefit to delaying at that point; if the user/pass has been cracked, delaying a short period before letting the attacker in doesn't help. But suppose that the real user is trying to login, in the middle of a brute-force attack? He should be authorised immediately. And the delay counter reset.

Dave G. · 10 months ago

Ideally, you would maintain the delay on successful login. If you were really a go-getter, you could make the login delay for a successful one not quite as long, but long enough to fool brute forcing attempts. Even if you keep the delay consistent, you can consider the login a success, remove the delay and when the gets frustrated and tries to login again, they succeed.

I am sure it's not perfect, but I like it better than a lot of the alternatives.

Dave G. · 10 months ago

To clarify why anonymous is talking about keep or don't keep the delay on successful login: Delays are noticeable. If you see you are being delayed, you know you don't have the right password and you stop authenticating and re-try. Combine that with parallelization of your brute force attacks and an attacker can still be pretty effective.

As always, depends on how much security you want versus how much you want to annoy your users.

anonymous · 10 months ago

that's spot on.

I've just been thinking about it more, perhaps the correct solution is to use random login delays (with a lower and upper limit in timeout) for both valid and failed attempts, and as such like one of the other commenters had mentioned a 1 or 2 second delay can slow down a paralellized brute force attack quite effectively.

grey · 10 months ago

Oldest methods are still some of the most reliable. ;) Landreth's Out of the Inner Circle is mostly a documentation of password guessing strategies, shunning notions of bruteforcing as something a true hacker wouldn't do. Good to know that 24 years after even that was published, old techniques are still effective. ;)

rafael · 10 months ago

admin/admin test/test demo/demo guest/guest
still our friend...
:D

DG · 10 months ago

I would say that it's not the method that is obsolete, it is the old login / password authentication that is.
Are we still there...? Login / Password...? And I thought I was in a Hollywood screen set!! dang!
//DG

send9 · 10 months ago

I couldn't agree more; even trying "admin/admin" many times leads to a finding. And there's no excuse not to, since there are numerous default password databases as well as product manual for the more obscure ones. And once you memorize some common defaults, it's second nature to try them. I can't remember how many times every UPS device at a client has had the "apc"/"apc" logon, and of course, once you have UPS access, you could create a network DoS pretty quickly ;)

Michael Coates · 10 months ago

I totally agree with the login delay. That's something I rarely see in applications. Even adding a one or two second delay, which is barely noticeable to a user, has tremendous impact in slowing down an automated attack.