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';
Cheers,
JT
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
-- Cheers, 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
-- //www.freelists.org/webpage/oracle-l
