Need to encrypt javascript die roller output

[googlegroups]

Hi, I'm making a javascript program for rolling dice for a roleplaying
game that's played in a forum. The die roll gets generated, gets stored
as text in a hidden form field, and then gets written to the mySQL
database upon form submission.

What I want to do is prevent cheaters from being able to create their
own die roll, and the best way I've come up with to do this is to
encrypt what gets stored in the hidden form field. However, since all
javascript code can be viewed by the user, they can see what key I'm
using.

Any suggestions on what to use as a key that a user cannot get access
to? Data hard-coded into a java applet, perhaps? Even that might be
hackable by someone a tool capable of inspecting javascript variables
at run-time.

Is it simply impossible to prevent cheating if my code is in
javascript? There must be some way to secure hidden form fields to
insure that their content is code-produced only. Is there? Or is there
some other way to make a cheater-proof javascript die roller I haven't
thought of?

[Safalra]

On 1 Jul 2006 16:00:37 -0700, go**********@he rbaloutfitters. com wrote:

Hi, I'm making a javascript program for rolling dice for a roleplaying
game that's played in a forum. The die roll gets generated, gets stored
as text in a hidden form field, and then gets written to the mySQL
database upon form submission.

What I want to do is prevent cheaters from being able to create their
own die roll, and the best way I've come up with to do this is to
encrypt what gets stored in the hidden form field. However, since all
javascript code can be viewed by the user, they can see what key I'm
using.

Any suggestions on what to use as a key that a user cannot get access
to? Data hard-coded into a java applet, perhaps? Even that might be
hackable by someone a tool capable of inspecting javascript variables
at run-time.

Any method of producing data on the client side can be hijacked; you need
to use server-side code here. If the user needs to be able to see the die
roll before submitting the form then you should generate it before
displaying the form and include it in the page (either storing the result
in the database so users can't change it, or using some one-way or
time-dependent cryptography so if they try to change it you can find out).

--
Safalra (Stephen Morley)
http://www.safalra.com/programming/javascript/

[Lasse Reichstein Nielsen]

go**********@he rbaloutfitters. com writes:

Hi, I'm making a javascript program for rolling dice for a roleplaying
game that's played in a forum. The die roll gets generated, gets stored
as text in a hidden form field, and then gets written to the mySQL
database upon form submission.

Bad choice. You are effectively making a client/server application
where the client is under the complete control of the user.
In that situation, you can not trust the client.

What I want to do is prevent cheaters from being able to create their
own die roll, and the best way I've come up with to do this is to
encrypt what gets stored in the hidden form field. However, since all
javascript code can be viewed by the user, they can see what key I'm
using.

Indeed. No matter what the browse does, the user can modify it to do
something else, like changing a call to Math.random to one always
returning 1.0.

Any suggestions on what to use as a key that a user cannot get access
to? Data hard-coded into a java applet, perhaps? Even that might be
hackable by someone a tool capable of inspecting javascript variables
at run-time.

Roll the dice on the server. It'a the only way to be sure[1]

Is it simply impossible to prevent cheating if my code is in
javascript?

Yes. More to the fact, it's impossible to prevent cheating when
the client genrates the random number directly.

You could make the client create a random number, and then offsetting
it by a number computed on the server, but then you could just
use the server generated number directly.

There must be some way to secure hidden form fields to
insure that their content is code-produced only. Is there?

There mustn't, and there isn't.
The security model of client side scripting allows full control
over the page, and even if not, any form submission can be faked
with a simple telnet connection.

Or is there some other way to make a cheater-proof javascript die
roller I haven't thought of?

Roll on the server, then send the number to the client as part of
the respons of the submission.
/L
[1] that, and nuking the site from orbit.
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Dag Sunde]

go**********@he rbaloutfitters. com wrote:

Hi, I'm making a javascript program for rolling dice for a roleplaying
game that's played in a forum. The die roll gets generated, gets
stored as text in a hidden form field, and then gets written to the
mySQL database upon form submission.

What I want to do is prevent cheaters from being able to create their
own die roll, and the best way I've come up with to do this is to
encrypt what gets stored in the hidden form field. However, since all
javascript code can be viewed by the user, they can see what key I'm
using.

Any suggestions on what to use as a key that a user cannot get access
to? Data hard-coded into a java applet, perhaps? Even that might be
hackable by someone a tool capable of inspecting javascript variables
at run-time.

Is it simply impossible to prevent cheating if my code is in
javascript? There must be some way to secure hidden form fields to
insure that their content is code-produced only. Is there? Or is there
some other way to make a cheater-proof javascript die roller I haven't
thought of?

Create a rollDice function on the server, and make an AJAX call from
the client.

The rollDice rolls and stores the value on the server in one go,
and just return the number of eyes to the client for display.

--
Dag.

[Lasse Reichstein Nielsen]

Safalra <us****@safalra .comwrites:

If the user needs to be able to see the die roll before submitting
the form then you should generate it before displaying the form and
include it in the page (either storing the result in the database so
users can't change it, or using some one-way or time-dependent
cryptography so if they try to change it you can find out).

In a game situation, knowing the number ahead of deciding your action
is also bad. If you know that you will fail your first attack roll and
succeede the second, you'll save your wastly expensive and highly
effective magical arrow for the second attack.

Make the form contain the player's decissions and the respons contain
the results. It's both safer and muxh simpler than any convoluted attempt
at making the client safe.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Arnold Shore]

Yep, here's one cheater-resistant way. The CHAP protocol uses a technique
to prevent such a man-in-the-middle attack. And using that, no, there's no
cleartext password exchanged over the wire.

Here's a cursory description of how: At each exchange, the server sends
(and remembers) a random string. The client hashes a concatenation of that
random value with the client's hashed password (cookie-stored) and sends
that. Which is compared server-side with the expected hash.

You'd use the result (hash of a hash) as the key to encrypt the die roll
info client side with some available symmetric key function (RC4 or 5, or
AES) before sending. Then, decrypt on receipt server-side.

Hash is MD5, and there's Paul Johnson's JS function available online.
Server-side, any languge processor will have an MD5 hash function available.
Poke around for the symmetric key function script for both sides.

AS
<go**********@h erbaloutfitters .comwrote in message
news:11******** *************@m 73g2000cwd.goog legroups.com...

Hi, I'm making a javascript program for rolling dice for a roleplaying
game that's played in a forum. The die roll gets generated, gets stored
as text in a hidden form field, and then gets written to the mySQL
database upon form submission.

What I want to do is prevent cheaters from being able to create their
own die roll, and the best way I've come up with to do this is to
encrypt what gets stored in the hidden form field. However, since all
javascript code can be viewed by the user, they can see what key I'm
using.

Any suggestions on what to use as a key that a user cannot get access
to? Data hard-coded into a java applet, perhaps? Even that might be
hackable by someone a tool capable of inspecting javascript variables
at run-time.

Is it simply impossible to prevent cheating if my code is in
javascript? There must be some way to secure hidden form fields to
insure that their content is code-produced only. Is there? Or is there
some other way to make a cheater-proof javascript die roller I haven't
thought of?

[Lasse Reichstein Nielsen]

"Arnold Shore" <Nu***@away.far writes:

Yep, here's one cheater-resistant way.

Here's a cursory description of how: At each exchange, the server sends
(and remembers) a random string. The client hashes a concatenation of that
random value with the client's hashed password (cookie-stored) and sends
that. Which is compared server-side with the expected hash.

You'd use the result (hash of a hash) as the key to encrypt the die roll
info client side with some available symmetric key function (RC4 or 5, or
AES) before sending. Then, decrypt on receipt server-side.

But what prevents the player from fixing the die roll itself.

Secure transfer is not the problem, but preventing him from substituting
Math.random with function(){retu rn 1.0;} is.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[googlegroups]

Dag Sunde wrote:

Create a rollDice function on the server, and make an AJAX call from
the client.

This is exactly what I will do. I've never used AJAX before, hence the
attempt to do it client-side, but I just read up on AJAX and it looks
simple enough. Thank you! This is just what I needed, and thanks
everyone else--I learned a lot.

Kanon

[Lasse Reichstein Nielsen]

go**********@he rbaloutfitters. com writes:

This is exactly what I will do. I've never used AJAX before, hence the
attempt to do it client-side, but I just read up on AJAX and it looks
simple enough. Thank you! This is just what I needed, and thanks
everyone else--I learned a lot.

I question whether this actually solve your problem, but perhaps only
because the problem hasn't been stated precisely yet :)

Will successive server calls give the same result or different
results?
If the same results, why not just include the random number with
the original page.
If different results, what prevents the user from reloading until
he gets a good number?

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Dag Sunde]

Lasse Reichstein Nielsen wrote:

go**********@he rbaloutfitters. com writes:

>This is exactly what I will do. I've never used AJAX before, hence
the attempt to do it client-side, but I just read up on AJAX and it
looks simple enough. Thank you! This is just what I needed, and
thanks everyone else--I learned a lot.

I question whether this actually solve your problem, but perhaps only
because the problem hasn't been stated precisely yet :)

Will successive server calls give the same result or different
results?
If the same results, why not just include the random number with
the original page.

If different results, what prevents the user from reloading until
he gets a good number?

As long as he wanted to store it in a db serverside, he should have
no problems maintaining state during the session serverside.

--
Dag.