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 1A0B81960192 for ; Thu, 7 Jul 2016 16:28:37 +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:28:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 98C9B24EBB; Thu, 7 Jul 2016 10:28:35 -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 AAIddurY9GtI; Thu, 7 Jul 2016 10:28:35 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A11AF24DC5; Thu, 7 Jul 2016 10:28:22 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 07 Jul 2016 10:27:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 71B9225244 for ; Thu, 7 Jul 2016 10:27:00 -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 qULPk9ogHlZR for ; Thu, 7 Jul 2016 10:27:00 -0400 (EDT) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) (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 467F025242 for ; Thu, 7 Jul 2016 10:26:59 -0400 (EDT) Received: by mail-qk0-f182.google.com with SMTP id e3so15681931qkd.0 for ; Thu, 07 Jul 2016 07:26:59 -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=o6cR2HfLE/LpwJYmhqDPyrp7d9BybDuM3YZYlyA7UJI=; b=eMNRsATJmj1Li3JAgHz7E6fDkIWqnBqLdp/uSXaG3pKk89oaf0MbJKGk1MTRVMcLPJ HNU3bfJNSbnh6g7m6bQuowNxzgpeitiYGMiVzB/gGRKk/pSzTjhPuSW6YMq5U7JUrxMX jqZjIqPEb2wYkZqACLSQ/z2QFaeq9n1ceKuM1fpcTYUOTTBSVSgabNT0UQhSQ6ftHGLT d00Uf0WdDoREc6y7DfU0Nu90PnrL0YGaSoWD3sJwLPEmHu4ZpsctLK3tF4hth7VbTBUk 5bNxNeBSOfJB3nT0XJf/xV3pjEcDj7K8e8iywq/nX+94JuptfT8hmNXkjXLxrpc0VSpo bIAA== X-Gm-Message-State: ALyK8tKCB+8uN8flLEq7q2wpSBSWCnQRMugh54lz/+mTBua3gJ+qDb0Vu7qI5tzaCfvbPexykYvwxivJ/3POyw== X-Received: by 10.55.214.77 with SMTP id t74mr641479qki.80.1467901619139; Thu, 07 Jul 2016 07:26:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.75.66 with HTTP; Thu, 7 Jul 2016 07:26:58 -0700 (PDT) In-Reply-To: References: <577D96E8.60502@gmail.com> <577DA534.2090905@gmail.com> <016201d1d808$763be5f0$62b3b1d0$@comcast.net> From: Andrew Kerber Date: Thu, 7 Jul 2016 09:26:58 -0500 Message-ID: Subject: Re: Passwords in DBA_USERS (Oracle 12c) To: mark.powell2@hpe.com Cc: Chris Taylor , "andy@oracledepot.com" , "dimensional.dba@comcast.net" , Mladen Gogala , oracle-l Content-Type: multipart/alternative; boundary=001a1149d29893114c05370c7ab7 X-archive-position: 65473 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: andrew.kerber@gmail.com Precedence: normal Reply-To: andrew.kerber@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 --001a1149d29893114c05370c7ab7 Content-Type: text/plain; charset=UTF-8 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 < > 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.' --001a1149d29893114c05370c7ab7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes.=C2=A0 Until programmers learn to include functionalit= y that allows passwords to be changed easily on the mid tier, the DBA or de= signated security personnel must be able to change a password and take it b= ack to what it was.

On Thu, Jul 7, 2016 at 9:20 AM, Powell, Mark = <mark.powell2@= hpe.com> wrote:
Andy, I wil= l disagree that it is absurd for Oracle to allow a means for a 'privile= ged' user to be able to change another's users password hash becaus= e without such a method how would an existing user with their existing pass= word be migrated to another database?

________________________________
From: oracle-l-bounce@free= lists.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.=C2=A0 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 fro= m 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@gm= ail.com<mailto:c= hristopherdtaylor1994@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


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





--
Andrew W. Kerber

'If = at first you dont succeed, dont take up skydiving.'
--001a1149d29893114c05370c7ab7-- -- http://www.freelists.org/webpage/oracle-l