Subject Re: [firebird-support] Avoiding hard-coding db pass in app - without using db users
Author Alan.Davies@aldis-systems.co.uk
>>
>> 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?
>

To hide source of procedures, do this: (make sure you have a copy first...)

UPDATE rdb$procedures
SET rdb$procedure_source = NULL
WHERE ((rdb$system_flag = 0) OR (rdb$system_flag IS NULL))

--
Alan J Davies
Aldis


Quoting Kjell Rilbe <kjell.rilbe@...>:

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