TOracleLogon and password

[Geoff Dunmore]

Good Day All:

I am researching a request from a client that wants database users defined, but does not want them to be able to use Oracle tools such as sqlPlus to connect to the database from outside the application environment.

One possible solution is to give the users a password to enter, then intercept the entered password and apply some kind of hash, encryption, bitwise XOR, or other manipulation that alters the password in exactly the same manner each time, and then passing this on through the application.

The user then has a password that is not able to be used to connect to the database via the standard tools.

This involves intercepting the password in the TOracleLogon and manipulating it before passing it on. Where would I hook the code to do this?

One other problem with this solution. Does anyone know how to access the stored passwords in the database so that they can be converted?

 

[Marco Kalter]

A common solution for such a security requirement is provided by password protected roles. The only default privileges you grant your users is the "create session" privilege, so that they can do literally nothing in SQL*Plus or other tools. All other privileges are granted through a role that is protected by a password that is only known to the application (or stored in the database in an encrypted form). This role is not enabled by default, and requires a password to enable it.

See also this topic .

 

[Geoff Dunmore]

Thanks Marco:

Unfortuantely, that solution still leaves me with having to embed a password for each role that is defined in the database that my users need access to. Currently, there are 18 various roles that allow users different access to different data.

Adding a new role or changing a role-based password would require a recompile and redeployment of the executable.

I would rather try the password manipulation route.

Any suggestions for where I might insert my hook for the manipulation routine?

 

[Marco Kalter]

You only need one password, and even if more passwords are required, you could implement a generic solution with a table with encrypted role passwords.

Nevertheless, your solution will also work, but requires that you write your own logon dialog to take care of the decryption. You could also purchase the source code and directly implement the decryption in the TOracleLogon form. There is unfortunately no hook for this.