On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost <sfr...@snowman.net> wrote: >> * Jan Urbański (wulc...@wulczer.org) wrote: >>> On 04/11/10 14:09, Robert Haas wrote: >>> > Hmm, I wonder how useful this is given that restriction. >>> >>> As KaiGai mentined, it's more to make bruteforcing difficult (read: tmie >>> consuming), right? >> >> Which it would still do, since the attacker would be bumping up against >> max_connections. max_connections would be a DOS point, but that's no >> different from today. Other things could be put in place to address >> that (max # of connections from a given IP or range could be implemented >> using iptables, as an example). >> >> 5 second delay w/ max connections at 100 would mean max of 20 attempts >> per second, no? That's alot fewer than 100*(however many attempts can >> be done in a second). Doing a stupid while true; psql -d blah; done >> managed to get 50 successful ident auths+no-db-found errors done in a >> second on one box here. 5000 >> 20, and I wasn't even trying. > > OK. I was just asking. I don't object to it if people think it's > useful, especially if they are looking at it as "I would actually use > this on my system" rather than "I can imagine a hypothetical person > using this".
I haven't heard anyone say "yes, I would actually use this on my system"? Any takers? If we're to commit this, then the patch needs to add a new file authdelay.smgl, fill it in with appropriate contents, and update contrib.sgml and filelist.sgml accordingly. I also note that the patch offers the ability to log superuser logins. Since that seems a bit off-topic for a contrib module called auth_delay, and since we already have a GUC called log_connections, I'm inclined to propose removing that part. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers