References: 
 <CAHnVB4C9tSJkD4Ysd645HJmJjWzNYKJgUumE74YY8FRjUFJE4g@mail.gmail.com>
 <30655.1536069964@sss.pgh.pa.us> <20180905174832.GO4184@tamriel.snowman.net>
 <87va7j61g2.fsf@gmail.com>
 <CAFwQ8rerOUEptWfbtrVusBTMqsEcTqDbnN6Q+O+o-49mmTUPqw@mail.gmail.com>
User-agent: mu4e 0.9.18; emacs 26.1
From: Tim Cross <theophilusx@gmail.com>
To: Craig James <cjames@emolecules.com>
Cc: Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>,
 Praneel Devisetty <devisettypraneel@gmail.com>, pgsql-admin@postgresql.org
Subject: Re: User to get locked after three wrong login attempts.
In-reply-to: 
 <CAFwQ8rerOUEptWfbtrVusBTMqsEcTqDbnN6Q+O+o-49mmTUPqw@mail.gmail.com>
Date: Thu, 06 Sep 2018 08:28:38 +1000
Message-ID: <87r2i760kp.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk


Craig James <cjames@emolecules.com> writes:

> On Wed, Sep 5, 2018 at 3:09 PM, Tim Cross <theophilusx@gmail.com> wrote:
>
>>
>> Stephen Frost <sfrost@snowman.net> writes:
>>
>> > Greetings,
>> >
>> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> >> Praneel Devisetty <devisettypraneel@gmail.com> writes:
>> >> > We have a requirement , where we require a user to get locked after
>> three
>> >> > wrong login attempts.
>> >>
>> >> The usual recommendation is to configure Postgres to use PAM
>> >> authentication; then you can set up any weird requirements like
>> >> this one in the PAM configuration.
>> >
>> > Unfortunately, it's a pain to set up PAM and there's a lot of things in
>> > the PAM stack which can't be used because PostgreSQL doesn't run as
>> > root.  We should really have a better solution to this pretty commonly
>> > asked for capability; I'm hoping to find time soon to hack on that.
>> >
>> > Thanks!
>> >
>> > Stephen
>>
>> These days, I think the better solution is to have this functionality in
>> a central system. Putting aside that it is an 'outdated' auditor
>> requirement ...
>
>
> To elaborate, you should explain to the auditor that this introduces a huge
> denial-of-service vulnerability into your system. Anyone can start
> hammering on everyone else's accounts, and with a fairly trivial script,
> lock the entire company out of all accounts. This is a terrible idea.
>

Unfortunately, that is a reflection of the poor standard of most
auditors. They are rarely technical people and just follow a rule
book. Most of their rules are outdated and many are wrong. For example,
many still require 'complex' passwords consisting of mixed case,
punctuation/special characters etc. This is despite the fact the person
who originally proposed such a scheme has actually come out and
apologised and said he had it wrong (plus this 'standard' was removed
from NIST standards over 2 years ago) and ignores the changes in
technologies which has changed the threat (i.e. rainbow tables etc now
mean length is far more important than complexity).  

The 'trick' with auditors is to only answer what they ask and answer in
such a way that what you say is true, but perhaps open to favourable
interpretation. e.g.

Auditor: do your accounts get locked after X failed login attempts
Answer: We use Active directory for our Windows domain, which has the
failed login policy enabled.
Auditor: Ah yes, I know about that - good, I will mark you as
compliant.

rather than

Answer: Well sort of. We have AD for our windows accounts which has the
failed login policy enabled, but some of our systems, like Postgres,
don't use that service.
Auditor: So do you get locked if you try to login to postgres and fail X
times
Answer: No
Auditor: Oh dear, I will have to mark you as non-compliant.


-- 
Tim Cross