Re: User to get locked after three wrong login attempts.

On 06/09/2018 01:28, Tim Cross wrote:
> 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.
 From what I have gathered they try to protect the system from the admins rather than the users.
> 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.
^^^ exactly.
We have freeipa in place (via ldap in pg_hba.conf) and it does what they (auditors) ask + more.
Things get even more complicated when requirements come from different authorities e.g.
SOX + GDPR, the first asks for logs to be kept at least X years, the second gives the option for a person to delete his
recordsor the records that contain info about him/her older than Y years. As a 
 
result, the company spends considerable resources going around in circles.
>
>
>

-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt