MIME-Version: 1.0
In-Reply-To: <CAP79kiTUN+7bixhP30F0CMH90+RdeWtBE7BAWSUH8b3kOvDuLA@mail.gmail.com>
References: <577D96E8.60502@gmail.com> <CAC540oiLsoSZ+26yqv0ecmFq8P__4+NbGQUPjQgLqGqjZPkEGQ@mail.gmail.com>
 <577DA534.2090905@gmail.com> <CADo_RaP=DgVAr6SsqF8WX+JNsyyBHBCqY+_BtW6XoZT05Kd_Ww@mail.gmail.com>
 <016201d1d808$763be5f0$62b3b1d0$@comcast.net> <CAP79kiTUN+7bixhP30F0CMH90+RdeWtBE7BAWSUH8b3kOvDuLA@mail.gmail.com>
From: Andy Klock <andy@oracledepot.com>
Date: Thu, 7 Jul 2016 09:32:56 -0400
Message-ID: <CADo_RaMmO1hTeKfD3DoTZuQKLKU5+sbJ11fwm8mHYMUEs5JQmA@mail.gmail.com>
Subject: Re: Passwords in DBA_USERS (Oracle 12c)
To: Chris Taylor <christopherdtaylor1994@gmail.com>
Cc: dimensional.dba@comcast.net, Mladen Gogala <gogala.mladen@gmail.com>, 
 oracle-l <oracle-l@freelists.org>
Content-Type: multipart/alternative; boundary=94eb2c06af4054851505370bb9b2
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: andy@oracledepot.com
--94eb2c06af4054851505370bb9b2
Content-Type: text/plain; charset=UTF-8

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@gmail.com> 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
>
>

--94eb2c06af4054851505370bb9b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">All your points are valid Chris.=C2=A0 My absurdity commen=
t is about the Oracle software allowing someone to log into someone else=
9;s account and then reset the password back to its previous state. This is=
 a gaping security hole that should be filled.=C2=A0Removing PASSWORD from =
DICTIONARY access was a step in the right direction. Those hashes shouldn&#=
39;t be considered unbreakable.=C2=A0<div><br></div><div>Didn&#39;t meant t=
o imply that the Mladen was doing anything wrong.=C2=A0<br><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Thu, Jul 7, 2016 at 9:16 AM, C=
hris Taylor <span dir=3D"ltr">&lt;<a href=3D"mailto:christopherdtaylor1994@=
gmail.com" target=3D"_blank">christopherdtaylor1994@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"f=
ont-family:arial,helvetica,sans-serif">Having the password &quot;somewhere&=
quot; is important so I&#39;m not sure if Andy is suggesting it&#39;s absur=
d to have it anywhere in the database or not.=C2=A0 But for at least one ca=
se it&#39;s terribly important and that is supporting legacy applications.<=
/div><div style=3D"font-family:arial,helvetica,sans-serif"><br></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif">Sometimes you need to be ab=
le to login as an application schema to create an object such as a material=
ized view or database link that is either exceptionally difficult or imposs=
ible to do UNLESS you are logged in as the schema owner.</div><div style=3D=
"font-family:arial,helvetica,sans-serif">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 o=
r MV), then change the password back without ever affecting the application=
 (or briefly affecting the application at least).</div><div style=3D"font-f=
amily:arial,helvetica,sans-serif"><br></div><div style=3D"font-family:arial=
,helvetica,sans-serif">Thanks,</div><div style=3D"font-family:arial,helveti=
ca,sans-serif">Chris</div><div style=3D"font-family:arial,helvetica,sans-se=
rif"><br></div></div></blockquote></div><br></div></div></div>

--94eb2c06af4054851505370bb9b2--
--
http://www.freelists.org/webpage/oracle-l