Board index » delphi » User authentication in Client/Server environment

User authentication in Client/Server environment

Our current Client/Server application logs in to the SQL database using
hardcoded username/password without asking the user about any logon
information.
Client wants to change this and add some means of authentication.
I know there are at least two ways to do so:
1. have a user table with username/password info inside the database,
   login as usual (automatically) to the SQL server, ask user to enter
his/her
   username/password, verify this and on success let the user work with the
application.
2. Before logging into the SQL server ask the user about his/her
username/password
    and use this info to actually log into the SQL server.

#2 looks more secure because there is no hardcoded user info in the
executable file,
but it may be not as convenient on the database maintenance side.

What is the common practice to authenticate the user in Client/Server
environment?
Other suggestions?

Thanks.

 

Re:User authentication in Client/Server environment


I've seen people use #1 in a AS/400 environment, ostensibly to make login
management "easier." It wasn't. Go with #2.

My $.02

Re:User authentication in Client/Server environment


How can I not see my own message but can see replies to it ???????????
Thanks.

"Justin Pitts" <jay pee eye tee tee ess at cee en stores dot com> wrote in
message news:39c11707$1_2@dnews...

Quote
> I've seen people use #1 in a AS/400 environment, ostensibly to make login
> management "easier." It wasn't. Go with #2.

> My $.02

Re:User authentication in Client/Server environment


make sure you are posting to newsgroups.borland.com

Re:User authentication in Client/Server environment


Go with #2.

John PIerce

Re:User authentication in Client/Server environment


However, I am having an issue here:

I am trying to build a 3  tier application using midas and http with SQL
serevr 7.0 as back end.
My app server is MultiInstance hence I have to set the "HandleShared"
property on the TDatabase to True. This means, if one user logs on
successfully then any users connecting through that app server can login
even if the login password is worng. I am not sure if I am missing
something. But because of this I am planning to use the #1 method and when
the app server is started it does the actual database login only once.

Any suggestions on how to implment #2.

Thanks,
Vikram

"Justin Pitts" <jay pee eye tee tee ess at cee en stores dot com> wrote in
message news:39c11707$1_2@dnews...

Quote
> I've seen people use #1 in a AS/400 environment, ostensibly to make login
> management "easier." It wasn't. Go with #2.

> My $.02

Re:User authentication in Client/Server environment


We use the #1 implementation because you don't have to deal with
dbusers (create, give permissions, change), you don't have trouble
when you change the db etc.
It's very easy to develop (you just have to encrypt/decrypt the
password).
HTH,
Rocco Barbaresco:

Herrare Humanum Est,
Perseverare Ovest ....
(By Fichi D'India)

Re:User authentication in Client/Server environment


Quote
> #2 looks more secure because there is no hardcoded user info in the
> executable file,
> but it may be not as convenient on the database maintenance side.

#2 is NOT more secure, unless you enforce strict and drastic password rules
and make sure nobody ever writes a password anywhere (see FDA's 21 CFR 11,
it describes how to have "secure" password based security, hint : you can't
comply to 21 CFR 11 with integrated database security).

We are using #1 and managing client access rights with out own structures,
we had to resort to this because #2 wasn't secure nor fine enough for us.
This opens up your db to direct queries though, and you have to secure the
data through other means.
Anyway, passwords should NEVER be used as the sole way to secure any data,
they are the easiest security measure to break through.

Eric Grange

Re:User authentication in Client/Server environment


Go with #2. In maintenance case, try to add users to a role. Then you should
only give permissions to this role and its members will automatically be
granted with the same permissions.

Quote
Nikolay Karasev <nkara...@e-dn.com> wrote in message

news:39c1163b_1@dnews...
Quote

> Our current Client/Server application logs in to the SQL database using
> hardcoded username/password without asking the user about any logon
> information.
> Client wants to change this and add some means of authentication.
> I know there are at least two ways to do so:
> 1. have a user table with username/password info inside the database,
>    login as usual (automatically) to the SQL server, ask user to enter
> his/her
>    username/password, verify this and on success let the user work with
the
> application.
> 2. Before logging into the SQL server ask the user about his/her
> username/password
>     and use this info to actually log into the SQL server.

> #2 looks more secure because there is no hardcoded user info in the
> executable file,
> but it may be not as convenient on the database maintenance side.

> What is the common practice to authenticate the user in Client/Server
> environment?
> Other suggestions?

> Thanks.

Re:User authentication in Client/Server environment


Hi:  You might want to take a look at the Basic Authorization code on the
http://www.matlus.com site.  He has also a number of good articles regarding
passwords and security, etc.  Also, his code and sample programs are darned
good.

Joe Krusick

Quote
Nikolay Karasev wrote:
> Our current Client/Server application logs in to the SQL database using
> hardcoded username/password without asking the user about any logon
> information.
> Client wants to change this and add some means of authentication.
> I know there are at least two ways to do so:
> 1. have a user table with username/password info inside the database,
>    login as usual (automatically) to the SQL server, ask user to enter
> his/her
>    username/password, verify this and on success let the user work with the
> application.
> 2. Before logging into the SQL server ask the user about his/her
> username/password
>     and use this info to actually log into the SQL server.

> #2 looks more secure because there is no hardcoded user info in the
> executable file,
> but it may be not as convenient on the database maintenance side.

> What is the common practice to authenticate the user in Client/Server
> environment?
> Other suggestions?

> Thanks.

Re:User authentication in Client/Server environment


Quote
Murat Okay wrote:
> Go with #2. In maintenance case, try to add users to a role. Then you should
> only give permissions to this role and its members will automatically be
> granted with the same permissions.

While I agree with you, there are certain permissions in Oracle that cannot be
effectively granted to roles, so this is a complicating factor.

John Pierce

Re:User authentication in Client/Server environment


I've used both methods and they each have their strengths.

Method 1 - I can grant access to the user through the app, but never
actually grant that user access to the database (unless I grant read-only
access for report development.)  This means that the somewhat rare user who
thinks they know more than they really do CAN'T get into the data through a
direct login to various database tools and mess up the data (yes,
unfortunately, I've had this happen!).  However, it also means that I had to
write various audit functions to track what users were doing - since the app
logged in to the database itself with the same id and password for each
user, I couldn't use the audit and tracking tools available in the database.

Method 2 - We do this in the app I'm currently working on.  There is an
Oracle script that runs through the user table every hour to see if there
are new users and then creates the user and grants the access rights.
However, to avoid the problem noted above, we add a "magic key" to the
password in both the script and behind the scenes when the user logs in to
the app.  The users don't know what this key is and it makes it so that they
can't log in to the database and play with the data outside of our app.  We
are also able to use the database's internal activity tracking tools to see
what users are doing.

-Dell

Quote
"Nikolay Karasev" <nkara...@e-dn.com> wrote in message

news:39c1163b_1@dnews...
Quote

> Our current Client/Server application logs in to the SQL database using
> hardcoded username/password without asking the user about any logon
> information.
> Client wants to change this and add some means of authentication.
> I know there are at least two ways to do so:
> 1. have a user table with username/password info inside the database,
>    login as usual (automatically) to the SQL server, ask user to enter
> his/her
>    username/password, verify this and on success let the user work with
the
> application.
> 2. Before logging into the SQL server ask the user about his/her
> username/password
>     and use this info to actually log into the SQL server.

> #2 looks more secure because there is no hardcoded user info in the
> executable file,
> but it may be not as convenient on the database maintenance side.

> What is the common practice to authenticate the user in Client/Server
> environment?
> Other suggestions?

> Thanks.

Re:User authentication in Client/Server environment


You could always pickup the login name from the operating system, assume
that if the user got past the login/password to enter the system in the
first place the user has been authenticated, and set permissions in the
database (preferable) or in the client application.

Juan

Quote
Nikolay Karasev wrote:

> Our current Client/Server application logs in to the SQL database using
> hardcoded username/password without asking the user about any logon
> information.
> Client wants to change this and add some means of authentication.
> I know there are at least two ways to do so:
> 1. have a user table with username/password info inside the database,
>    login as usual (automatically) to the SQL server, ask user to enter
> his/her
>    username/password, verify this and on success let the user work with the
> application.
> 2. Before logging into the SQL server ask the user about his/her
> username/password
>     and use this info to actually log into the SQL server.

> #2 looks more secure because there is no hardcoded user info in the
> executable file,
> but it may be not as convenient on the database maintenance side.

> What is the common practice to authenticate the user in Client/Server
> environment?
> Other suggestions?

> Thanks.

Re:User authentication in Client/Server environment


Quote
> You could always pickup the login name from the operating system, assume
> that if the user got past the login/password to enter the system in the
> first place the user has been authenticated, and set permissions in the
> database (preferable) or in the client application.

Win9x does NOT check passwords.
You can assume the authentication was done properly only when using a
*well managed* NT security with detailed accounts, and permission
must be granted on a user per server basis...

Re:User authentication in Client/Server environment


Quote
Eric Grange wrote:

> Win9x does NOT check passwords.

Of course not, but then again if the app is run on a standalone Win9x
box then what's the point in doing any security? To get into a network
you have to have a user id and password, though, and that IS checked.

Juan

Other Threads