Well,

This is what I thought too, but thanks for the confirmation. It'll be a pain in the ass to write this, but there seems to be no other way.

Could you tell me why using the SYSDBA user is a bad idea? I have one central database, and I see no reason to create another user with the same rights...

----- Original Message -----
From: Kjell Rilbe
To: firebird-support@yahoogroups.com
Sent: Monday, November 10, 2008 9:18 AM
Subject: Re: [firebird-support] Avoiding hard-coding db pass in app - without using db users


Zd wrote:

> 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?

Someone mentioned a 3-tier approach, which I suppose is not viable for
you at this time.

But perhaps you could just create a simple authentication service? A
small application that sits on the server, that your application
connects to with the normal user credentials. This application has a
separate user account, unknown outside the physical server, that has
exactly the grants required to verify the credentials passed to it, and
if successful returns the "master user" password. (This "master user"
should, as already pointed out, be a different user than sysdba, if
possible.) The communication between application and authentication
service as well as between application and DB server should be
encrypted, of course.

Personally, I can't see any other way.

Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64





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