Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Applet Authentication

Reply
Thread Tools

Applet Authentication

 
 
Roedy Green
Guest
Posts: n/a
 
      01-08-2006
I think about this problem periodically and then throw my arms in the
air that it is impossible. Yet perhaps perfection is not needed, any
more than you don't need a perfect lock on your front door to deter
most thieves.

What I am looking for is a scheme for Applet Authentication -- I want
assurance nobody has tampered with the code that is talking to my
server. I don't mean validate the user, I mean validate the code.

You may say, don't sweat it, just validate messages at the server.
This is not enough. Why?

1. The Applets/JAWS apps might be playing a game where they interact
directly with other players. You want to prevent people from
cheating.

2. The Applets/JAWS apps might be doing a BitTorrent like download
where they must co-operate with each other. You want to prevent fake
Applets that take but don't give.

What possible tools come to mind?

1. jar signing. This seems to be designed only to protect the end
user. I know of no way for the server to find out if the code running
was signed by the appropriate party, even when the server knows the
private key. The problem here is the hacker has the legit code, so
can compute any checksum desired on demand.

2. snap inspection. The code downloads a byte array with a custom
classloader and runs the code and returns a response within a time
limit. Since the hacker has no advance knowledge of the code, it is
difficult for him to prepare. Even if he hands it to a legit copy to
compute, that legit copy likely won't have the expected internal
state. If the code fails inspection the userid/password/logon cert is
invalidated.

3. leave out some crucial modules and download the version of the day
each time. You change the protocol daily.

I wondered if anyone has some ideas, especially ones that could be
encapsulated and plopped into any app.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
Reply With Quote
 
 
 
 
Chris Smith
Guest
Posts: n/a
 
      01-09-2006
Roedy Green <(E-Mail Removed) > wrote:
> I think about this problem periodically and then throw my arms in the
> air that it is impossible.


It is indeed impossible, in the sense that it can't be solved in a
strongly cryptographically verifiable way, without running the sensitive
code on the server.

Your best idea is probably to change the code over time. Of course,
there's a trade-off between how many and how fundamental the changes you
make, and how difficult that makes it to maintain your own code. Every
single step you take to make maintenance easier (for example, moving a
cryptographic key to a resource instead of embedding it into multiple
steps spread throughout your source code) makes it easier to break.

You could join Microsoft and others' "trusted computing" initiative that
would make this truly possible, but then we remaining sane people would
have to shoot you.

I realize this isn't a good enough answer for everyone, but I'd just get
out of any business that required this of me.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
 
 
 
Oliver Wong
Guest
Posts: n/a
 
      01-11-2006

"Roedy Green" <(E-Mail Removed) > wrote in
message news:(E-Mail Removed)...
>
> What I am looking for is a scheme for Applet Authentication -- I want
> assurance nobody has tampered with the code that is talking to my
> server. I don't mean validate the user, I mean validate the code.
>
> You may say, don't sweat it, just validate messages at the server.
> This is not enough. Why?
>

[...]
>
> 2. The Applets/JAWS apps might be doing a BitTorrent like download
> where they must co-operate with each other. You want to prevent fake
> Applets that take but don't give.
>


Like Chris said, I can't think of a simple yet secure solution to the
problem. I just wanted to point out in the case of BitTorrent, protection is
built into the protocol itself. Note how BitTorrent "works", even though the
protocol is completely open, and anyone is free to implement clients with
any behaviour they want.

Greatly simplified, clients do not give (or tend to give less) with
peers that don't give back. Of course, there has to be some initial "free
giving", or else people just starting to download (with zero bytes to share)
will never actually get anything. This is basically the Prisoner's Dilema
problem.

- Oliver


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
struts/jsp/applet: sessionid doesn't work in applet for macs only Blah Blah Java 0 08-13-2003 02:51 AM
Cool Applet Cool Applet http://24.60.235.213/Grid/ Alisher Fatykhov Java 1 08-06-2003 04:32 AM
Re: newbie: Join JApplet & Applet in one applet Andrew Thompson Java 0 08-05-2003 01:41 PM
Re: play wave files using java.applet.Applet webster Java 0 07-20-2003 01:51 PM
applet vs. canvas in applet Rob Love Java 1 07-07-2003 10:07 PM



Advertisments