Re: Verifying passwords have been changed in oracle

From: Mark Townsend <markbtownsend_at_attbi.com>
Date: Sun, 10 Nov 2002 16:48:44 GMT
Message-ID: <B9F1D05E.217A%markbtownsend@attbi.com>

in article s94hqa.s81.ln_at_spuddy.org, Stephen Harris at sweh_at_spuddy.mew.co.uk wrote on 11/8/02 11:46 AM:

> Ed Stevens <spamdump_at_nospam.noway.nohow> wrote:

>> How often do you have to audit to insure the sys and system passwords have
>> been
>> changed from the default?  I would think this is something you'd have to
>> check
>> exactly once.  And even if there were some fear that it might get set back to

>
> Well, this is merely one test in a suite of tests. I'm building a compliance
> checker to ensure a build matches the security base line, and one of the
> baseline tests is that the password is not a default one. Other things
> will include ensuring SCOTT account doesn't exist, for example. Another
> would be permissions on the datafiles. And so on.
>
> Initially the program will be executed on new builds to ensure they have
> been properly setup before going into production, but later there will
> be automated daily checks to verify nothing has broken.

I'm confused - you want to check to see if a default password has been used, but identified that you couldn't use the default password to check because password verification routines are in place. Doesn't the latter preclude the former ? Check that the verification routines are in place during build, and then once in production, you won't have to check again (especially as your security team are auditing connections on sys/system anyhow).

Or is there more to this story I'm not getting ?

As an aside, we are presenting next week at OracleWorld on things users have done to fill supposed gaps in the database, when they could have used one of the database features - for instance, a copmany using MQSeries to send messages between only Oracle databases. One of the classic real world examples is a company that automated password checking scripts to ensure that users didn't use obvious passwords. This thing ran continuously on over 1000 instances a day - driving systems/networks into the ground, and generating massive amounts of audit trail. A quick deployment of password verification routines solved their self imposed problems. Received on Sun Nov 10 2002 - 10:48:44 CST