authenticating high scores sent from a Java applet

Depends on the way you send the data. If you send it in a package, you can also add another field containing a variable that it came from the applet. Next to that you can also use an algorithm to make the data unreadable. Hackers can always crack it, for example by grabbing the data being sent and copying it, and then adjusting it. They will also need to know what the package looks like, but that's easily cracked. It's really hard to make something that is truly valid...

Regards,
CJ

CJ S: I already have some encryption to prevent simple cracking, but need a foolproof solution.  I really doubt that there is one, but if anybody's tellin' then i'm listening.  Thanks anyhow

There is no such thing as a fool proof encryption scheme. You just have to balance the amount of time you are willing to spend implementing a scheme with the time someone would be willing to spend trying to crack your scheme.

Zaphod.

There is no foolproof scheme as indicated by Z_Beeblebrox. Especially not because the packages you are sending can easily be grabbed and ripped apart. Those packages can then be rebuilt by the user, and send it each and every time.

Regards,
CJ

Okay then, what's the best method for ensuring that nobody monkeys around with the high scores?

Checking the referrer on the server, you should check where the data came from. What kind of server application do you use?

I just use an ASP script.  The java applet communicates via http requests.

Okay, you can check some of the server variables...for example the url the request came from:

Request.ServerVariables("URL")


here's a full list of servervariables:
ALL_HTTP All HTTP headers sent by the client.
ALL_RAW Retrieves all headers in the raw-form. The difference between ALL_RAW and ALL_HTTP is that ALL_HTTP places an HTTP_ prefix before the header name and the header-name is always capitalized. In ALL_RAW the header name and values appear as they are sent by the client.  
APPL_MD_PATH Retrieves the metabase path for the (WAM) Application for the ISAPI DLL.
APPL_PHYSICAL_PATH Retrieves the physical path corresponding to the metabase path. IIS converts the APPL_MD_PATH to the physical (directory) path to return this value.
AUTH_PASSWORD The value entered in the client's authentication dialog. This variable is only available if Basic authentication is used.  
AUTH_TYPE The authentication method that the server uses to validate users when they attempt to access a protected script.
AUTH_USER Raw authenticated user name.  
CERT_COOKIE Unique ID for client certificate, Returned as a string. Can be used as a signature for the whole client certificate.
CERT_FLAGS bit0 is set to 1 if the client certificate is present.
bit1 is set to 1 if the Certifying Authority of the client certificate is invalid (not in the list of recognized CA on the server).
 
CERT_ISSUER Issuer field of the client certificate (O=MS, OU=IAS, CN=user name, C=USA).
CERT_KEYSIZE Number of bits in Secure Sockets Layer connection key size. For example, 128.
CERT_SECRETKEYSIZE Number of bits in server certificate private key. For example, e.g. 1024.
CERT_SERIALNUMBER Serial number field of the client certificate.
CERT_SERVER_ISSUER Issuer field of the server certificate.
CERT_SERVER_SUBJECT Subject field of the server certificate.
CERT_SUBJECT Subject field of the client certificate.
CONTENT_LENGTH The length of the content as given by the client.  
CONTENT_TYPE The data type of the content. Used with queries that have attached information, such as the HTTP queries GET, POST, and PUT.
GATEWAY_INTERFACE The revision of the CGI specification used by the server. The format is CGI/revision.  
HTTP_<HeaderName> The value stored in the header HeaderName. Any header other than those listed in this table must be prefixed by HTTP_ in order for the ServerVariables collection to retrieve its value.
Note  The server interprets any underscore (_) characters in HeaderName as dashes in the actual header. For example if you specify HTTP_MY_HEADER, the server searches for a header sent as MY-HEADER.
 
HTTPS Returns ON if the request came in through secure channel (SSL) or it returns OFF if the request is for a non-secure channel.
HTTPS_KEYSIZE Number of bits in Secure Sockets Layer connection key size. For example, 128.
HTTPS_SECRETKEYSIZE Number of bits in server certificate private key. For example, 1024.
HTTPS_SERVER_ISSUER Issuer field of the server certificate.
HTTPS_SERVER_SUBJECT Subject field of the server certificate.
INSTANCE_ID The ID for the IIS instance in textual format. If the instance ID is 1, it appears as a string. You can use this variable to retrieve the ID of the Web-server instance (in the metabase) to which the request belongs.
INSTANCE_META_PATH The metabase path for the instance of IIS that responds to the request.
LOCAL_ADDR Returns the Server Address on which the request came in. This is important on multi-homed machines where there can be multiple IP addresses bound to a machine and you want to find out which address the request used.
LOGON_USER The Windows NT? account that the user is logged into.
PATH_INFO Extra path information as given by the client. You can access scripts by using their virtual path and the PATH_INFO server variable. If this information comes from a URL, it is decoded by the server before it is passed to the CGI script.
PATH_TRANSLATED A translated version of PATH_INFO that takes the path and performs any necessary virtual-to-physical mapping.
QUERY_STRING Query information stored in the string following the question mark (?) in the HTTP request.  
REMOTE_ADDR The IP address of the remote host making the request.  
REMOTE_HOST The name of the host making the request. If the server does not have this information, it will set REMOTE_ADDR and leave this empty.
REMOTE_USER Unmapped user-name string sent in by the User. This is the name that is really sent by the user as opposed to the ones that are modified by any authentication filter installed on the server.
REQUEST_METHOD The method used to make the request. For HTTP, this is GET, HEAD, POST, and so on.
SCRIPT_NAME A virtual path to the script being executed. This is used for self-referencing URLs.
SERVER_NAME The server's host name, DNS alias, or IP address as it would appear in self-referencing URLs.
SERVER_PORT The port number to which the request was sent.
SERVER_PORT_SECURE A string that contains either 0 or 1. If the request is being handled on the secure port, then this will be 1. Otherwise, it will be 0.
SERVER_PROTOCOL The name and revision of the request information protocol. The format is protocol/revision.
SERVER_SOFTWARE The name and version of the server software that answers the request and runs the gateway. The format is name/version.
URL  Gives the base portion of the URL.

> "but need a foolproof solution"

then why?:

> "in order to upload and download high scores."

I understand download "the latest"

I have no clue why anyone would want all clients to perform uploads of information about everybody.

I suggest dumping the upload piece, and use a different process for providing such function (alternative upload, ftp, server-side code (that can be triggered by an event, perhaps from within the applet)) - anything on client is all too hackable.

done?

Well, everybody has to update their highscore.  I can't think of any other way.

Well, scoring managed server side.
How many people per update?
Perhaps some simple mechanism where you only have to ensure one person only gets score updated, and cannot update another. Use of keys, passwords can help control.

Also convoluted scoring mechanism (hard to replicate - which increases level of difficulty in manipulating)

If audience high enough, knock off the ones who try to cheat, with appropriate warnings.  Anything on client has to be considered compromised.

Depending on nature of game, can it be run offline from web/phone/server, it should have as few pieces on client as possible. It should do stuff, then check in with server before doing more. Server tracks progress and checks for cheating.

I'm not sure if any of the above apply, so I'll enlarge on the problem.

The game is a java applet.  Upon finishing a game, the user uploads a highscore and initials.  I just want to help make sure that nobody can just decide to upload an invalid score.

sorry for the confusion (&thanks for the help)