Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from puck1183.startdedicated.com (localhost [127.0.0.1]) by puck1183.startdedicated.com (Postfix) with ESMTP id C86761960639 for ; Thu, 7 Jul 2016 16:59:55 +0200 (CEST) Received: from turing.freelists.org (turing.freelists.org [206.53.239.180]) by puck1183.startdedicated.com (Postfix) with ESMTPS for ; Thu, 7 Jul 2016 16:59:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 644B724081; Thu, 7 Jul 2016 10:59:13 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH1xuQovqQxh; Thu, 7 Jul 2016 10:59:13 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7B1FD23B32; Thu, 7 Jul 2016 10:59:00 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 07 Jul 2016 10:57:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7F03C2175B for ; Thu, 7 Jul 2016 10:57:38 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSmDNcOCGNl5 for ; Thu, 7 Jul 2016 10:57:38 -0400 (EDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 4F2D521732 for ; Thu, 7 Jul 2016 10:57:38 -0400 (EDT) Received: by mail-oi0-f45.google.com with SMTP id r2so26392577oih.2 for ; Thu, 07 Jul 2016 07:57:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ECNDxWoF80qsf6ySVDuRzav+TJm2Frt4GGgLi7go/CU=; b=CbYqoM815XY89EBx9LJTb78wf8by3tHOiV2Ji4d24OQEW5k74IEuo396SxGBdxW9dF ERjlaRDqNjqt6ja/PpS5zSzAsXOVAKUUByDewOUhFR6ZVT+xvYQoOf5I8q5QE8PUMPL0 0k5QFqj+pK5fmQ9owPbXpYvJQaqboVGRdggzdb/gM3zMgd+2ePfo23/krMDm+oymXIrZ D8cqQIg4jzS21EzIsjjwt3z0WDZdUU2NZ0EIsvbD22gbcMlrlA8CnLRN/CiOntMTPXXZ 9hRNZVhUqkwdBnyGOGBPBAUpbGy9RSR1PHRJ+rYU28G2b7Ku/FZqZVLWCqvbtsOSuZMk BbRQ== X-Gm-Message-State: ALyK8tJYsTizXE9LX8VRoHzndAWTDktzHdgx2dcxzTiWBnMmoX9Wi7ftQXlmqnvCOWMrhVGD/jjKy9zvuGVe5A== X-Received: by 10.157.8.49 with SMTP id 46mr425253oty.81.1467903457803; Thu, 07 Jul 2016 07:57:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.241.6 with HTTP; Thu, 7 Jul 2016 07:57:37 -0700 (PDT) In-Reply-To: References: <577D96E8.60502@gmail.com> <577DA534.2090905@gmail.com> <016201d1d808$763be5f0$62b3b1d0$@comcast.net> From: Chris Taylor Date: Thu, 7 Jul 2016 09:57:37 -0500 Message-ID: Subject: Re: Passwords in DBA_USERS (Oracle 12c) To: "Deas, Scott" Cc: "andrew.kerber@gmail.com" , "mark.powell2@hpe.com" , "andy@oracledepot.com" , "dimensional.dba@comcast.net" , Mladen Gogala , oracle-l Content-Type: multipart/alternative; boundary=94eb2c0308542ac45305370ce81b X-archive-position: 65476 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: christopherdtaylor1994@gmail.com Precedence: normal Reply-To: christopherdtaylor1994@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l --94eb2c0308542ac45305370ce81b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It appears the only problem with this approach is the DBA doesn't include this ability automatically. You still have to do the grant to the DBA to allow the connect through - which requires a 3rd account to do the grant as you can't grant privs to yourself. It would be great if this was included in the DBA role functionality to connect through any user. After setting up the necessary grant, it is definitely easier to do it this way but in the middle of an application deployment, this method is cumbersome if the setup grants haven't been completed. Thanks, Chris On Thu, Jul 7, 2016 at 9:44 AM, Deas, Scott wrote: > But you don=E2=80=99t need to know the user=E2=80=99s password or change = it, you just > proxy into the account. We=E2=80=99ve been using it successfully here fo= r years. > > > > > http://www.oracle.com/technetwork/issue-archive/2013/13-mar/o23asktom-190= 6478.html > > > > Thanks, > Scott > > > > *From:* oracle-l-bounce@freelists.org [mailto: > oracle-l-bounce@freelists.org] *On Behalf Of *Andrew Kerber > *Sent:* Thursday, July 07, 2016 10:27 AM > *To:* mark.powell2@hpe.com > *Cc:* Chris Taylor ; > andy@oracledepot.com; dimensional.dba@comcast.net; Mladen Gogala < > gogala.mladen@gmail.com>; oracle-l > *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 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@freelists.org on > behalf of Andy Klock > Sent: Thursday, July 7, 2016 9:32:56 AM > To: Chris Taylor > Cc: dimensional.dba@comcast.net; Mladen Gogala; oracle-l > Subject: Re: Passwords in DBA_USERS (Oracle 12c) > > All your points are valid Chris. My absurdity comment is about the Oracl= e > software allowing someone to log into someone else's account and then res= et > the password back to its previous state. This is a gaping security hole > that should be filled. Removing PASSWORD from DICTIONARY access was a ste= p > 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 f= or > 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 t= he > 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 ba= ck > without ever affecting the application (or briefly affecting the > application at least). > > Thanks, > Chris > > > -- > http://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 o= r > 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.** > --94eb2c0308542ac45305370ce81b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It appears the only problem with this approach is the D= BA doesn't include this ability automatically.=C2=A0 You still have to = do the grant to the DBA to allow the connect through - which requires a 3rd= account to do the grant as you can't grant privs to yourself.=C2=A0 It= would be great if this was included in the DBA role functionality to conne= ct through any user.

After setting up the necessary = grant, it is definitely easier to do it this way but in the middle of an ap= plication deployment, this method is cumbersome if the setup grants haven&#= 39;t been completed.

Thanks,
Chris
<= br>

On= Thu, Jul 7, 2016 at 9:44 AM, Deas, Scott <Scott.Deas@lfg.com> wrote:

But you don=E2=80=99t need to know th= e user=E2=80=99s password or change it, you just proxy into the account.=C2= =A0 We=E2=80=99ve been using it successfully here for years.<= /span>

=C2=A0

http://www.oracle.com/technetwork/issue-archive/2013/13-mar/o23asktom-1906= 478.html

=C2=A0

Thanks,
Scott

=C2=A0

From: oracle-l-bounce@freelists.org [mai= lto:orac= le-l-bounce@freelists.org] On Behalf Of Andrew Kerber
Sent: Thursday, July 07, 2016 10:27 AM
To: mark.p= owell2@hpe.com
Cc: Chris Taylor <christopherdtaylor1994@gmail.com>; andy@oracledepot.com; <= a href=3D"mailto:dimensional.dba@comcast.net" target=3D"_blank">dimensional= .dba@comcast.net; Mladen Gogala <gogala.mladen@gmail.com>; oracle-l <oracle-l@freelists= .org>
Subject: Re: Passwords in DBA_USERS (Oracle 12c)

=C2=A0

Yes.=C2=A0 Until programmers learn to include functi= onality 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 tak= e it back to what it was.

=C2=A0

On Thu, Jul 7, 2016 at 9:20 AM, Powell, Mark <mark.powell2@hpe.com= > wrote:

Andy, I will disagree= that it is absurd for Oracle to allow a means for a 'privileged' u= ser 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: or= acle-l-bounce@freelists.org <oracle-l-bounce@freelists.org> on behalf= of Andy Klock <andy@oracledepot.com>
Sent: Thursday, July 7, 2016 9:32:56 AM
To: Chris Taylor
Cc: dimens= ional.dba@comcast.net; Mladen Gogala; oracle-l
Subject: Re: Passwords in DBA_USERS (Oracle 12c)

All your points are valid Chris.=C2=A0 My absurdity comment is about the Or= acle software allowing someone to log into someone else's account and t= hen reset the password back to its previous state. This is a gaping securit= y hole that should be filled. Removing PASSWORD from DICTIONARY access was a step in the right direction. Those hashes sho= uldn'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.co= m<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 o= r not.=C2=A0 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 a= n object such as a materialized view or database link that is either except= ionally difficult or impossible to do UNLESS you are logged in as the schem= a owner.
The DBA may not have access to the schema password but can preserve the pas= sword by looking at sys.user$ for the encrypted password, temporarily chang= e it, create the object (db link or MV), then change the password back with= out ever affecting the application (or briefly affecting the application at least).

Thanks,
Chris


--
htt= p://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 Linco= ln National Corporation family of
companies. This E-mail is intended so= lely 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 no= tified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly pr= ohibited
and may be unlawful. If you have received this E-mail in error= , please notify the
sender immediately and permanently delete the origi= nal and any copy of this E-mail
and any printout. Thank You.**


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