public inbox for [email protected]
help / color / mirror / Atom feedRe: Password complexity/history - credcheck?
9+ messages / 7 participants
[nested] [flat]
* Re: Password complexity/history - credcheck?
@ 2024-06-23 00:23 Tom Lane <[email protected]>
2024-06-23 09:30 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Tom Lane @ 2024-06-23 00:23 UTC (permalink / raw)
To: Martin Goodson <[email protected]>; +Cc: [email protected]
Martin Goodson <[email protected]> writes:
> Recently our security team have wanted to apply password complexity
> checks akin to Oracle's profile mechanism to PostgreSQL, checking that a
> password hasn't been used in x months etc, has minimum length, x special
> characters and x numeric characters, mixed case etc.
Don't suppose it would help to push back on whether your security
team knows what they're doing.
The really key reason why server-side password checks are not as
bright an idea as they sound is that they cannot be implemented
without forcing the client to transmit the password in cleartext.
It's widely considered best practice if the server *never* sees
the user's cleartext password, because then it can't leak, either
from sniffing the connection or scraping the postmaster log.
I believe that practices such as forcing a password change every
X amount of time are not viewed as favorably as they once were,
either. (The argument is that that discourages users from putting
any serious thought into choosing an uncrackable password, and
might well encourage them to write down their current and last few
passwords somewhere.)
Anyway, considerations like these are why there's not features
of this sort in community PG. You can use an extension that
applies some checks, but there's no good way around the "needs
cleartext password" problem for that.
regards, tom lane
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Password complexity/history - credcheck?
2024-06-23 00:23 Re: Password complexity/history - credcheck? Tom Lane <[email protected]>
@ 2024-06-23 09:30 ` Martin Goodson <[email protected]>
2024-06-23 10:49 ` Re: Password complexity/history - credcheck? Christoph Moench-Tegeder <[email protected]>
2024-06-23 15:09 ` Re: Password complexity/history - credcheck? Greg Sabino Mullane <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Martin Goodson @ 2024-06-23 09:30 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]
On 23/06/2024 01:23, Tom Lane wrote:
> Don't suppose it would help to push back on whether your security
> team knows what they're doing.
> ...
> Anyway, considerations like these are why there's not features
> of this sort in community PG. You can use an extension that
> applies some checks, but there's no good way around the "needs
> cleartext password" problem for that.
>
> regards, tom lane
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.
credcheck seems to satisfy their requirements - password complexity,
password history, etc but - and this is the crucial bit - only on
cleartext passwords.
If I'm forced to go to cleartext passwords, which would be a nightmare,
credcheck might be worth looking at, but I'm not sure whether or not it
is well adopted, reliable, and without significant issues. I only heard
about it a few days ago from a friend/colleague, so I was wondering if
anybody else was using it and what experiences with it might be.
Regards,
Martin.
--
Martin Goodson.
"Have you thought up some clever plan, Doctor?"
"Yes, Jamie, I believe I have."
"What're you going to do?"
"Bung a rock at it."
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Password complexity/history - credcheck?
2024-06-23 00:23 Re: Password complexity/history - credcheck? Tom Lane <[email protected]>
2024-06-23 09:30 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
@ 2024-06-23 10:49 ` Christoph Moench-Tegeder <[email protected]>
2024-06-23 13:14 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Christoph Moench-Tegeder @ 2024-06-23 10:49 UTC (permalink / raw)
To: Martin Goodson <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]
## Martin Goodson ([email protected]):
> 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.
The current state of the art is documented (as in, "official", for
arguing with auditors) at
https://pages.nist.gov/800-63-3/sp800-63b.html#sec5
My advice would be to not use secrets stored in the database -
that is, do not use scram-sha-256 - but use an external authentication
system, like Kerberos (might be AD) or LDAP (might also be AD) and have
that managed by the security team: that way all these compliance
topics which they brought up also become their problem :) and a lot
of the processes of recovering and disabling accounts and changing
passords move into a central location, which is most often a good thing[tm].
Or maybe move to client certificates, but if you're managing more
than a few personal accounts rotating certificates might become a
hassle (depending on your user base).
Regards,
Christoph
--
Spare Space
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Password complexity/history - credcheck?
2024-06-23 00:23 Re: Password complexity/history - credcheck? Tom Lane <[email protected]>
2024-06-23 09:30 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
2024-06-23 10:49 ` Re: Password complexity/history - credcheck? Christoph Moench-Tegeder <[email protected]>
@ 2024-06-23 13:14 ` Martin Goodson <[email protected]>
2024-06-24 08:20 ` Re: Password complexity/history - credcheck? Laurenz Albe <[email protected]>
2024-06-24 15:01 ` Re: Password complexity/history - credcheck? Christoph Moench-Tegeder <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Martin Goodson @ 2024-06-23 13:14 UTC (permalink / raw)
To: Christoph Moench-Tegeder <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]
On 23/06/2024 11:49, Christoph Moench-Tegeder wrote:
> My advice would be to not use secrets stored in the database -
> that is, do not use scram-sha-256 - but use an external authentication
> system, like Kerberos (might be AD) or LDAP (might also be AD) and have
> that managed by the security team: that way all these compliance
Crikey, that would be quite a lot of lot of SSL/TLS to set up. We have
quite a few (massive understatement :( ... ) PostgreSQL database
clusters spread over quite a lot (another understatement) of VMs.
The last time I suggested LDAP there was a lot of enthusiasm ... until
they went down and looked at what might have to be done, after which it
all became very quiet ...
Regards,
Martin.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Password complexity/history - credcheck?
2024-06-23 00:23 Re: Password complexity/history - credcheck? Tom Lane <[email protected]>
2024-06-23 09:30 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
2024-06-23 10:49 ` Re: Password complexity/history - credcheck? Christoph Moench-Tegeder <[email protected]>
2024-06-23 13:14 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
@ 2024-06-24 08:20 ` Laurenz Albe <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Laurenz Albe @ 2024-06-24 08:20 UTC (permalink / raw)
To: Martin Goodson <[email protected]>; Christoph Moench-Tegeder <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]
On Sun, 2024-06-23 at 14:14 +0100, Martin Goodson wrote:
> On 23/06/2024 11:49, Christoph Moench-Tegeder wrote:
> > My advice would be to not use secrets stored in the database -
> > that is, do not use scram-sha-256 - but use an external authentication
> > system, like Kerberos (might be AD) or LDAP (might also be AD) and have
> > that managed by the security team: that way all these compliance
>
> Crikey, that would be quite a lot of lot of SSL/TLS to set up. We have quite a
> few (massive understatement :( ... ) PostgreSQL database clusters spread over
> quite a lot (another understatement) of VMs.
>
> The last time I suggested LDAP there was a lot of enthusiasm ... until they went
> down and looked at what might have to be done, after which it all became very quiet ...
Yes, LDAP is not perfect for that - for one, every connection to the database would
also hit the LDAP server.
Kerberos or certificate authentication is probably better.
For many PostgreSQL clusters and clients, that might be a lot of work.
But not all your PostgreSQL databases will contain equally sensitive data.
You could start with the important ones, try to automatize as much as possible,
and roll out the changes over time.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Password complexity/history - credcheck?
2024-06-23 00:23 Re: Password complexity/history - credcheck? Tom Lane <[email protected]>
2024-06-23 09:30 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
2024-06-23 10:49 ` Re: Password complexity/history - credcheck? Christoph Moench-Tegeder <[email protected]>
2024-06-23 13:14 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
@ 2024-06-24 15:01 ` Christoph Moench-Tegeder <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Christoph Moench-Tegeder @ 2024-06-24 15:01 UTC (permalink / raw)
To: Martin Goodson <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]
## Martin Goodson ([email protected]):
> Crikey, that would be quite a lot of lot of SSL/TLS to set up. We
> have quite a few (massive understatement :( ... ) PostgreSQL database
> clusters spread over quite a lot (another understatement) of VMs.
No matter what: you'll have to touch all your instances anyways.
The good thing is that all the options (including TLS) can be
automatically deployed iff you're set up for that - and you should
be, especially when you have "many" databases.
> The last time I suggested LDAP there was a lot of enthusiasm ... until
> they went down and looked at what might have to be done, after which
> it all became very quiet ...
With "many" databases and personal accounts, you should have some
sort of central management (else even an inventory of the accounts
("who can access what") is a nightmare). Finding the best ways towards
that goal for your organization could be beyond the scope of an email
list - but I'd start with looking at what you already have. I mentioned
LDAP because all too often that's the system which you can most easily
get access to (but depending on your environment, that might mot be
the best solution).
Regards,
Christoph
--
Spare Space.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Password complexity/history - credcheck?
2024-06-23 00:23 Re: Password complexity/history - credcheck? Tom Lane <[email protected]>
2024-06-23 09:30 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
@ 2024-06-23 15:09 ` Greg Sabino Mullane <[email protected]>
2024-06-24 12:59 ` 2FA - - - was Re: Password complexity/history - credcheck? o1bigtenor <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Greg Sabino Mullane @ 2024-06-23 15:09 UTC (permalink / raw)
To: Martin Goodson <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]
On Sun, Jun 23, 2024 at 5:30 AM Martin Goodson <[email protected]>
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/complexity.
Cheers,
Greg
^ permalink raw reply [nested|flat] 9+ messages in thread
* 2FA - - - was Re: Password complexity/history - credcheck?
2024-06-23 00:23 Re: Password complexity/history - credcheck? Tom Lane <[email protected]>
2024-06-23 09:30 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
2024-06-23 15:09 ` Re: Password complexity/history - credcheck? Greg Sabino Mullane <[email protected]>
@ 2024-06-24 12:59 ` o1bigtenor <[email protected]>
2024-06-24 13:30 ` Re: 2FA - - - was Re: Password complexity/history - credcheck? Chris Travers <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: o1bigtenor @ 2024-06-24 12:59 UTC (permalink / raw)
To: ; +Cc: [email protected]
On Sun, Jun 23, 2024 at 10:10 AM Greg Sabino Mullane <[email protected]>
wrote:
> On Sun, Jun 23, 2024 at 5:30 AM Martin Goodson <[email protected]>
> 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/complexity.
>
>
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 because
of course SMS 'always' works (except it doesn't(!!!!!!!!!!!!!!!!)).
(Can you tell that I've been bitten in the posterior repeatedly with this
garbage?)
Regards
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: 2FA - - - was Re: Password complexity/history - credcheck?
2024-06-23 00:23 Re: Password complexity/history - credcheck? Tom Lane <[email protected]>
2024-06-23 09:30 ` Re: Password complexity/history - credcheck? Martin Goodson <[email protected]>
2024-06-23 15:09 ` Re: Password complexity/history - credcheck? Greg Sabino Mullane <[email protected]>
2024-06-24 12:59 ` 2FA - - - was Re: Password complexity/history - credcheck? o1bigtenor <[email protected]>
@ 2024-06-24 13:30 ` Chris Travers <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: Chris Travers @ 2024-06-24 13:30 UTC (permalink / raw)
To: o1bigtenor <[email protected]>; +Cc: [email protected]
On Mon, Jun 24, 2024 at 8:00 PM o1bigtenor <[email protected]> wrote:
>
>
> On Sun, Jun 23, 2024 at 10:10 AM Greg Sabino Mullane <[email protected]>
> wrote:
>
>> On Sun, Jun 23, 2024 at 5:30 AM Martin Goodson <[email protected]>
>> 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/complexity.
>>
>>
> 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 because
> 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=sameuser. 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
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2024-06-24 15:01 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-06-23 00:23 Re: Password complexity/history - credcheck? Tom Lane <[email protected]>
2024-06-23 09:30 ` Martin Goodson <[email protected]>
2024-06-23 10:49 ` Christoph Moench-Tegeder <[email protected]>
2024-06-23 13:14 ` Martin Goodson <[email protected]>
2024-06-24 08:20 ` Laurenz Albe <[email protected]>
2024-06-24 15:01 ` Christoph Moench-Tegeder <[email protected]>
2024-06-23 15:09 ` Greg Sabino Mullane <[email protected]>
2024-06-24 12:59 ` 2FA - - - was Re: Password complexity/history - credcheck? o1bigtenor <[email protected]>
2024-06-24 13:30 ` Re: 2FA - - - was Re: Password complexity/history - credcheck? Chris Travers <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox