Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sLjml-00GIfv-Qo for pgsql-general@arkaria.postgresql.org; Mon, 24 Jun 2024 13:31:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sLjmi-009YZE-SX for pgsql-general@arkaria.postgresql.org; Mon, 24 Jun 2024 13:31:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sLjmi-009YZ4-DG for pgsql-general@lists.postgresql.org; Mon, 24 Jun 2024 13:31:04 +0000 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sLjmb-002tRf-E8 for pgsql-general@lists.postgresql.org; Mon, 24 Jun 2024 13:31:03 +0000 Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-366edce6493so937260f8f.3 for ; Mon, 24 Jun 2024 06:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719235856; x=1719840656; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LsLpwdr0kop2czKpXmakR/4+xmhmHqw3wCqhu9T7tj8=; b=lAN2bfUb9pMxhgA2RG7rlGiwdwghA6T9ocu/f4XsRKwbDkVdojXtqpe2cho+7hcKPr iBUZowR9Jl7kOab+i7P8DYbAEe5sE+kHnaqj+y/VZcHzTboLDAc76VByEMoOKxcemvBd sqxm6ZOGHp6viIIvSPaD0Kdk0c4n2iT3dO2UtQiDwSDcdZ/ZsTZyNTdg4XrzQAR03K+B APNLHP3yjBvt/cBi5RBIK+w2yx+1Jqv0aLbDjXyLqbttapOVU8PLdshIbu1JAkJZ2/t0 SfwfZx6c+EvSAjpmCnLX46UR10S5vCV3mOmQjFmIbmdCaYwfR11cO6p+Un0SbN52maXS aM8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719235856; x=1719840656; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LsLpwdr0kop2czKpXmakR/4+xmhmHqw3wCqhu9T7tj8=; b=eQMccCtU39/P+UsilYWJ+2P6Pogm7CONCIGPIaSKnm/hP6NLujjlsBzz783+pADMzd YwmvtowsihbfeiY2PM9UmYlB0zRXLCCFDSceW7egtEeEVQCJsebMzOALxSjZVDKGvUmf Yhul4WYNfsD0AevzxNDk/a7GtEXX2QvyXJWAnFztBAB0TUcZOKhJyynYmM0Zm11JBNUg ZDvk40mM9ZHidmvM34krHatiPenWwFwlM4CJHaIx6YAFzf1meHJBPyJcoay5OZcfL3Qb 6A7HwTY4TpQoZArlLw60PZMh16vKAPZCK6yHvgdDcboz5Qw562wcKw5HV1iCQJeVI24Q TMPA== X-Gm-Message-State: AOJu0YxBpux4hwihf5fdb1mDKqmn8pf31N2jpHWW7eZoUaXYlJbUZf8H Z1JVmYtJISKbXYOwlVEuAc1x5H3PYp0czUiPyA87ja24CwGn+QsqKg642hbQb9qDEgB0A2l5Fcx b0/r5rCiT5W+p+6oa4RolxIxQlAw= X-Google-Smtp-Source: AGHT+IF/6nRX5O4FaRQ0nT4EdI2+7a6zlm2SLaZBfPGoVy9Jy6Uq9QmQAV92pUoi/qcPyX4cbj74EonZ0izwOBtlsaM= X-Received: by 2002:a05:6000:481e:b0:366:f994:33c with SMTP id ffacd0b85a97d-366f99403eamr1003543f8f.56.1719235855674; Mon, 24 Jun 2024 06:30:55 -0700 (PDT) MIME-Version: 1.0 References: <79692c1a-190c-413e-9442-a14a45c1069d@googlemail.com> <834558.1719102188@sss.pgh.pa.us> <43826fbd-2d26-467b-afcf-7fde609f8da3@googlemail.com> In-Reply-To: From: Chris Travers Date: Mon, 24 Jun 2024 20:30:44 +0700 Message-ID: Subject: Re: 2FA - - - was Re: Password complexity/history - credcheck? To: o1bigtenor Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000767d1b061ba2cab0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000767d1b061ba2cab0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 24, 2024 at 8:00=E2=80=AFPM o1bigtenor w= rote: > > > On Sun, Jun 23, 2024 at 10:10=E2=80=AFAM Greg Sabino Mullane > wrote: > >> On Sun, Jun 23, 2024 at 5:30=E2=80=AFAM Martin Goodson >> wrote: >> >>> I believe that our security team is getting most of this from our >>> auditors, who seem convinced that minimal complexity, password history >>> etc are the way to go despite the fact that, as you say, server-side >>> password checks can't really be implemented when the database receives = a >>> hash rather than a clear text password and password minimal complexity >>> etc is not perhaps considered the gold standard it once was. >>> >>> In fact, I think they see a hashed password as a disadvantage. >> >> >> Wow, full stop right there. This is a hill to die on. >> >> Push back and get some competent auditors. This should not be a DBAs >> problem. Your best bet is to use Kerberos, and throw the password >> requirements out of the database realm entirely. >> >> Also, the discussion should be about 2FA, not password history/complexit= y. >> >> > Hmmmmmmm - - - - 2FA - - - - what I've seen of it so far is that > authentication is most often done > using totally insecure tools (emailing some numbers or using SMS). Now if > you were espousing > the use of security dongles and such I would agree - - - - otherwise you > are promoting the veneering > of insecurity on insecurity with the hope that this helps. > > IMO having excellent passwords far trumps even 2FA - - - - 2FA is useful > when simple or quite > easily broken passwords are required. Now when you add the lack of SMS > possibilities (due to lack of signal) 2FA is an usually potent PITA becau= se > of course SMS 'always' works (except it doesn't(!!!!!!!!!!!!!!!!)). > > (Can you tell that I've been bitten in the posterior repeatedly with this > garbage?) > For 2FA, a simple solution is to require a password plus clientcert=3Dsameuser. This allows you to authorize devices/user accounts for specific remote database connections and provides that second factor -- i.e. something you have as well as something you know. > > > Regards > --=20 Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more --000000000000767d1b061ba2cab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 24, 2024 at 8:00=E2=80=AF= PM o1bigtenor <o1bigtenor@gmail.= com> wrote:


On Sun, Jun 23, 2024 at 10:10=E2= =80=AFAM Greg Sabino Mullane <htamfids@gmail.com> wrote:
On Sun, = Jun 23, 2024 at 5:30=E2=80=AFAM Martin Goodson <kaemaril@googlemail.com> wrote:=
I believe that our security team is getting most of this from o= ur
auditors, who seem convinced that minimal complexity, password history
etc are the way to go despite the fact that, as you say, server-side
password checks can't really be implemented when the database receives = a
hash rather than a clear text password and password minimal complexity
etc is not perhaps considered the gold standard it once was.

In fact, I think they see a hashed password as a disadvantage.
=

Wow, full stop right there. This is a hill to die on.

Push back and get some competent auditors. This sho= uld not be a DBAs problem. Your best bet is to use Kerberos, and throw the = password requirements out of the database realm entirely.

Also, the discussion should be about 2FA, not password history/comp= lexity.


Hmmmmmmm - - = - - 2FA - - - - what I've seen of it so far is that authentication is m= ost often done=C2=A0
using totally insecure tools (emailing some = numbers or using SMS). Now if you were espousing=C2=A0
the use of= security dongles and such I would agree - - - - otherwise you are promotin= g the veneering=C2=A0
of insecurity on insecurity with the hope t= hat this helps.=C2=A0

IMO having excellent passwor= ds far trumps even 2FA - - - - 2FA is useful when simple or quite=C2=A0
easily broken passwords are required.=C2=A0 Now when you add the lac= k of SMS possibilities (due to lack of signal) 2FA is an usually potent PIT= A because of course SMS 'always' works (except it doesn't(!!!!!= !!!!!!!!!!!)).=C2=A0

(Can you tell that I've b= een bitten in the posterior repeatedly with this garbage?)

For 2FA, a simple solution is to require = a password plus clientcert=3Dsameuser.=C2=A0 This allows you to authorize d= evices/user accounts for specific remote database connections and provides = that second factor -- i.e. something you have as well as something you know= .=C2=A0


Regards=


--
Best Wishes,
Chris Travers

Effi= cito: =C2=A0Hosted Accounting and ERP.=C2=A0 Robust and Flexible.=C2=A0 No = vendor lock-in.
--000000000000767d1b061ba2cab0--