Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Different way of maintaining users?

Re: Different way of maintaining users?

From: John Thomas <>
Date: Sun, 16 Oct 2005 21:22:12 +0100
Message-ID: <>

One of the simplest ways of doing this is to change the user's password in the application login, so the password entered is related to, but not the same as, the user's database password.

This scheme could be as simple as:

database_password := <entered_password> || 'a';

But would usually involve scrambling or encrypting the password using a known algorithm which is also called by the application's "set password" routine.

If you use a single account, you may have difficulties with auditing. There are ways round this including identifying the proxy user if you are using the appropriate OCI calls to connect.



In message
<>, Vanessa A. Simmons <> writes
>We are considering a change to the way our users access the database
>and our applications. We would like to make sure that users are getting
>to the data through the applications only and not using external tools
>(i.e. SQL*Plus) to access the database directly with the hopes that
>this will help us to further secure our databases. In this scenario, we
>would create a high-level user which would be the data source user
>(we're using Cold Fusion for our application front-end) that would be
>able to run any query on behalf of the user "logged in" to the
>application. However, each user would not have his/her own DB account
>that requires role and password maintenance. Instead, the programmers
>would create a user and role table in the database that would hold this
>information (including encrypted passwords) so that the users do not
>have individual access to the database.  That would push a lot of the
>user maintenance that I deal with on a daily basis to either our
>programmers or a help desk technician. 

>My question is whether or not this is a sound plan and if you have any
>concerns about problems we might encounter if we decide to go this
>route? Has anyone else done something similar in their environment?
>Internal Virus Database is out-of-date.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date: 06/10/2005

John Thomas

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.1/135 - Release Date: 15/10/2005

Received on Sun Oct 16 2005 - 15:26:04 CDT

Original text of this message