public inbox for [email protected]
help / color / mirror / Atom feedFrom: Gilles Darold <[email protected]>
To: Tom Lane <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Pasword expiration warning
Date: Fri, 19 Nov 2021 17:56:20 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Le 19/11/2021 à 16:55, Tom Lane a écrit :
> Gilles Darold <[email protected]> writes:
>> Now that the security policy is getting stronger, it is not uncommon to
>> create users with a password expiration date (VALID UNTIL).
> TBH, I thought people were starting to realize that forced password
> rotations are a net security negative. It's true that a lot of
> places haven't gotten the word yet.
>
>> I'm wondering if we might be interested in having this feature in psql?
> This proposal kind of seems like a hack, because
> (1) not everybody uses psql
Yes, for me it's a comfort feature. When a user connect to a PG backend
using an account that have expired you have no information that the
problem is a password expiration. The message returned to the user is
just: "FATAL: password authentication failed for user "foo". We had to
verify in the log file that the problem is related to "DETAIL: User
"foo" has an expired password.". If the user was warned beforehand to
change the password it will probably saves me some time.
> (2) psql can't really tell whether rolvaliduntil is relevant.
> (It can see whether the server demanded a password, but
> maybe that went to LDAP or some other auth method.)
I agree, I hope that in case of external authentication rolvaliduntil is
not set and in this case I guess that there is other notification
channels to inform the user that his password will expire. Otherwise yes
the warning message could be a false positive but the rolvaliduntil can
be changed to infinity to fix this case.
> That leads me to wonder about server-side solutions. It's easy
> enough for the server to see that it's used a password with an
> expiration N days away, but how could that be reported to the
> client? The only idea that comes to mind that doesn't seem like
> a protocol break is to issue a NOTICE message, which doesn't
> seem like it squares with your desire to only do this interactively.
> (Although I'm not sure I believe that's a great idea. If your
> application breaks at 2AM because its password expired, you
> won't be any happier than if your interactive sessions start to
> fail. Maybe a message that would leave a trail in the server log
> would be best after all.)
I think that this is the responsibility of the client to display a
warning when the password is about to expire, the backend could help the
application by sending a NOTICE but the application will still have to
report the notice. I mean that it can continue to do all the work to
verify that the password is about to expire.
>> Default value is 0 like today no warning at all.
> Off-by-default is pretty much guaranteed to not help most people.
Right, I was thinking of backward compatibility but this does not apply
here. So default to 7 days will be better.
To sum up as I said on top this is just a comfort notification dedicated
to psql and for local pg account to avoid looking at log file for
forgetting users.
--
Gilles Darold
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Pasword expiration warning
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox