Why not store the password in an encrypted format in the db? If the
inputted user password matches the stored user password (or encrypt it
and compare) then pull encrypted password and decrypt it (client or
server side) and use it to login as SYSDBA (not a good idea).

-steve

Zd wrote:

>
> 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
> <mailto:firebird-support%40yahoogroups.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]
>
>

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.