Yes. Until programmers learn to include functionality that allows
passwords to be changed easily on the mid tier, the DBA or designated
security personnel must be able to change a password and take it back to
what it was.
On Thu, Jul 7, 2016 at 9:20 AM, Powell, Mark <mark.powell2@xxxxxxx> wrote:
Andy, I will disagree that it is absurd for Oracle to allow a means for a
'privileged' user to be able to change another's users password hash
because without such a method how would an existing user with their
existing password be migrated to another database?
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on
behalf of Andy Klock <andy@xxxxxxxxxxxxxxx>
Sent: Thursday, July 7, 2016 9:32:56 AM
To: Chris Taylor
Cc: dimensional.dba@xxxxxxxxxxx; Mladen Gogala; oracle-l
Subject: Re: Passwords in DBA_USERS (Oracle 12c)
All your points are valid Chris. My absurdity comment is about the Oracle
software allowing someone to log into someone else's account and then reset
the password back to its previous state. This is a gaping security hole
that should be filled. Removing PASSWORD from DICTIONARY access was a step
in the right direction. Those hashes shouldn't be considered unbreakable.
Didn't meant to imply that the Mladen was doing anything wrong.
On Thu, Jul 7, 2016 at 9:16 AM, Chris Taylor <
christopherdtaylor1994@xxxxxxxxx<mailto:christopherdtaylor1994@xxxxxxxxx>>
wrote:
Having the password "somewhere" is important so I'm not sure if Andy is
suggesting it's absurd to have it anywhere in the database or not. But for
at least one case it's terribly important and that is supporting legacy
applications.
Sometimes you need to be able to login as an application schema to create
an object such as a materialized view or database link that is either
exceptionally difficult or impossible to do UNLESS you are logged in as the
schema owner.
The DBA may not have access to the schema password but can preserve the
password by looking at sys.user$ for the encrypted password, temporarily
change it, create the object (db link or MV), then change the password back
without ever affecting the application (or briefly affecting the
application at least).
Thanks,
Chris
--
//www.freelists.org/webpage/oracle-l
