Re: Passwords in DBA_USERS (Oracle 12c)
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-lReceived on Thu Jul 07 2016 - 15:56:50 CEST