The point of SECUSER is that it is a very limited user that can only run
the login procedure. Nothing else. The login procedure simply takes in
a user name + password and if it matches what is in the database it will
return the real password to use. The app then disconnects from the
database and logs in as the real user with the real password. Using
this method the app does not need to know anything about the real user
or real password.

-steve

Zd wrote:

>
> Thierry,
>
> Secuser password is hard-coded in the app (in an encrypted form).
>
> The hacker can OF COURSE extract the SECUSER password, but since
> SYSDBA password is given back by a stored procedure, he has to know a
> valid username/password combination to get the SYSDBA password!
>
> The meaning of this mechanism is that SECUSER has only execute rights
> to the stored procedure, nothing else!
>
> Is it clear now?
>
> Regards,
> Zd
>
> ----- Original Message -----
> From: Teträm Corp
> To: firebird-support@yahoogroups.com
> <mailto:firebird-support%40yahoogroups.com>
> Sent: Tuesday, November 11, 2008 12:13 PM
> Subject: Re: [firebird-support] Guys! I got it! - Re: Avoiding
> hard-coding db pass in app - without using db users
>
> you said: "As far as I can see, there are no security holes here"...
> well...
> just a question: what about SECUSER password ? How the application knows
> it ? hard coded ?
>
> I think the problem is only moved to another place: from SYSDBALIKE
> password to SECUSER password.
> if hacker can gain access to SECUSER password, it will not be difficult
> to understand how to gain access to the SYSDBALIKE password
>
> unless the user of the application should have enter two passwords:
> SECUSER one and its account one (and assuming the hacker doesn't sniff
> key strokes :-) )
>
> sorry if the point has been discussed but it miss in your summary ;-)
>
> Thierry
>
> Kjell Rilbe a écrit :
> >
> > This whole thread seems rather confusing now - a lot of replies to
> > various subthreads discussing only parts of the problem at a time. SO,
> > I'll try to summarize my take on it, as a rather unexperienced FB user
> > as well as a novice on security, but with a good thinking brain. :-)
> > Please point out any holes in my reasoning!
> >
> > In general we assume that the physical DB server is "secure", so that
> > the DB can only be accessed through client connections. No direct file
> > access and so forth.
> >
> > Zd wrote:
> >
> > > Database has two users:
> > > SYSDBA, and SECUSER
> >
> > Or rather MYSPECIALSYSDBA and SECUSER. Substitute SYSDBA with
> > MYSPECIALSYSDBA everywhere in the following. MYSPECIALSYSDBA has grants
> > to everything the app needs, but not to GBAK, shutdown and so forth.
> >
> > > SYSDBA's password is stored in a table called "CODETABLE".
> > > The following grants are executed using SYSDBA:
> > > GRANT EXECUTE ON PROCEDURE GET_DB_PASSWORD TO SECUSER;
> > > GRANT SELECT ON CodeTable TO PROCEDURE GET_DB_PASSWORD;
> > > GRANT SELECT ON Users TO PROCEDURE GET_DB_PASSWORD;
> >
> > Executed once locally on the physical DB server I assume.
> >
> > > As you see, SECUSER has access only to GET_DB_PASSWORD, and only the
> > > stored procedure has access to the SYSDBA password in CODETABLE!
> > >
> > > The stored procedure's code is the following:
> > >
> > > CREATE PROCEDURE GET_DB_PASSWORD(
> > > USERNAME VARCHAR(100) CHARACTER SET UTF8,
> > > "PASSWORD" VARCHAR(100) CHARACTER SET UTF8)
> > > RETURNS(
> > > DB_PASSWORD VARCHAR(8) CHARACTER SET UTF8,
> > > ISSUCCESSFUL SMALLINT)
> > > AS
> > > BEGIN
> > > IsSuccessful = 0;
> > >
> > > SELECT (SELECT CodeValue FROM CodeTable WHERE
> > > CodeName = 'DatabasePassword')
> > > FROM Users
> > > WHERE
> > > Username = :Username AND
> > > Passwd = :"PASSWORD"
> > > INTO :DB_Password;
> > >
> > > IF (ROW_COUNT = 1) THEN
> > > IsSuccessful = 1;
> > >
> > > SUSPEND;
> > > END;
> >
> > As I understand it, this procedure checks that the provided credentials
> > are valid and if so returns the MYSPECIALSYSDBA password.
> >
> > The application executes this procedure logged in as SECUSER, who only
> > has access to the procedure, and only to execute it. So, it's of no
> > importance to protect the procedure's source - a hacker can't do
> > anything with it except executing it anyway.
> >
> > Assuming the procedure is free of bugs and there's no risk of buffer
> > overflow exploits, it doesn't even really matter what grants the
> > procedure has, as long as it has those mentioned above, which are
> > required for the procedure to do its job.
> >
> > It is assumed that the client application always connects through a
> > secure tunnel, both when calling this procedure and when logging in with
> > the obtained MYSPECIALSYSDBA password. This eliminates the risk of a
> > hacker snatching the password, unless he/she has access to a client
> > application where a user has already logged on. In this case, nothing
> > can protect the database if the application has to connect with a
> > SYSDBA-like user.
> >
> > > So what do you think? I tried and it works, but any ideas whether this
> > > is a SECURE solution too?
> >
> > As far as I can see, there are no security holes here, assuming
> > potential hacker don't have access to user credentials or to an already
> > logged in application, and assuming the authorized users are not hackers
> > able of extracting the MYSPECIALSYSDBA password from the running
> > application.
> >
> > Kjell
> > --
> > --------------------------------------
> > Kjell Rilbe
> > DataDIA AB
> > E-post: kjell@... <mailto:kjell%40datadia.se>
> <mailto:kjell%40datadia.se>
> > Telefon: 08-761 06 55
> > Mobil: 0733-44 24 64
> >
> >
>
> [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.