RE: Security needs to be a major priority with this game

RE: Security needs to be a major priority with this game (Full Version)

All Forums >> [New Releases from Matrix Games] >> Empires in Arms the Napoleonic Wars of 1805 - 1815

Message

NeverMan -> RE: Security needs to be a major priority with this game (11/12/2008 2:10:48 AM)
quote: ORIGINAL: Marshall Ellis Yes. My plan is to let the host know how many times a battle was loaded by EACH player. Maybe this should be public and not just the host? This alone means very little. Are you going to implement other things as well, maybe something "along" the lines of what Jimmer suggested but more complex?

Grognot -> RE: Security needs to be a major priority with this game (11/12/2008 4:47:35 AM)
quote: ORIGINAL: Jimmer quote: Now, your next question should be "Hey, doesn't this mean even MORE emails?" Maybe not. Let's suppose that a particular sequence was generated when the game started. It could be passed along with the save file, and if we wanted to be a bit paranoid, the game could not only include that but a checksum incorporating a secret (e.g. MD5 of the concatenation of the game secret, with some hidden key buried in the game code -- not the save file. Probably no need to go RSA-heavy, heh). Then, a PRNG is usually initialized with some bit sequence. The same sort of magic (MD5) can work here: take the game seed, concatenate it with a proprietary secret (to make it harder to figure out what the actual PRNG seed will look like, and thus make it harder to forecast rolls), and furthermore concatenate it with some key denoting the type of action and location (e.g. '1809:09:land:fr:prov79:fieldcombat:attacker:round3:outflankroll'). Take the MD5 hash of the combined string (or different hash if the PRNG requires more bits), seed the PRNG with it, roll. It's somewhat robust unless the PRNG is prone to patterns early in a sequence. Nice thing is, strings which are similar to each other aren't supposed to generate similar MD5 hashes, so you can do this with just the per-game secret and the built-in one. Bad thing is, it might be slightly computationally ugly, but it's not -that- bad. It would still allow somebody to decide whether or not to actually -do- something (there's no real way around that unless there's a way to commit results to somebody else before seeing them -- problem if you're using quick combat, for instance... or with naval battles, testing interception), but reload + reorder wouldn't work.

delatbabel -> RE: Security needs to be a major priority with this game (11/12/2008 10:57:13 AM)
What about the idea of having a central game host that managed die rolls, etc. Most on-line EiA players (before EiANW when it was done using cyberboard) used services such as ACTS and Warfare Project to distribute die rolls, chit picks, etc.

Mardonius -> RE: Security needs to be a major priority with this game (11/12/2008 11:21:27 AM)
Great idea but perhaps a host with a priority of alternates in case the host(s) were involved in a battle

Marshall Ellis -> RE: Security needs to be a major priority with this game (11/12/2008 1:10:40 PM)
quote: ORIGINAL: NeverMan quote: ORIGINAL: Marshall Ellis Yes. My plan is to let the host know how many times a battle was loaded by EACH player. Maybe this should be public and not just the host? This alone means very little. Are you going to implement other things as well, maybe something "along" the lines of what Jimmer suggested but more complex? What more would you need othen than a public notice that France is cheating???

NeverMan -> RE: Security needs to be a major priority with this game (11/12/2008 2:16:55 PM)
quote: ORIGINAL: Marshall Ellis quote: ORIGINAL: NeverMan quote: ORIGINAL: Marshall Ellis Yes. My plan is to let the host know how many times a battle was loaded by EACH player. Maybe this should be public and not just the host? This alone means very little. Are you going to implement other things as well, maybe something "along" the lines of what Jimmer suggested but more complex? What more would you need othen than a public notice that France is cheating??? Oh, so it is going to detect cheating, because simply knowing that someone loaded their turn multiple times is not enough, IMO, to accuse someone of cheating? What if their computer crashed (Windows has a habit of doing that)? What if they accidentally hit the wrong key and had to reload, etc, etc, etc...?

bresh -> RE: Security needs to be a major priority with this game (11/12/2008 3:23:52 PM)
quote: ORIGINAL: NeverMan quote: ORIGINAL: Marshall Ellis quote: ORIGINAL: NeverMan quote: ORIGINAL: Marshall Ellis Yes. My plan is to let the host know how many times a battle was loaded by EACH player. Maybe this should be public and not just the host? This alone means very little. Are you going to implement other things as well, maybe something "along" the lines of what Jimmer suggested but more complex? What more would you need othen than a public notice that France is cheating??? Oh, so it is going to detect cheating, because simply knowing that someone loaded their turn multiple times is not enough, IMO, to accuse someone of cheating? What if their computer crashed (Windows has a habit of doing that)? What if they accidentally hit the wrong key and had to reload, etc, etc, etc...? I think he said battlefiles loaded repeatly. So far in some pbm games i never had my pc crash during a turn (cross my fingers). I do belive at times, you sometimes want to discuss plans with your ally before moving forces, but you would need to load the game to see the situation. I think the idea about checking when there are rolls involved like forage it should use some XX-file, mentioned above. Regards Bresh

NeverMan -> RE: Security needs to be a major priority with this game (11/12/2008 3:43:56 PM)
quote: ORIGINAL: bresh quote: ORIGINAL: NeverMan quote: ORIGINAL: Marshall Ellis quote: ORIGINAL: NeverMan quote: ORIGINAL: Marshall Ellis Yes. My plan is to let the host know how many times a battle was loaded by EACH player. Maybe this should be public and not just the host? This alone means very little. Are you going to implement other things as well, maybe something "along" the lines of what Jimmer suggested but more complex? What more would you need othen than a public notice that France is cheating??? Oh, so it is going to detect cheating, because simply knowing that someone loaded their turn multiple times is not enough, IMO, to accuse someone of cheating? What if their computer crashed (Windows has a habit of doing that)? What if they accidentally hit the wrong key and had to reload, etc, etc, etc...? I think he said battlefiles loaded repeatly. So far in some pbm games i never had my pc crash during a turn (cross my fingers). I do belive at times, you sometimes want to discuss plans with your ally before moving forces, but you would need to load the game to see the situation. I think the idea about checking when there are rolls involved like forage it should use some XX-file, mentioned above. Regards Bresh Yes, you are correct he said battle files. I used "turn" because it has broader cheating implications. That said, what I said earlier still holds true for either "battle" files or "turn" files. I have had my computer crash during games. I have accidentally hit the wrong button(s) (not thinking) and I have had my GPU not recover during games (not this one though). I'm just saying that these things happen and to ban a player from a game for reloading a turn is not the best scenario when I think a better method (such as the one Jimmer suggested but maybe more complex/advanced) can be found/implemented.

Marshall Ellis -> RE: Security needs to be a major priority with this game (11/12/2008 3:55:56 PM)
Tracking the loading of turn files could also be done. This would also be a good indicator BUT I think I only want to let everybody know how many times it was loaded as opposed to blocking a reload just in case the PC crashed, world came to an end, etc. Agreed? It would still be public knowledge so that if Bob's computer were always "crashing" then the host could warn / replace.

NeverMan -> RE: Security needs to be a major priority with this game (11/12/2008 4:04:31 PM)
quote: ORIGINAL: Marshall Ellis Tracking the loading of turn files could also be done. This would also be a good indicator BUT I think I only want to let everybody know how many times it was loaded as opposed to blocking a reload just in case the PC crashed, world came to an end, etc. Agreed? It would still be public knowledge so that if Bob's computer were always "crashing" then the host could warn / replace. Is there a way to save the state upon a forced or unexplained close?

Marshall Ellis -> RE: Security needs to be a major priority with this game (11/12/2008 7:48:04 PM)
quote: ORIGINAL: NeverMan quote: ORIGINAL: Marshall Ellis Tracking the loading of turn files could also be done. This would also be a good indicator BUT I think I only want to let everybody know how many times it was loaded as opposed to blocking a reload just in case the PC crashed, world came to an end, etc. Agreed? It would still be public knowledge so that if Bob's computer were always "crashing" then the host could warn / replace. Is there a way to save the state upon a forced or unexplained close? Not easily. This would force the creation of a persistence manager (Close to an O/S architecture) and that's a whole new app. We might use 500k to fix a 200k problem.

NeverMan -> RE: Security needs to be a major priority with this game (11/12/2008 8:19:56 PM)
quote: ORIGINAL: Marshall Ellis quote: ORIGINAL: NeverMan quote: ORIGINAL: Marshall Ellis Tracking the loading of turn files could also be done. This would also be a good indicator BUT I think I only want to let everybody know how many times it was loaded as opposed to blocking a reload just in case the PC crashed, world came to an end, etc. Agreed? It would still be public knowledge so that if Bob's computer were always "crashing" then the host could warn / replace. Is there a way to save the state upon a forced or unexplained close? Not easily. This would force the creation of a persistence manager (Close to an O/S architecture) and that's a whole new app. We might use 500k to fix a 200k problem. Sounds ok to me. This sounds to me like the best solution.

Marshall Ellis -> RE: Security needs to be a major priority with this game (11/12/2008 8:23:48 PM)
Actually the big key would be tracking of turn file loading and battle file loading. The battles are a little trickier since a battle file is loaded several times by the same player in a normal battle. The key is to make sure that no one is selecting chits twice or loading at the same point more than once.

Jimmer -> RE: Security needs to be a major priority with this game (11/12/2008 8:39:04 PM)
quote: ORIGINAL: Marshall Ellis Yes. My plan is to let the host know how many times a battle was loaded by EACH player. Maybe this should be public and not just the host? This can be defeated. All the person has to do is play on a second system, with copies of the game files, to find out what's going on. Now, if the game put an encrypted serial number tracer into the registry somewhere (use an obfuscated key name, and do not reference the game itself in any way), THAT would make it hard. I could still break through it, but not many other people would know how (and I don't cheat). If this tracer were tied to the installed-game copy itself, AND to the game in progress, this would help enormously. But, this is no easy feat to accomplish. You have to get permission from Microsoft to "own" the registry key (not value) in question, so no other vendor accidentally uses the same key. Then, the game could check the local hard disk and network for other copies of the game. Firewalls could block this, but not if you use the same ports the game will use generally (i.e. that will be needed for basic TCP/IP functionality in the future). To block the copy protection, the user would have to also block the IP capabilities of the game. That's not a threat now, but it certainly could be down the road.

Jimmer -> RE: Security needs to be a major priority with this game (11/12/2008 8:41:19 PM)
quote: ORIGINAL: Grognot quote: ORIGINAL: Jimmer quote: Now, your next question should be "Hey, doesn't this mean even MORE emails?" Maybe not. Let's suppose that a particular sequence was generated when the game started. It could be passed along with the save file, and if we wanted to be a bit paranoid, the game could not only include that but a checksum incorporating a secret (e.g. MD5 of the concatenation of the game secret, with some hidden key buried in the game code -- not the save file. Probably no need to go RSA-heavy, heh). Then, a PRNG is usually initialized with some bit sequence. The same sort of magic (MD5) can work here: take the game seed, concatenate it with a proprietary secret (to make it harder to figure out what the actual PRNG seed will look like, and thus make it harder to forecast rolls), and furthermore concatenate it with some key denoting the type of action and location (e.g. '1809:09:land:fr:prov79:fieldcombat:attacker:round3:outflankroll'). Take the MD5 hash of the combined string (or different hash if the PRNG requires more bits), seed the PRNG with it, roll. It's somewhat robust unless the PRNG is prone to patterns early in a sequence. Nice thing is, strings which are similar to each other aren't supposed to generate similar MD5 hashes, so you can do this with just the per-game secret and the built-in one. Bad thing is, it might be slightly computationally ugly, but it's not -that- bad. It would still allow somebody to decide whether or not to actually -do- something (there's no real way around that unless there's a way to commit results to somebody else before seeing them -- problem if you're using quick combat, for instance... or with naval battles, testing interception), but reload + reorder wouldn't work. Good idea(s)!

Jimmer -> RE: Security needs to be a major priority with this game (11/12/2008 8:43:38 PM)
quote: ORIGINAL: delatbabel What about the idea of having a central game host that managed die rolls, etc.� Most on-line EiA players (before EiANW when it was done using cyberboard) used services such as ACTS and Warfare Project to distribute die rolls, chit picks, etc. This is the only possible truly secure implementation: A third party that handles the mechanics. I'm operating on the assumption that this isn't practical at this point in the product's life. But, if it is, it eliminates the need for several of the above points. The nice thing about the method I proposed is that it would seamlessly integrate into this plan, with very little modification. I was actually thinking forward to this kind of idea (see the thread from about 3 months ago, where I outlined it in broader terms).

Jimmer -> RE: Security needs to be a major priority with this game (11/12/2008 8:45:45 PM)
quote: ORIGINAL: Mardonius Great idea but perhaps a host with a priority of alternates in case the host(s) were involved in a battle Actually, this shouldn't matter. It's the game copy that the host is using that does the work, not the host itself. The host is merely a placeholder, in this instance. However, your point brings up a good side point: The entity that does the security testing does NOT have to be the host. It can fall to any copy of the game in use. The key, though, will be that the players cannot be told which one it is at any point. All players have to load all files. They just won't know which one of them actually utilized the data.

Jimmer -> RE: Security needs to be a major priority with this game (11/12/2008 8:47:08 PM)
quote: ORIGINAL: Marshall Ellis What more would you need othen than a public notice that France is cheating??? A guillotine. Strangely appropriate for this game, don't you think? :)

Jimmer -> RE: Security needs to be a major priority with this game (11/12/2008 8:50:07 PM)
quote: ORIGINAL: NeverMan What if their computer crashed (Windows has a habit of doing that)? What if they accidentally hit the wrong key and had to reload, etc, etc, etc...? If that happens, then it is incumbant upon the player to notify the rest of the players prior to moving forward. If the security stuff is done correctly, the game will not be able to progress anyhow, in the case of a game or system crash. The security stuff should detect the mismatch. Now, a player could feign a crash in order to "re-roll", yes. But, if you have one player getting 2-3 of these every phase, it's time to find a new player.

Jimmer -> RE: Security needs to be a major priority with this game (11/12/2008 8:58:30 PM)
quote: ORIGINAL: bresh So far in some pbm games i never had my pc crash during a turn (cross my fingers). I haven't had a computer crash in months. It only reboots when I tell it to, usually after "Patch Tuesday" (once or twice a month). The secret? Run all games (and everything else that doesn't require admin rights) inside a user account that does not have administrator rights. It's amazing how many crashes cannot occur when you don't have admin rights. Vista does this by default, but most people have this desire to be "god" on their computer, and they change the settings back to godhood. VERY bad idea. I run a small business that gets people out of the messes they create with just such actions. Tsk, tsk!

Jimmer -> RE: Security needs to be a major priority with this game (11/12/2008 9:01:34 PM)
quote: ORIGINAL: Marshall Ellis Tracking the loading of turn files could also be done. This would also be a good indicator BUT I think I only want to let everybody know how many times it was loaded as opposed to blocking a reload just in case the PC crashed, world came to an end, etc. Agreed? It would still be public knowledge so that if Bob's computer were always "crashing" then the host could warn / replace. That's an acceptable compromise as a first step. However, I think players will want to have the game make the recommendation to drop a player due to excessive "restarting". Real security, though, must be implemented at a far deeper level. The above, for instance, could not be used in a tournament with prize money, simply because the entrants need more concrete rules. But, it could be used in tandem with other "house rules" for such gatherings.

Jimmer -> RE: Security needs to be a major priority with this game (11/12/2008 9:07:57 PM)
quote: ORIGINAL: Marshall Ellis Not easily. This would force the creation of a persistence manager (Close to an O/S architecture) and that's a whole new app. We might use 500k to fix a 200k problem. Alternately, you can simply apply a "changed file" token to both the user's local saved copy of the game (the .sav or .dat file) and to what will become the PBM file once it is generated. If you do this at the instant the player LOADS the saved game and each PBM file (instead of when he ends his phase), you mitigate against the "simple cheat" of merely closing the game and restarting the turn. It's not good enough against the model where the cheater puts two copies of the game onto two different systems, but it at least gets rid of the obvious version of this "reload cheat". NOTE: A "changed file token" is a little different than the token I described above, but it serves roughly the same purpose. The one I noted above is a bit more robust. But, this one would be an excellent first step. Plus, there's no need to remove it later in the life of the game.

Marshall Ellis -> RE: Security needs to be a major priority with this game (11/12/2008 10:37:05 PM)
There are other things that I am doing that we should not discuss in too much detail ... ;-)

NeverMan -> RE: Security needs to be a major priority with this game (11/13/2008 12:29:57 AM)
quote: ORIGINAL: Jimmer quote: ORIGINAL: NeverMan What if their computer crashed (Windows has a habit of doing that)? What if they accidentally hit the wrong key and had to reload, etc, etc, etc...? If that happens, then it is incumbant upon the player to notify the rest of the players prior to moving forward. If the security stuff is done correctly, the game will not be able to progress anyhow, in the case of a game or system crash. The security stuff should detect the mismatch. Now, a player could feign a crash in order to "re-roll", yes. But, if you have one player getting 2-3 of these every phase, it's time to find a new player. It only takes 1 time to change the course of the game.

Jimmer -> RE: Security needs to be a major priority with this game (11/13/2008 12:46:36 AM)
quote: ORIGINAL: Marshall Ellis There are other things that I am doing that we should not discuss in too much detail ... ;-) Actually, we should. But, perhaps not here. And, perhaps not "we", as in me. But, SOME people should talk it through, and examine the details.

Dancing Bear -> RE: Security needs to be a major priority with this game (11/13/2008 1:33:07 AM)
Only if a battle file loaded more than once does anyone else need to be told about it. Then, everyone should be told. There is nothing like a good public shaming. Perhaps the player doing the relaoding can be given a warning about all other players being informed.

NeverMan -> RE: Security needs to be a major priority with this game (11/13/2008 2:37:19 AM)
Where do the battle files come from? Can they be altered? Can they be copied, moved, then copied back over?

Grognot -> RE: Security needs to be a major priority with this game (11/13/2008 5:05:22 AM)
quote: ORIGINAL: NeverMan Where do the battle files come from? Can they be altered? Can they be copied, moved, then copied back over? Data is data. If you know where it is, if you can read it, and if nobody else has full control over your hardware, you can copy it to do whatever. It'd take fairly fascist methods to stop somebody from playing the game in a sufficiently well-done virtual machine, duplicating and restoring the whole disk image as he felt, for instance. Wiping a virtual machine would be rather drastic, but it'd also make such things as buried keys in the Windows Registry utterly moot, because that'd be restored too. Although in practice, considering that this is a low-stakes, low-profile PBEM game, perhaps one would be better off worrying about cheating via controlling multiple nations through different online identities, rather than people investing lots of time in technological methods. Somebody who's secretly controlling some other nation in addition to France, for instance, would have a huge advantage if his alter ego were privy to negotiations and planning, and it wouldn't require arcane skills with debuggers and hex editors to do so.

Jimmer -> RE: Security needs to be a major priority with this game (11/13/2008 4:37:00 PM)
quote: ORIGINAL: Grognot Wiping a virtual machine would be rather drastic, but it'd also make such things as buried keys in the Windows Registry utterly moot, because that'd be restored too. Actually, the key is buried after the battle/turn file is loaded, and at the same time that the token is sent. The only real problem possible is if the sending of the token is blocked. However, if blocked, then the player has to reload again prior to his "real" attempt, and that means getting different results. There's still a method someone could use, though: Capturing (rather than blocking) the token. This can only be mitigated by having to have a two-way token transfer, and that means another round of back and forth emails. So, it would slow down the game. Hence the reason I skipped talking about it.

Page: << < prev 1 [2]

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

0.953125