Re: Fun with ALTER_USER

If you want to somewhat automate this, use auto-generated passwords instead. If you consider your corporate email secure, you can then have the new password emailed to the user instead of allowing him or her to enter it. You could take it a bit further and generate URLs to retrieve the password, which can only be used once.

E.g.

• Present the user with a form he needs to login to (with e.g. his email).
• The form allows him to select the database username to reset
• Your procedure then resets it to a random, secure password and by whatever means lets the user know the new password
• They can then update their applications

> 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
>>
>

-- 
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | _at_zztat_oracle | fb.me/zztat | zztat.net/blog/

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