The hash in SPARE4 is just much longer.
begin
dbms_metadata.set_transform_param (dbms_metadata.session_transform,'DEFAULT');
dbms_metadata.set_transform_param(dbms_metadata.session_transform,'PRETTY',TRUE);
dbms_metadata.set_transform_param(dbms_metadata.session_transform,'SQLTERMINATOR',TRUE);
end;
/
SELECT DBMS_METADATA.GET_DDL('USER','THE_USER') from dual;
Then copy the hash value into:
alter user THE_USER identified by values ‘COPY THE HASH VALUE FROM THE QUERY
ABOVE’; -- The hash is very long normally with S: and H: and T: section.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Andrew Kerber
Sent: Thursday, July 07, 2016 10:27 AM
To: mark.powell2@xxxxxxx
Cc: Chris Taylor <christopherdtaylor1994@xxxxxxxxx>; andy@xxxxxxxxxxxxxxx;
dimensional.dba@xxxxxxxxxxx; Mladen Gogala <gogala.mladen@xxxxxxxxx>; oracle-l
<oracle-l@xxxxxxxxxxxxx>
Subject: Re: Passwords in DBA_USERS (Oracle 12c)
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.'
Notice of Confidentiality: **This E-mail and any of its attachments may contain
Lincoln National Corporation proprietary information, which is privileged,
confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the individual or
entity to
which it is addressed. If you are not the intended recipient of this E-mail,
you are
hereby notified that any dissemination, distribution, copying, or action taken
in
relation to the contents of and attachments to this E-mail is strictly
prohibited
and may be unlawful. If you have received this E-mail in error, please notify
the
sender immediately and permanently delete the original and any copy of this
E-mail
and any printout. Thank You.**
