Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance

From: Marko Kreen <markokr(at)gmail(dot)com>
To: David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, toruvinn <toruvinn(at)lain(dot)pl>, pgsql-bugs(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance
Date: 2009-07-15 15:31:25
Message-ID: e51f66da0907150831p1432de8cv378d33bf34633aec@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-performance
On 7/15/09, David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com> wrote:
> On Wed, Jul 15, 2009 at 11:10 AM, Marko Kreen<markokr(at)gmail(dot)com> wrote:
>  > From security standpoint, wasting more cycles on bad passwords is good,
>  > as it decreases the rate bruteforce password scanning can happen.
>  >
>  > And I cannot imagine a scenario where performance on invalid logins
>  > can be relevant..
>
>
> DoS attacks. The longer it takes to reject an invalid login, the fewer
>  invalid login attempts it takes to DoS the server.

No, this is not a good argument against it.  Especially if you consider
that DoS via hanging-connect or SSL is still there.

Compared to minor DoS, the password-leakage is much worse danger.

-- 
marko

In response to

pgsql-performance by date

Next:From: Scott MeadDate: 2009-07-15 15:33:03
Subject: Re: Performance comparison between Postgres and Greenplum
Previous:From: Tom LaneDate: 2009-07-15 15:30:26
Subject: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-07-15 15:33:02
Subject: Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty
Previous:From: Tom LaneDate: 2009-07-15 15:30:26
Subject: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group