Re: Fun with ALTER_USER

From: Gus Spier <gus.spier_at_gmail.com>
Date: Sun, 3 Mar 2019 09:33:09 -0500
Message-ID: <CAG8xnifC29DbeHwVjysfMBfR07MdBHevxityjHHxk7StjyMBBg_at_mail.gmail.com>



You guys are right. There is no good way to do this, except to retrain or re-indoctrinate everyone to take minimum security practices seriously. But I wasn't tasked to do that. And, I have the perfect opportunity to really learn SQL Injection counter-measures.

Thanks for the input.

Gus

On Sun, Mar 3, 2019 at 8:39 AM Andy Klock <andy_at_oracledepot.com> wrote:

>
> On Thu, Feb 28, 2019 at 3:26 PM Gus Spier <gus.spier_at_gmail.com> wrote:
>
>>
>> It fell in my lap to produce the tool. It certainly seems that it should
>> work. But I suspect there are complications with which I am unfamiliar.
>>
>>
> Apart from Dynamic SQL being the devil and me not wanting to rain on your
> fun, this all looks like a really bad idea. I like that management is
> trying to address a common attack vector, but this tool is opening ways to
> hand passwords to would-be attackers. If the connection from the client to
> the database isn't encrypted then the password is going over the wire in
> clear text. And since it is being passed into a bind variable then it is
> sitting in the SGA in clear text. (Meaning, anyone with SELECT ANY
> DICTIONARY, regardless of who they are what their role is, can possibly see
> it).
>
> The best tool for changing passwords is sqlplus. (But you probably already
> knew that :) ) It validates that the old password is known and that the new
> password has been typed in correctly twice. The new password is never sent
> or stored clear text, so dramatically more secure. Time would be better
> spent writing a function that validates that the new password conforms to
> your company policy.
>
>
> https://docs.oracle.com/database/121/DBSEG/authentication.htm#GUID-38B80221-55AE-4928-9AC0-4CAFFD5A4E96
>
> And hopefully your DEVs are using wallets :)
>
> Sorry about being a bummer.
>
> Andy K
>

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Mar 03 2019 - 15:33:09 CET

Original text of this message