audit change password [message #494428] |
Mon, 14 February 2011 11:06 |
smunir362
Messages: 310 Registered: September 2007
|
Senior Member |
|
|
I want to get information "who ,when change his own or other user password."
I enable audit "alter user"
But It was useless.... If some one have an idea pls share with me.
|
|
|
|
|
|
|
Re: audit change password [message #494439 is a reply to message #494438] |
Mon, 14 February 2011 11:58 |
smunir362
Messages: 310 Registered: September 2007
|
Senior Member |
|
|
I think Log Miner is little hard to setup....
Moreover I have no idea about keeping archived log for how much time.
Currently I have I month archived logs...
What will happen if i want to generate report for last six months of change passwords.....
|
|
|
|
|
|
|
|
Re: audit change password [message #494696 is a reply to message #494685] |
Wed, 16 February 2011 11:33 |
John Watson
Messages: 8963 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Perhaps you could use the password verify function? Include an autonomous transaction that would write out details of the change. I haven't tested this, I would be interested to know if it works.
|
|
|
|
Re: audit change password [message #494705 is a reply to message #494703] |
Wed, 16 February 2011 12:08 |
John Watson
Messages: 8963 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Interesting. Actually, I think this is horrific: in effect, we have a trigger that can capture everyone's password as it is changed. I suppose it becomes necessary to audit ALTER PROFILE as well as all access to the verify function and anything it calls. I hope the security police know about this.
|
|
|
Re: audit change password [message #494707 is a reply to message #494705] |
Wed, 16 February 2011 12:17 |
|
Michel Cadot
Messages: 68731 Registered: March 2007 Location: Saint-Maur, France, https...
|
Senior Member Account Moderator |
|
|
You can create the verify function ONLY in SYS schema, so only those who already have the privilege to change account password or connect without knowing it can capture this password.
But yes, I agree, Oracle should not allow autonmous transaction in verify function; it could be (very) dangerous.
Regards
Michel
[Updated on: Wed, 16 February 2011 12:17] Report message to a moderator
|
|
|
|
|
Re: audit change password [message #495526 is a reply to message #495525] |
Sun, 20 February 2011 11:03 |
John Watson
Messages: 8963 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Smunir, one has to be responsible when discussing techniques that could be used to hack the database. Michel's example of an autonomous transaction in the password verify function is OK: it does exactly what you asked for in your original post, and no more. But many DBAs will immediately have seen how a variation could be used to hack the database, either through a SQL injection or by compromising password secrecy. Such a variation might well be illegal in some applications in some jurisdictions.
One way of explaining the issue is to talk about triggers. All triggers have dreadful security implications, because they cause events to occur that execute outside the control (or even the knowledge) of the person executing the original command.
Does that help?
|
|
|
|
Re: audit change password [message #495528 is a reply to message #495527] |
Sun, 20 February 2011 11:29 |
|
BlackSwan
Messages: 26766 Registered: January 2009 Location: SoCal
|
Senior Member |
|
|
>But Someone have to know about harmful transactions.....(autonomous) Then he can develop best solution for that...
Solution is simply, an actual code review before every procedure is released into Production
You can not automate Best Practices which are procedural in nature.
|
|
|