Re: password_rollover_time like Oracle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Jun 20, 2024, at 10:46 PM, Bruce Momjian <bruce@xxxxxxxxxx> wrote:

I can see that causing problems if you want to store CURRENT_USER in the
database, perhaps for auditing.  I guess you could call it user4_login12
and keep incrementing the login number, but that seems cumbersome.

-- 
 Bruce Momjian  <bruce@xxxxxxxxxx>        https://momjian.us
 EDB                                      https://enterprisedb.com

 Only you can decide what is important to you.

I don’t think it’s too much of an issue for auditing as it’s same name with an embedded date code; however, I do think that changing a password every other month is cumbersome busy work and there are better ways to secure the account.  The problem I’ve seen with this type of solution is the application owners would commonly forget to update password information and then the application would stop working causing a scramble to update the credentials.  Then there is the account management itself, dropping expired users and creating new users for the upcoming month.  

[Index of Archives]     [Postgresql Home]     [Postgresql General]     [Postgresql Performance]     [Postgresql PHP]     [Postgresql Jobs]     [PHP Users]     [PHP Databases]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Yosemite Forum]

  Powered by Linux