Home > Blockchain >  Is it possible to set a mimimum period of validity of a user-password in Oracle Database
Is it possible to set a mimimum period of validity of a user-password in Oracle Database

Time:01-13

we are using Oracle Database 12c (migrating to 19c in the next months) as basis for an application. Currently I`m dealing with a general password guideline and how to implement the requirements of the guideline to the oracle user-passwords.

I know that i can write my own password verify function in the utlpwdmg.sql script to force a certain level of complexity of the password. I can also set the PASSWORD_LIFE_TIME and so on. But is it also possible to set a minimum time, a password is not allowed to be changed (e.g. I have set my password, and in the next 24 hours i am not allowed to change my password again)? I can`t find a resource which corresponds to this requirement.

Thank you very much!

CodePudding user response:

Not directly, as far as I can tell.

My Oracle Support document ID 2036008.1 suggests us to create our own function (let's call it password_minimum_age) which will be checking it.

Shortly, you'd select ptime from sys.user$ for that particular username and compare it to sysdate; if you find out that it is changed too soon, raise an error.

You'd then use that function to create profile, e.g.

create profile password_age limit password_verify_function password_minimum_age;

and alter user to use that profile:

alter user scott profile password_age;

CodePudding user response:

First off, I'd push back on that requirement. The most common time that a user forgets their password is right after they changed it. Declaring that users aren't allowed to work for 24 hours because they can't remember the password they just changed doesn't seem like a sensible idea. If the goal is to prevent users from cycling their password back to the original value (i.e. changing "password" to "password2022" and back to "password"), you can set password_reuse_time to prevent passwords from being reused for a period of time (or forever). If the goal is to prevent an attack where a DBA changes a user's password, logs in as that user to do something nefarious, and then immediately changes the password back, the proper approach would be to audit password changes in a way that the DBA can't modify.

If you do want to implement such a thing, you can expand whatever password verification function you're using to include a check on the last time the password was changed. If you want to blindly enforce the requirement, you could use the ptime in sys.user$. Or password_date in user_history$ assuming you've set password_reuse_time or password_reuse_max. But my guess is that you'd need to do something a bit more involved (i.e. allowing certain users like a DBA to change the password early) so that you have the ability to override the rule when the VP of Accounting is locked out of the system because the password he's sure he set yesterday isn't working and he has to get reports together for the board meeting this evening.

  •  Tags:  
  • Related