Time to learn about Oracle RAS (Real Application Security), an EE
functionality (not option) with which you no longer need to register
users in the database, and you establish a trust relationship with the
middle tier to properly authenticate the user.
Two books on it at http://docs.oracle.com/database/121/nav/portal_25.htm
(Licensing: http://docs.oracle.com/database/121/DBLIC/editions.htm#DBLIC116)
/Hans
On 07/07/2016 8:26 AM, Andrew Kerber wrote:
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 <mailto: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
<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
<oracle-l-bounce@xxxxxxxxxxxxx
<mailto:oracle-l-bounce@xxxxxxxxxxxxx>> on behalf of Andy Klock
<andy@xxxxxxxxxxxxxxx <mailto:andy@xxxxxxxxxxxxxxx>>
Sent: Thursday, July 7, 2016 9:32:56 AM
To: Chris Taylor
Cc: dimensional.dba@xxxxxxxxxxx
<mailto: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><mailto: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
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
