Re: User to get locked after three wrong login attempts.
От | Achilleas Mantzios |
---|---|
Тема | Re: User to get locked after three wrong login attempts. |
Дата | |
Msg-id | 67946f0f-4c7b-ffdb-5177-5585bf583f21@matrix.gatewaynet.com обсуждение исходный текст |
Ответ на | Re: User to get locked after three wrong login attempts. (Tim Cross <theophilusx@gmail.com>) |
Список | pgsql-admin |
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
В списке pgsql-admin по дате отправления:
Предыдущее
От: amit tripathiДата:
Сообщение: recovery.conf not getting changed to recovery.done after PITR
Следующее
От: Andrey ZhidenkovДата:
Сообщение: Determine which query prevents applying WALs on standby