Re: Pasword expiration warning

From: Gilles Darold <gilles(at)migops(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pasword expiration warning
Date: 2021-11-19 16:56:20
Message-ID: a776f2d0-7ef8-f734-48b7-2aa383f41b2b@migops.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Le 19/11/2021 à 16:55, Tom Lane a écrit :
> Gilles Darold <gilles(at)migops(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marcos Pegoraro 2021-11-19 17:03:09 Re: update with no changes
Previous Message Andres Freund 2021-11-19 16:49:52 Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)