On my webserver, you get 3 chances and then a 24 hour ip ban. I think that comes out to 0.00003 passwords per second :)

The particularly persistent IPs get a special iptables rule.

I suppose it's a bit different from a user facing login, but does anyone know why these limits tend to be set so low? I've locked myself out of plenty of things, and so have plenty of people I know. It seems like setting the limit to 20 would be just as effective in blocking brute force attacks without being user unfriendly.

Is it that with user facing services the common user/passwords are so common it's reasonable to just try just the top x most common passwords?

Intuition, most of the time. Here are some quite common ones:

http://www.splashdata.com/press/PR121023.htm

There's no reason why you would have a three attempts limit, or five, or ten, and so on. If I get three per account, I'll just use the top three and try again different accounts. If I get three attempts per IP, I'll use many different IPs and do the same.

To remain user friendly, delays are the way to go. E.g. you could have three different delays that add to each other: Account-level, IP-level and global. Increase each with every failed attempt up to 30 seconds of wait time, and add them together. This will slow down brute force attempts to the point where they're useless, while still allowing legitimate users to login (just with a little inconvenience).

As a result, if I failed three attempts with one account, and three one next, etc., my IP-level limit will prohibit me from moving on to other accounts. If I try a lot of passwords on one account, the account-level and IP-level ones will slow me down. And if there's a distributed attack with many IPs, the global delay will reduce the damage the attack can do. All the while legitimate users can still use the service.

So far it hasn't been a problem (fingers crossed). I have a couple ways into the server in case I get myself banned. Also, it's my personal server, so the only user that would complain is me :)

For other sites, I'm honestly not sure how they go about choosing a limit. 20 does seem to be more reasonable, while still being perfectly safe.

I remember using the nice fingerprint reader upon my old IBM laptop once, worked well until you changed your password and then if you had not updated the one in finger print encypted libary you got some impressive automation. Usualy it would automate yoru password once you scanned your finger. Now with the power of a computer you could scan your finger once and watch as the wonderful system tried the wrong password as fast as it could repeat upon itself. Was fun restoring my blackberry from backup after the 10 failed attempts in nanoseconds.

I like your approach though though I would redirect them to a appeal process that a human could read, but I'm not aware of the volumes you have to deal with. I would though wonder how this system will adapt come IPV6 times and with that if your not using it then I hope it is disabled as if your ISP/provider suddenly starts processing it or running tests then that latent IPV6 stack doing nothing could suddenly come to life and you probably don't have many firewall or IPtable rules for that in place. But that is a problem many will face over the years comming.

That's why an attacker will try three common passwords against every possible login name.

I doubt the IP ban is per account. Mine is a 5 failure within 1 hour rule, and if you get more than 4 of those ever you're perm-banned.

Could you share the details of the implementation please?

Not much implementation actually. Fail2ban does all the hard work, and then if I get too many emails reporting the same IP I go in and manually permaban the offending IP (doesn't happen often).

These hash functions are made to be fast to hash :P Check out the NIST competition, they picked the fastest hash that can be calculated with special hardware :) People who want real offline password security should use slow hash functions (and passphrases of course).

it's my understanding that NTLM hashes are sent over the wire...? therefore any machine on the local network could intercept this hash via network-level attacks such as ARP poisoning, WiFi attacks, etc. Then the cracking box would quite happily and easily brute force the entire 8 char keyspace and reveal the pass.

it's a different threat model to hash+email retrieval via sql injection which can lead to all sorts of nastiness involving hijacking email and then other accts

If they are sent over the wire I hope there is some additional encryption such as SSL involved in the transmission!

Otherwise regardless of hash crackability, one would be able to do authentication bypass by simply sniffing hashes and replaying them.