Steve,

The stored procedure has to return the SYSDBA (or another user's with similar rights) password to the client.

The only way to do this is to have the password in the stored procedure's code. Which is obviously a no-go.

Can you please look up the following thread in the archives:
"Need security advice from the pros"

On 29th Aug 2008 you wrote in this thread:

"Since you state you have to work with sysdba in production as the db
user what about trying something like this:

1) Have client talk to the server over an ecnrypted tunnel only
2) Create a user that can only run a login stored procedure that takes
the application user and password and returns the correct sysdba password

Your app will login using the hard coded user that can only run the
login routine and the user will have to put in their correct user ID and
password. If it is good then the login procedure returns the sysdba
password to your app and you can then reconnect using the sysdba user.

-steve"

We're now talking about this solution and why this is not possible to do.

If you have any other approach based on this, please let us know!

Thanks,

Zd

----- Original Message -----
From: Steve Wiser
To: firebird-support@yahoogroups.com
Sent: Monday, November 10, 2008 2:46 PM
Subject: Re: [firebird-support] Avoiding hard-coding db pass in app - without using db users


I don't understand why them having the source code of the login
procedure is dangerous? The code should be pretty generic and is
checking their inputted password versus some password that is stored
encrypted in a table, right? As long as they cannot change it you are
ok, right?

-steve

Zd wrote:
>
> 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]
>
>

This message and any files transmitted with it may contain information that is privileged, confidential, and exempt from disclosure under applicable law. They are intended solely for the use of the intended recipient. If you are not the intended recipient, distributing, copying, disclosing, or reliance on the contents of this communication is strictly prohibited. If this has reached you in error, kindly destroy this message and notify the sender immediately. Thank you for your assistance.

Specialized Business Software attempts to sweep harmful content (e.g. viruses) from e-mail and attachments, however we cannot guarantee their safety and can accept no liability for any resulting damage. The recipient is responsible to verify the safety of this message and any attachments before accepting them.





[Non-text portions of this message have been removed]