Note that there are some explanatory texts on larger screens.

plurals
  1. POWhat is the best Distributed Brute Force countermeasure?
    text
    copied!<p>First, a little background: It is no secret that I am implementing an auth+auth system for CodeIgniter, and so far I'm winning (so to speak). But I've run into a pretty non-trivial challenge (one that most auth libraries miss entirely, but I insist on handling it properly): how to deal intelligently with <strong>large-scale, distributed, variable-username brute-force attacks</strong>.</p> <p>I know all the usual tricks:</p> <ol> <li><strong>Limiting # of failed attempts per IP/host</strong> and denying the offenders access (e.g. Fail2Ban) - which no longer works <a href="http://www.christopher-kunz.de/archives/205-Distributed-and-coordinated-SSH-bruteforce-attacks.html" rel="noreferrer">since botnets have grown smarter</a></li> <li>Combining the above with a <strong>blacklist of known 'bad' IPs/hosts</strong> (e.g. DenyHosts) - which relies on botnets falling for #1, <a href="http://www.christopher-kunz.de/archives/205-Distributed-and-coordinated-SSH-bruteforce-attacks.html" rel="noreferrer">which they increasingly don't</a></li> <li><strong>IP/host whitelists</strong> combined with traditional auth (sadly useless with dynamic IP users and the high churn on most web sites)</li> <li>Setting a <strong>sitewide limit</strong> on # of failed attempts within a N minute/hour period, and throttling (suspending) all login attempts after that for a number of minutes/hours (with the problem that DoS attacking you becomes botnet child's play)</li> <li>Mandatory <strong>digital signatures</strong> (public-key certificates) or RSA hardware tokens for all users with NO login/password option (without question a rock-solid solution, but only practical for closed, dedicated services)</li> <li>Enforced <strong>ultra-strong password schemes</strong> (e.g. >25 nonsense characters with symbols - again, too impractical for casual users)</li> <li>And finally, <strong>CAPTCHAs</strong> (which could work in most cases, but are annoying for users and <a href="http://caca.zoy.org/wiki/PWNtcha" rel="noreferrer">virtually useless</a> against a <a href="http://www.slideshare.net/valicac/captcha" rel="noreferrer">determined, resourceful attacker</a>)</li> </ol> <p>Now, these are just the theoretically workable ideas. There are <em>plenty</em> of rubbish ideas that blow the site wide open (e.g. to trivial DoS attacks). What I want is something better. And by better, I mean:</p> <ul> <li><p>It has to be secure(+) against DoS and brute-force attacks, and not introduce any new vulnerabilities that might allow a slightly sneakier bot to continue operating under the radar</p></li> <li><p>It has to be automated. If it requires a human operator to verify each login or monitor suspicious activity, it's not going to work in a real-world scenario</p></li> <li><p>It has to be feasible for mainstream web use (ie. high churn, high volume, and open registration that can be performed by non-programmers)</p></li> <li><p>It can't impede the user experience to the point where casual users will get annoyed or frustrated (and potentially abandon the site)</p></li> <li><p>It can't involve kittens, unless they are <em>really really secure</em> kittens</p></li> </ul> <p>(+) <em>By 'secure', I mean at least as secure as a paranoid user's ability to keep his password secret</em></p> <p>So - let's hear it! <em>How would you do it</em>? Do you know of a best-practice that I haven't mentioned (oh please say you do)? I admit I do have an idea of my own (combining ideas from 3 and 4), but I'll let the true experts speak before embarrassing myself ;-)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload