Re: VB4 and passwords on Oracle 7 roles

In article <310FB883.C9F_at_cincom.com>, "Brian M. Biggs" <bbiggs_at_cincom.com> writes:
> We are using ODBC to interact with an MDB file that is attached to an
> Oracle database. Our application will control access to the tables
> WITHIN THE APPLICATION, but there is really nothing stopping a user from
> opening up Access and connecting directly to the MDB and viewing or
> modifying the data in the tables.
>
> I thought we could use an Oracle role with a password to control access
> to the tables. Our application would enable the role with a password,
> and the user could access the data. Then, even if the user opened the
> MDB directly, the role would not be enabled, and they wouldn't be able
> to see the tables or any data. The problem is the password for the
> role. I'd rather not embed a password in the application. We'd like to
> have the flexibility of changing the role password at any time and not
> having to visit each workstation to change their application.
>
> As a solution, what about storing the password in encrypted form in the
> Oracle database, retrieving it and decrypting it in the application, and
> then sending it back to Oracle to enable the role?

The problem here is identifying the APPLICATION rather than the user. To do this, something must be known by the application that is not known by the user. You can hardcode the password for the role, or you can hardcode the method of retrieving the password. It all amounts to the same thing. In the first case a user might find the password in the application, in the other he will find the method of retrieving the password. At least in the first case only one password will be comprimised and the fix is to change the password and redistribute the application (after figuring a better method of hiding it of course). In the second case ALL of your passwords/roles are comprimised and you need to change the application, the database (they now know where you stash your passwords), and the passwords for ALL applications.

The problem with both approaches is that it can be very difficult to hide anything in an application that the users have access to (such as in C/S).

Something that will minimize the damage is to use declarative constraints and triggers in you DB so that it won't get corrupted by someone who isn't aware of the total structure.

David Jordan
DBA
Ford Motor Company Received on Tue Feb 06 1996 - 00:00:00 CET