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**********@herbaloutfitters.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**********@herbaloutfitters.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/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Dag Sunde]

go**********@herbaloutfitters.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/rasterTriangleDOM.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**********@herbaloutfitters.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.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.farwrites:

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(){return 1.0;} is.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.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**********@herbaloutfitters.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/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Dag Sunde]

Lasse Reichstein Nielsen wrote:

go**********@herbaloutfitters.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.

[googlegroups]

I question whether this actually solve your problem, but perhaps only

because the problem hasn't been stated precisely yet :)

I guess the precise problem is simply that I want to make a
cheater-proof die roller as a forum mod. (The forum is SMF, BTW.) I
want to do it in javascript for speed.

>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.

Yup, so a user who keeps rolling will have each roll put into the db.

>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.

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(){return 1.0;} is.

Thanks for the info about CHAP. It looks very interesting, but yeah, I
think it's not good enough in this case. The die roll needs to be
generated server-side or else it will always be vulnerable to
client-side manipulation.

With AJAX, I can dynamically load a simple php file using javascript.
This simple php file will simply generate a random number, insert it
into the database, and return the result to the calling javascript
function. Even if the user manipulates this, he can't (theoretically)
ever manipulate the database.

To see what I have so far, check out:

http://herbaloutfitters.com/dierolle...;num_replies=2

Click the two red dice to open the die roller popup.

Kanon

[Lasse Reichstein Nielsen]

go**********@herbaloutfitters.com writes:

With AJAX, I can dynamically load a simple php file using javascript.
This simple php file will simply generate a random number, insert it
into the database, and return the result to the calling javascript
function. Even if the user manipulates this, he can't (theoretically)
ever manipulate the database.

True. It seems you can roll without being logged in, but if you record
the client ip address wih the roll, you should still have a clue
whether someone is rerolling for a good roll.

On the other hand, if one post contains multiple rolls of the same
type, the player can still rearrange them to his needs, like using
his magic arrow for the second attack, not the first, decided after
rolling both attack rolls.
Another solution could be to add a tag, e.g.,: [dice=5d4+5]damage[/dice]
which is expanded server side into "damage (5d4+5=17)"
You can even add extra parameters to show individual die rolls, e.g.:
[dice=10d6,show]fireball[/dice] becoming
"fireball (10d6=4+2+4+6+2+1+3+2+6+6=36)". I still think this is a lot
simpler than using extra server calls and trying to control the user.

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

[googlegroups]

Lasse Reichstein Nielsen wrote:

True. It seems you can roll without being logged in, but if you record
the client ip address wih the roll, you should still have a clue
whether someone is rerolling for a good roll.

Actually, I just configured that test forum to allow guests to post
(and therefore roll dice). In actual use, only members of a game will
have the ability to post in it. This is yet another mod I'm working on.

On the other hand, if one post contains multiple rolls of the same
type, the player can still rearrange them to his needs, like using
his magic arrow for the second attack, not the first, decided after
rolling both attack rolls.

Not once I actually make that reason textbox work. I'll put a note to
the players saying to be specific about what the roll is for.

Another solution could be to add a tag, e.g.,: [dice=5d4+5]damage[/dice]
which is expanded server side into "damage (5d4+5=17)"

Problem with this is that it's nice to know the result of your roll
while posting, not just after. For example, if the GM tells you to roll
vs. your IQ to detect something, you can do the roll and respond with
your character's actions based on whether or not you succeeded.

Another member of the team I'm doing all this with (see
http://www.ayeka.net/smf/index.php?board=89.0 for our developer's
discussion area) has made a dieroller very much like what you describe.
It's simple and it works. You can see it in action on his site:
http://forum.technodragon.net/ , but you'll have to register to get
posting (and therefore rolling) access.