User: Password:
Subscribe / Log in / New account

Blocking brute forcing

Blocking brute forcing

Posted Jun 24, 2011 11:07 UTC (Fri) by copsewood (subscriber, #199)
Parent article: A hole in crypt_blowfish

Yes I know it makes login code much more complex and stateful, but it's probably a bad idea to allow anything with an Internet login more than a certain number of attempts. On a webapp I'm developing I lockout the IP4 or IP6 address sooner than the account based on number of bad attempts. It will still allow a DOS attack by someone with more than enough IP6 addresses to burn through by hitting the per account bad login limit for enough guessable account names. I think the next significant iteration of this code will probably need more entropy included as or with the account name.

In the end I have to strike a balance, between a system which is possible for my users (some of them retired and very recent computer users) to learn and use, and one which is secure under all circumstances. I don't think I can achieve both. Another improvement is not allowing users to choose their own passwords. If they want to change their password generate a new random one for them.

(Log in to post comments)

Blocking brute forcing

Posted Jun 24, 2011 14:37 UTC (Fri) by solardiz (subscriber, #35993) [Link]

I briefly touch this topic here: (focusing on web apps, but relevant in other contexts as well). In my opinion, the per-source-address limits should NOT apply per-account, but rather should apply to authentication attempts globally - e.g., the way I implemented them in popa3d may be more effective. And decent password policies are generally more effective than source address or target account lockout.

Blocking brute forcing

Posted Jun 27, 2011 15:50 UTC (Mon) by nye (guest, #51576) [Link]

>In my opinion, the per-source-address limits should NOT apply per-account, but rather should apply to authentication attempts globally

I think the opposite of this. Source limiting is like saying "you drove here via the A32? The last guy who did that was a thief so you're barred".

A lot of people share an IP address, especially on mobile connections or large institutions (nice way to lock out 1000 students at once, or everyone in an office because a few people took 3 attempts to remember which of their 2 or 3 passwords they used for your service), and this problem is only going to get worse - likely rapidly worse - as the address crunch squeezes in.

Blocking brute forcing

Posted Jun 27, 2011 21:13 UTC (Mon) by solardiz (subscriber, #35993) [Link]

I guess I shouldn't have commented on this topic in here, which is only indirectly related to the article's topic. Anyway, here's a bit more detail: the approach that popa3d uses, and which I like so far (compared to possible alternatives), is based purely on connection rate per source address. In fact, its primary purpose was/is to improve availability of the service when under connection flood (whether intentional or not) from one or from a handful of source addresses. It is also reducing password probing as a nice side-effect. Default settings are: 500 sessions max, 50 per-source max (yes, NAT is considered here), a session is considered active for no less than 10 seconds after its startup. This allows for up to 5 new connections (and thus authentication attempts) per second per source IP address on average (but it also allows for spikes for up to 50 when not under flood from the address). Indeed, these settings may need to be tuned on larger/smaller servers.

Blocking brute forcing

Posted Jun 29, 2011 16:07 UTC (Wed) by nye (guest, #51576) [Link]

Ah, right. So the point here is that if you didn't block some users, *all* users could be affected, so even if you get some collateral damage it's still better than not doing it. That's somewhat tangential to blocking for the purpose of preventing dictionary attacks (as you say) and does make more sense.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds