[RESOLVED] Making the password invisible to the eyes.

[abhijit]

I have an application which uses ADO to connect to the database.
The architecture is something like this.
The application uses a generic user name / password to connect to a database.
Then it gets the logged in users' NT ID using an API call and calls a function in Oracle.
This function basically looks up a table, finds the corresponding record for the user and reads the passowrd field.

The table has a three columns.

NTID, PASSWORD, ACTIVE_FLAG

The password is encrypted before storing it in the table. The function decrypts the password.

The application uses the decrypted password and the NT ID of the user to form another connection string which it then uses to login to the application.

If I put a debug point on the connection string, I am able to get the password for the users.
I want to put an end to this. I do not want anyone to read the password in clear text.

How should I go about it?

[si_the_geek]

Unfortunately there is no way to completely eliminate the issue - as it still needs to be transmitted to the database in plain text.

As long as users can't get into the code (which they can't if your app is VB, or VBA with a project password), they wont be able to get it that way.

[abhijit]

None of the users can get into the code, but that still lets the developers see the user's passwords which is something not desirable from a SoX point of view.

[si_the_geek]

SoX should restrict which developers can see the code in the first place... and in terms of seeing the password etc, wouldn't they have to log in as that user first anyway?


Anyhoo.. if they have access to the connection object, they will be able to see the connection string. The only alternative is to hide it within a DLL/ActiveX Exe, and provide methods to perform all of the operations that are required (whilst not providing access to the connection string, or other data you want to hide).

[abhijit]

SoX should restrict which developers can see the code in the first place... and in terms of seeing the password etc, wouldn't they have to log in as that user first anyway?


Anyhoo.. if they have access to the connection object, they will be able to see the connection string. The only alternative is to hide it within a DLL/ActiveX Exe, and provide methods to perform all of the operations that are required (whilst not providing access to the connection string, or other data you want to hide).

I think that is a good and simple idea. The connection object could be hidden inside a DLL. So developers can debug and then they cannot see the password. They could always spoof the user login, by putting a breakpoint on the GetUserName API and substitute the original user name with another NT ID. :-)