I have clients using an application that allows users to change their
passwords. The application uses the 'ALTER USER xxx IDENTIFIED
BY.....' command. What I need to do is use Oracle to capture the
username and password and send the info to another Oracle instance on
a different server and update that users password.
Basically I need to keep the user's password in sync between two
different databases.
I also cannot change the application in anyway and therefore need to
do this from the Oracle side.
Any ideas would be great.........
This all sounds a bit like hacking to me, not the best way to solve a
problem!, - maybe it would be better to ask the application
manufacturer?.
BUT, there are a number of possibilities that you could try, you could
implement a layer above OCI (it should be OCI unless its the thin
driver) and basically get the third party application to call your
version of OCI first, extract the string and then call the real OCI
layer. This is a hard way to crack the problem though. If it is java you
could do something illegal and decompile the java and modify it and
recompile - your supplier would not support you though!!!!
You don't have to access the username and password either in the
application, you could just run a process regularly that synchronises
password hashes between the databases using the "identified by values"
version of alter user. This would depend on how long you can wait for
passwords to synchronise. You could also use single sign on?
You could also grab the text off the wire or via trace, my recent paper
called "detecting SQL injection in Oracle" might help. You can get it at
http://www.petefinnigan.com/orasec.htm. Finally you might be able to
find a way to screen scrape the application at the terminal level -
there are a few commercial products to do this, mainly used for
automated testing.
hth
kind regards
Pete
PS: please don't cross post, most people read all of these groups!
--
Pete Finnigan
email:pe...@petefinnigan.com
Web site: http://www.petefinnigan.com - Oracle security audit specialists
Book:Oracle security step-by-step Guide - see http://store.sans.org for details.
Go to $ORACLE_HOME/rdmbs/admin
Look at the file utlpwdmg.sql
If you have any business doing this you will be able to fill in the rest
of the picture.
Personally I agree with Pete. This is nonsense and worse than nonsense a
huge violation
of any reasonable definition of system security. The OEM should fix the
problem. And
my advise to you would be not to do this. That it can be done doesn't
mean that it should
be done. The entire idea stinks.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damo...@x.washington.edu
(replace 'x' with a 'u' to reply)
I'm not sure what is so wrong about this, at least using Pete's
suggestion of Identified by Values in a non-public environment? It
seems as reasonable as, say, copying /etc/passwd (or shadow
equivalents) and user files to synchronize users on two identical
servers.
jg
--
@home.com is bogus.
http://www.signonsandiego.com/news/metro/20031106-9999_2m6wage.html
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 objection is that it would take me a matter of minutes tomake 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
"Daniel Morgan" <damo...@x.washington.edu> wrote in message news:1068245466.11957@yasure...
--------------Actually one of the databases I manage runs on an application which doessomething similar (Not the synchronization .. but the way it creates application accounts ...by creating an Oracle account). The application being Bladerunner.If you ever get a chance .. run (really fast) away from it.:0)Anurag
"Daniel Morgan" <damo...@x.washington.edu> wrote in message news:1068311431.525724@yasure...
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.