focuskarsites.net
Date: Sat Oct 30 2004 - 04:12:40 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Tim, everyone.

Interesting problem.

I suppose you could send a password with the encrypted data,
from your client to the server.

On receiving the data from the client, check the validity of
the password at the server end.

If the password check fails, then assume that the data may
have become corrupted as well.

Or you could also use various forms of 'proprietory dynamic
encryption', and send an 'encryption method key' with the
data, to tell the server which decryption method to use, on
receipt of the data. You are not actually sending the
encryption/decryption key itself, but a hint to the server
as to which methods (there could be several proprietory
methods) need to be used to decrypt the data).

An encryption key could be anything you want to use really.

For each field in the input data, a unique code number could
be used, stored on the server side, to identify the
decryption method required.

The Java applet could randomly choose from a pre-defined
list, which encryption method it uses for each field at the
client end, and build the appropriate 5-part encryption key
to send to the server.

Eg. if there are five input fields, then the encryption key
might be something like this:

De25hM:yTm90:A3GhpWm:Kx48qBz:Sn7U9vI

When the server receives the above key, it should be able to
parse the string into 5 seperate sub-keys, one for each
field, then apply the different server decryption methods
for each input field, and it's client-sided encrypted data.

HTH - Keith Roberts

Have you considered using VPN between the client and
server, if this is going via the internet?

http://www.karsites.net/

On Fri, 29 Oct 2004, Tim James wrote:

> To: webappsecsecurityfocus.com
> From: Tim James <jimtamesyahoo.com>
> Subject: advice needed - secure transfer of client details
>
> Hi all,
>
> This is a brain teaser. I have an application to
> review which supplies details from the client's
> workstation (derived from files on disk, hostname, IP
> address). It currently implements a Java applet whose
> job is to obtain these details and send them up to the
> server in an ordinary HTTP POST.
>
> This sends alarm bells ringing for me. I have
> developed a simple attack whereby I can replace the
> applet at will with my own code, which can send
> different details for workstation ID, hostname, IP
> address. This falsifies the audit trail from this
> point on and the server is none the wiser.
>
> So, the general problem is this :-
>
> How can a client communicate details that are only
> known to the client, up to a server, in a way that
> cannot be tampered with ? Why should a server trust
> the supplied values ? The data for the workstation
> next to me is known by everyone - why can't I create
> an applet to reproduce those details, and hence
> impersonate that workstation ?
>
> I have some ideas but none are totally satisfactory.
>
> 1) Encrypt the data
> This shifts the problem to one of key management.
> 2) Checksum the applet
> 3) Keep the details on the server in the first place
> and supply some token from the client which cannot be
> impersonated
>
> I would *really* appreciate a different perspective on
> this problem because I'm kind of stalled.....
>
> Thanks a lot
>
> Tim
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]