Securing client/server communication

**Sjoerd** · Aug 12 '08, 12:35 PM

Re: Securing client/server communication

On Aug 12, 2:10 pm, AeonOfTime <s.mordz...@gma il.comwrote:

How would you go about securing the data exchanges?

You only want the client to do requests to the server. Therefore, the
client has to tell the server it is him and nobody else. This can be
done by supplying a password/cookie to the server on each request. As
long as nobody else knows the password, you're save.

Furthermore, you should not send the password plain-text over the
internet. You could use HTTPS or send a hash (MD5, SHA1) of the
password instead.

**AeonOfTime** · Aug 12 '08, 12:45 PM

Re: Securing client/server communication

On Aug 12, 2:27 pm, Sjoerd <sjoer...@gmail .comwrote:

On Aug 12, 2:10 pm, AeonOfTime <s.mordz...@gma il.comwrote:
>

How would you go about securing the data exchanges?

>
You only want the client to do requests to the server. Therefore, the
client has to tell the server it is him and nobody else. This can be
done by supplying a password/cookie to the server on each request. As
long as nobody else knows the password, you're save.
>
Furthermore, you should not send the password plain-text over the
internet. You could use HTTPS or send a hash (MD5, SHA1) of the
password instead.

Hi Sjoerd, that makes sense - thanks a bundle. If I make sure the
client identifies itself, it can simply provide a user ID to access
that user's specific data - I don't need more than that. I always try
to keep it simple, but sometimes I get tangled up in details :|

**Jerry Stuckle** · Aug 12 '08, 01:15 PM

Re: Securing client/server communication

AeonOfTime wrote:

Let's assume a web application (in this case a browser-based game)
with a custom HTTP server built on PHP, and a client also built on
PHP. The client uses the server to access and change data. Even if the
client server communication is not directly visible to the user (who
logs into the client), the fact that the server is publicly accessible
(a port sniffer would be enough to find it) means the communication
has to be secured.
>

First of all, clients are not normally built on PHP. Client systems
generally don't have PHP installed. Additionally, if they do use PHP as
a client app, they won't be able to use the browser for a GUI. They'll
either be restricted to CLI or you'll have to have them install a PHP
GUI, also.

How would you go about securing the data exchanges?
>

Secure data transfer is typically performed with SSL. But my question
is - what is being transferred that you need SSL? Is there anything
potentially harmful if leaked, like credit card numbers or other
personal data? And even if someone does intercept a game move
(unlikely, but possible), what real harm will it do?

I am thinking of using unique tokens that are given to each client and
which have to be provided in the data sets, and which would only be
valid for a given amount of time before they have to be renewed. I am
a bit confused though, as I have the user authentication on the
clientside (via sessions) and the communication with the server which
happens in the background. Can I use the same session maybe, or does
that open new vulnerabilities ?
>

If you have sessions on the client side, then not only are you requiring
the user to install PHP, but a web server on their client. Even fewer
are going to do this.

Thanks in advance for any input you may have.
>
>

Sounds like the wrong approach to me. If you really need a client side
app, you should be using a Java applet, not PHP. Java is installed on
many (most?) systems, it has a GUI, and can easily use it's own
communications mechanism between the client and server.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

**AeonOfTime** · Aug 12 '08, 02:05 PM

Re: Securing client/server communication

On Aug 12, 3:02 pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:

AeonOfTime wrote:

Let's assume a web application (in this case a browser-based game)
with a custom HTTP server built on PHP, and a client also built on
PHP. The client uses the server to access and change data. Even if the
client server communication is not directly visible to the user (who
logs into the client), the fact that the server is publicly accessible
(a port sniffer would be enough to find it) means the communication
has to be secured.

>
First of all, clients are not normally built on PHP. Client systems
generally don't have PHP installed. Additionally, if they do use PHP as
a client app, they won't be able to use the browser for a GUI. They'll
either be restricted to CLI or you'll have to have them install a PHP
GUI, also.

Hi jerry, I may have used the wrong terminology there. In my case, the
client is the PHP script that runs on my own server, and which
generates web pages via which users play the game. It is not a client
in the traditional sense that it runs on the user's system. Ideally I
will have one physical machine for the server that exists simply as a
central management source for game data, and several other physical
machines for rendering the game with load balancing.

Thus the only thing a user needs is a browser, and the communication
between client and server happens only between my own personal
scripts. Sorry for the confusion.

>

How would you go about securing the data exchanges?

>
Secure data transfer is typically performed with SSL. But my question
is - what is being transferred that you need SSL? Is there anything
potentially harmful if leaked, like credit card numbers or other
personal data? And even if someone does intercept a game move
(unlikely, but possible), what real harm will it do?
>

The harm lies in the fact that I plan on making the game code open
source in the future, giving players full insight in how the system
works. There is no critical data being exchanged per se, but I do not
want any data to be leaked either. I don't think I will go for an SSL
connection though, that would be overkill and slow down the
communication somewhat. I think a unique client token will be enough -
that way even if you were able to intercept something you could not do
anything with it.

>
Sounds like the wrong approach to me. If you really need a client side
app, you should be using a Java applet, not PHP. Java is installed on
many (most?) systems, it has a GUI, and can easily use it's own
communications mechanism between the client and server.

Yes, java or even flash could have been a choice for a GUI, but I
settled for plain old HTML for now with enhanced functionalities in
Flash and AJAX, it is sufficient for what I have in mind.

Thanks for the input.

**C. (http://symcbean.blogspot.com/)** · Aug 12 '08, 09:25 PM

Re: Securing client/server communication

On Aug 12, 1:10 pm, AeonOfTime <s.mordz...@gma il.comwrote:

Let's assume a web application (in this case a browser-based game)
with a custom HTTP server built on PHP, and a client also built on
PHP. The client uses the server to access and change data. Even if the
client server communication is not directly visible to the user (who
logs into the client), the fact that the server is publicly accessible
(a port sniffer would be enough to find it) means the communication
has to be secured.
>
How would you go about securing the data exchanges?
>
I am thinking of using unique tokens that are given to each client and
which have to be provided in the data sets, and which would only be
valid for a given amount of time before they have to be renewed. I am
a bit confused though, as I have the user authentication on the
clientside (via sessions) and the communication with the server which
happens in the background. Can I use the same session maybe, or does
that open new vulnerabilities ?
>
Thanks in advance for any input you may have.

HTTPS is the only sensible way to go - even if you run your own CA

C.

Securing client/server communication

Securing client/server communication

Comment

Comment

Comment

Comment

Comment