Re: embedded passwords

To Daniel's excellent answer I would add the following suggestions.

You say that the reason for wanting to assign and expire passwords etc is part of an anti-fraud initiative. If this is the case then presumably it is sanctioned by the management of the business. They should be told that the design of the applications is inherently insecure and that they should consider a rewrite. I guess at that point they will have to assess the cost of the fraud against the cost of the systems rewrite.

It certainly may be possible to remove the embedded id's and rely on Oracle authentication but this would need a look at the code and application design.

--
Niall Litchfield
Oracle DBA
Audit Commission UK

"Daniel A. Morgan" <dmorgan_at_exesolutions.com> wrote in message
news:3AAF0D59.148C3E68_at_exesolutions.com...


> > We are looking to reduce internal credit card fraud in our company by

> > setting up user security in Oracle so that everyone has their own unique

 ID


> > and password and so that passwords expire every 90 days.

> >

> > The problem: We have many applications that were created in-house that

> > contain embedded ID's and passwords so I was told we can't change ID's

 and


> > passwords in Oracle. My questions are:

> >

> > - What are other people doing out there in a case like this? Is there

 any


> > way to take the embedded ID's and passwords out of the applications and

> > still have them function correctly?

> > - Or can we leave an ID embedded in an application without embedding the

> > password so the user using the app will be prompted for a password each

 time


> > they use the app? This way we could set expiring passwords, lockout

 settings


> > etc.

>

> Embedded IDs are antithetical to database security. It is hard to have

 both at


> the same time. But the easy answer is to create PROFILES for different

 classes


> of users. For example you might have

>

> 1. System Administrators

> 2. Embedded Applications

> 3. Web Users

> 4. ODBC Users

> 5. Everyone else

>

> Create a role for each with different system privileges. Then to each role

> assign a profile. The profile for the embedded applications might have

 passwords


> that never expire whereas the other profiles expire passwords. This method

 would


> also allow you to modify an entire class of users with a single change to

 their


> common profile.

>

> Daniel A. Morgan

>