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
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?) |