Re: Fun with ALTER_USER

On the other hand, one can easily predict outages when the password is changed. The applications will no longer be able to connect. There will be a period between the password change and the change in configuration files. You can even have more fun and send new passwords using snail mail and scented envelopes.

On 3/4/19 4:53 AM, Stefan Knecht wrote:
> 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
>
> For tools that don't support wallets properly, this may work pretty
> well. Should be easy to build in APEX.
>
> Stefan
>
>
>
>
> On Sun, Mar 3, 2019 at 9:34 PM Gus Spier <gus.spier_at_gmail.com
> <mailto:gus.spier_at_gmail.com>> wrote:
>
> 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
> <mailto:andy_at_oracledepot.com>> wrote:
>
>
> On Thu, Feb 28, 2019 at 3:26 PM Gus Spier <gus.spier_at_gmail.com
> <mailto: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 <http://zztat.net/> | _at_zztat_oracle |
> fb.me/zztat <http://fb.me/zztat> | zztat.net/blog/
> <http://zztat.net/blog/>

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217


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