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 C541C19600F4 for ; Thu, 7 Jul 2016 17:33:54 +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 17:33:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7366025059; Thu, 7 Jul 2016 11:33:53 -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 JE5FelsWm4Io; Thu, 7 Jul 2016 11:33:53 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 81EEF251E0; Thu, 7 Jul 2016 11:33:38 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 07 Jul 2016 11:32:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 9B9FE23A25 for ; Thu, 7 Jul 2016 11:32:16 -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 Mb72OGzqL4rK for ; Thu, 7 Jul 2016 11:32:16 -0400 (EDT) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (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 6F9F423A0D for ; Thu, 7 Jul 2016 11:32:16 -0400 (EDT) Received: by mail-it0-f52.google.com with SMTP id f6so22703931ith.0 for ; Thu, 07 Jul 2016 08:32:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Bj5p96LPrtMksGlntrl+fw2CaIJAwiz2dT8ghwN+uBI=; b=EyW1PgLoF/MlYj9esV0mnTxcO06HgGdvfbSxWew75NIsvgcFYu2WBsF5VYBXV03mC5 wnqbauGZSZNFnGfjvg/ngl0Ih9DrQZpviQjXik15GvNe+A89JNxcTAin0rpGbeaMdpN3 /zpa05cOnDRwFzXPXeg3sa+8ba0ox/kt+0PRW7oLf1TXJ4MAIwfrpMPqOCOENwkgdwuO KkKLkdnlPWL7eKVepWML8vFq+n0xeydh4BW32ObzxeOH6Nwv6sg0ZhFh0IDwyPuMPPhK 6ms89GrdJW/OsAqlRnajA5f9brgwFkyOU/PZe56i/u+eKExatvWgQd+q/HxneiNdkL5Y gCZA== X-Gm-Message-State: ALyK8tLdNYZ1GiHH7BkY2cJeSVzhkGwNw2paJxhUBB9O7sngaLFFOzmdI1WnY1rc4y7y6Q== X-Received: by 10.36.29.20 with SMTP id 20mr23632876itj.99.1467905535542; Thu, 07 Jul 2016 08:32:15 -0700 (PDT) Received: from [172.16.204.148] (d75-158-35-17.abhsia.telus.net. [75.158.35.17]) by smtp.gmail.com with ESMTPSA id 92sm1371864iok.22.2016.07.07.08.32.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jul 2016 08:32:15 -0700 (PDT) Subject: Re: Passwords in DBA_USERS (Oracle 12c) To: oracle-l@freelists.org References: <577D96E8.60502@gmail.com> <577DA534.2090905@gmail.com> <016201d1d808$763be5f0$62b3b1d0$@comcast.net> From: Hans Forbrich Message-ID: <577E75FD.1000402@gmail.com> Date: Thu, 7 Jul 2016 09:32:13 -0600 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010208050305080905030508" X-archive-position: 65479 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: fuzzy.graybeard@gmail.com Precedence: normal Reply-To: fuzzy.graybeard@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 --------------010208050305080905030508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 > 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 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 > >> 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 > > > -- > http://www.freelists.org/webpage/oracle-l > > > > > > -- > Andrew W. Kerber > > 'If at first you dont succeed, dont take up skydiving.' --------------010208050305080905030508 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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@hpe.com> 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 <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: 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 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


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





--
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

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