and when your hacker has the SECUSER password, do you think he will stop
there thinking "what a mess, a limited account!!!" and not try something
like EXECUTE PROCEDURE (or select from procedure if you want) ???
and so retreive the SYSDBALIKE password (and now the login)...

I continue, if hardcoding the SECUSER password seems enough, why not
SYSDBALIKE one ? or, if you prefer, if hardcondig SYSDBALIKE password is
not enough how could it be secure for SECUSER one which permit to get
SYSDBALIKE one ?

Thierry

Zd a écrit :

>
> You make a good point here.
> By returning not only the password but the name of the user as well,
> we can prevent brute force attacks against SYSDBALIKE user!
>
> This is even more secure :-)
>
> So the only information the hacker can get from the app's code is the
> SECUSER name/pw (which is limited to executing the get_db_password
> stored procedure) and nothing else!
>
> ----- Original Message -----
> From: Steve Wiser
> To: firebird-support@yahoogroups.com
> <mailto:firebird-support%40yahoogroups.com>
> Sent: Tuesday, November 11, 2008 3:15 PM
> Subject: Re: [firebird-support] Guys! I got it! - Re: Avoiding
> hard-coding db pass in app - without using db users
>
> 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>
> > <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>
> > <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.
>
> [Non-text portions of this message have been removed]
>
>