Re: Passwords in DBA_USERS (Oracle 12c)

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Thu, 7 Jul 2016 09:56:50 -0400
Message-ID: <577E5FA2.9070902_at_gmail.com>



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_at_gmail.com
> <mailto:christopherdtaylor1994_at_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


--
http://www.freelists.org/webpage/oracle-l
Received on Thu Jul 07 2016 - 15:56:50 CEST

Original text of this message