Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fxfzz-0004oe-8y for pgsql-admin@arkaria.postgresql.org; Wed, 05 Sep 2018 22:10:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fxfzx-0002Bn-1K for pgsql-admin@arkaria.postgresql.org; Wed, 05 Sep 2018 22:10:05 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fxfzw-0002Bf-KT for pgsql-admin@lists.postgresql.org; Wed, 05 Sep 2018 22:10:04 +0000 Received: from mail-pf1-x441.google.com ([2607:f8b0:4864:20::441]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fxfzt-0006yE-V1 for pgsql-admin@postgresql.org; Wed, 05 Sep 2018 22:10:03 +0000 Received: by mail-pf1-x441.google.com with SMTP id b11-v6so4178112pfo.3 for ; Wed, 05 Sep 2018 15:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=S++2hTOVqXPUjDqz3T2deGnGt4PYGKyi0wIcR2mrTQA=; b=J9+THsJaMx6p3mFlTGrexkXr6QyovSh+pLK62xJa6lUbEYkYh5yMfvSLNz5O2FpBSZ 4YUGvRczoIOmowq1xFfUMhxIuztBOuKSWdwfvGI9Q6w0Jon29adsQZMFt9TQsofbeni7 bKuzjjjkYb1PwsbPo8b53KTZlOFB9lGVVjLCe4FrNY5brrkSFRESTeT5zxpNmmlkbhzZ gFp4V0F6iEYQBWh+ZjvzDceRgqOdt9axFAFM2dS7rJQiXifoghSC84Z0n4eR/uAijyy0 Jfsdn+xIinYpFk3cp06/hckskuqXUeaB9KGTe4z6ZD3oronB7VYKoL2l06m/R15k4VDv J3tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=S++2hTOVqXPUjDqz3T2deGnGt4PYGKyi0wIcR2mrTQA=; b=CoyibvGu2qHtxsEgshkTRaA4zvfFWuWlef06bzbob3pR6jKA105Y5w//umDklvg+Tf aZzCL1kFiahdYuETFalNf/TTFLiKPQ0d83GIQnmMVQWYkgExHeJWC9Oe8TDqFHDM/YLL J55ymKCa0dyrh5DNN6TAJ8W2CI/OtIYX7qC/CS94vsjiL5SA7gH/jF/cF1qESMgWwDWp vdMGp8jsPbw6gf6DInW7smELarfCTgLTguxZ1ZMhlqf/RJCLACBpl3LlPeYbAsPEL2Rm DhvM4j96VJ+jhV42hbhmqArI9b5O9BeQGEb04xWDgl63dh5V/SYjwpJRX4igFXWq4eXq wEww== X-Gm-Message-State: APzg51CfldoM3g8jVhgJzX8rj+Lk1NLdWzsQAVWIBoybN/tVWHV3ILRy ESUkofDeiNLz/miRGyXzqq1nTIZ5 X-Google-Smtp-Source: ANB0VdagKxVhBYIg6RhahQY6+rXMtvvsMMNA5R72ai6YTJygXrBjgzcYuYqK6Z6Qupk4t4YHktuLeg== X-Received: by 2002:a62:6690:: with SMTP id s16-v6mr42893554pfj.152.1536185400776; Wed, 05 Sep 2018 15:10:00 -0700 (PDT) Received: from tim-desktop (2001-44b8-31f2-bb00-49e9-8aa7-a94a-d946.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:49e9:8aa7:a94a:d946]) by smtp.gmail.com with ESMTPSA id y85-v6sm5105153pfa.170.2018.09.05.15.09.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Sep 2018 15:10:00 -0700 (PDT) References: <30655.1536069964@sss.pgh.pa.us> <20180905174832.GO4184@tamriel.snowman.net> User-agent: mu4e 0.9.18; emacs 26.1 From: Tim Cross To: Stephen Frost Cc: Tom Lane , Praneel Devisetty , pgsql-admin@postgresql.org Subject: Re: User to get locked after three wrong login attempts. In-reply-to: <20180905174832.GO4184@tamriel.snowman.net> Date: Thu, 06 Sep 2018 08:09:49 +1000 Message-ID: <87va7j61g2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Stephen Frost writes: > Greetings, > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> Praneel Devisetty 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, what the auditor really wants to see is that access to ALL systems is locked after 3 failed authentication attempts (for a period e.g. 5 minutes). Having a centralised system also has the benefit of 'same login', so your users have the same username and password across all services in the organisation and 1 central and consistent place for password management. I would suggest looking at what can be achieved with oepnLDAP and/or Active Directory/Kerberos. Note that the tricky part with this approach in the era of multiple devices is getting the parameters tweaked correctly. It is not as easy as just saying 'after 3 failed logins, lock the account'. You need to consider what happens when someone changes their password and has multiple devices logged into different services (e.g. mail). As soon as the password has changed, some of these devices will begin to fail and this will happen before the user can open each device and change the password. If the policy is to restrictive, by the time they do this, their account is locked and they cannot change the password - now they are caught in a vicious cycle. Most lockout mechanisms have parameters you can set to avoid this issue. Tim -- Tim Cross