Subject | Avoiding hard-coding db pass in app - without using db users |
---|---|
Author | Zd |
Post date | 2008-11-10T07:53:31Z |
Dear Group,
I asked this question a while back and now it turns out the answer I got might not be usable.
Here is the situation:
My application has to connect to the database through one universal user. Having multiple DB users for each user is not an option for now.
I do not want to encode the DB password in my application in any way because a talented hacker can easily extract that, no matter what encryption I use.
The solution suggested before was that the application should have a restricted user / pass combo encoded which should be used only to get the full password over a secure network. There should be a stored procedure which authenticates the user (using data from a separate users table) then returns the full DB password if the user/pass supplied is valid.
But since you can't hide the procedure's code, I don't know how to go about this.
Any ideas on how to make this strategy work, or any other ideas?
Thanks,
Zd
[Non-text portions of this message have been removed]
I asked this question a while back and now it turns out the answer I got might not be usable.
Here is the situation:
My application has to connect to the database through one universal user. Having multiple DB users for each user is not an option for now.
I do not want to encode the DB password in my application in any way because a talented hacker can easily extract that, no matter what encryption I use.
The solution suggested before was that the application should have a restricted user / pass combo encoded which should be used only to get the full password over a secure network. There should be a stored procedure which authenticates the user (using data from a separate users table) then returns the full DB password if the user/pass supplied is valid.
But since you can't hide the procedure's code, I don't know how to go about this.
Any ideas on how to make this strategy work, or any other ideas?
Thanks,
Zd
[Non-text portions of this message have been removed]