Subject: Re: Passwords in DBA_USERS (Oracle 12c)
To: Andy Klock <andy@oracledepot.com>,
 Chris Taylor <christopherdtaylor1994@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>
 <CADo_RaMmO1hTeKfD3DoTZuQKLKU5+sbJ11fwm8mHYMUEs5JQmA@mail.gmail.com>
Cc: dimensional.dba@comcast.net, oracle-l <oracle-l@freelists.org>
From: Mladen Gogala <gogala.mladen@gmail.com>
Message-ID: <577E5FA2.9070902@gmail.com>
Date: Thu, 7 Jul 2016 09:56:50 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CADo_RaMmO1hTeKfD3DoTZuQKLKU5+sbJ11fwm8mHYMUEs5JQmA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------090704080601030605000502"
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: gogala.mladen@gmail.com
--------------090704080601030605000502
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

If I had a choice, which is not the case, my preferred mechanism would 
be "ALTER SESSION SET CURRENT_SCHEMA", but that doesn't work. Scott Deas 
has an interesting mechanism for doing that, without going through the 
password reset.
As for hashes being unbreakable, SHA512 algorithm has not been broken 
yet. It produces 512 bit integer and it would take while to find the 
right combination of ASCII characters with such a hash, even with a 
super-computer, with thousands of CPU resources. That means that for all 
intents and purposes SHA512 is unbreakable.
Regards

On 07/07/2016 09:32 AM, Andy Klock wrote:
> 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 
> <mailto: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
>
>


-- 
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217


--------------090704080601030605000502
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">If I had a choice, which is not the
      case, my preferred mechanism would be "ALTER SESSION SET
      CURRENT_SCHEMA", but that doesn't work. Scott Deas has an
      interesting mechanism for doing that, without going through the
      password reset. <br>
      As for hashes being unbreakable, SHA512 algorithm has not been
      broken yet. It produces 512 bit integer and it would take while to
      find the right combination of ASCII characters with such a hash,
      even with a super-computer, with thousands of CPU resources. That
      means that for all intents and purposes SHA512 is unbreakable.<br>
      Regards<br>
      <br>
      On 07/07/2016 09:32 AM, Andy Klock wrote:<br>
    </div>
    <blockquote
cite="mid:CADo_RaMmO1hTeKfD3DoTZuQKLKU5+sbJ11fwm8mHYMUEs5JQmA@mail.gmail.com"
      type="cite">
      <div dir="ltr">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. 
        <div><br>
        </div>
        <div>Didn't meant to imply that the Mladen was doing anything
          wrong. <br>
          <div class="gmail_extra"><br>
            <div class="gmail_quote">On Thu, Jul 7, 2016 at 9:16 AM,
              Chris Taylor <span dir="ltr">&lt;<a
                  moz-do-not-send="true"
                  href="mailto:christopherdtaylor1994@gmail.com"
                  target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:christopherdtaylor1994@gmail.com">christopherdtaylor1994@gmail.com</a></a>&gt;</span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div dir="ltr">
                  <div style="font-family:arial,helvetica,sans-serif">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.</div>
                  <div style="font-family:arial,helvetica,sans-serif"><br>
                  </div>
                  <div style="font-family:arial,helvetica,sans-serif">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.</div>
                  <div style="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 or MV), then change the
                    password back without ever affecting the application
                    (or briefly affecting the application at least).</div>
                  <div style="font-family:arial,helvetica,sans-serif"><br>
                  </div>
                  <div style="font-family:arial,helvetica,sans-serif">Thanks,</div>
                  <div style="font-family:arial,helvetica,sans-serif">Chris</div>
                  <div style="font-family:arial,helvetica,sans-serif"><br>
                  </div>
                </div>
              </blockquote>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217
</pre>
  </body>
</html>

--------------090704080601030605000502--
--
http://www.freelists.org/webpage/oracle-l