Re: capture oracle pwd change in 3rd party application. help needed

Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1068245466.11957_at_yasure>...
> Pete Finnigan wrote:
>
> >>> My objection is that it would take me a matter of minutes to
> >>>
> >>>
> >> make myself an account on another
> >> machine on which I had no permissions. It is a hacker's delight.
> >>
> >>
> >
> >Hi Daniel,
> >
> >I think there is another point to make here is that we are not
> >implementing this but just discussing possible solutions without knowing
> >the application or architecture, tools, requirements etc.... I would say
> >that a script to synchronise password hash values should be run in a
> >secure manner and also would not add new accounts, just synchronise old
> >ones. I would also re-iterate this isn't the way to fix an issue like
> >this, why does this application need to have synchronised access to two
> >databases? and why isn't the manufacturer involved.
> >
> >kind regards
> >
> >Pete
> >
> >
> My personal opinion? The person asking the question is trying to crack a
> database.
> I've never seen an application with this architecture in 34 years in the
> business.

Well, what do you think of SSO in Portal? The whole idea is to spread a single password among apps. Then they give code to show the passwords to admins! (ie, metalink note 205984.1). And you wind up with two passwords, one of which is used in some places and the other in others (such as whether you make all the, ahem, required public synonyms through portal or sqlplus). IDENTIFIED GLOBALLY requires some sort of syncronization between db's, and/or careful use of schema independence.

>
> I'd really like to be wrong.

You may well be right, but By Values has been common knowledge for generations. A couple of times I've almost written things like the OP asked for, but it always turned out to be not necessary due to the methods of copying the db. It's easy to envision an architecture like that, though, particularly with unique ETL requirements. I've seen worse - like admins keeping passwords in email so they know what to change them all to manually.

jg

--
@home.com is bogus.
http://cbs.marketwatch.com/news/story.asp?guid=%7B954AA053-F953-43F3-BBC8-63D351A3BF2A%7D&siteid=google&dist=google