Turn Slurping ! (was PBM report)

From: "MindShift Design" <teammsd@mindshiftdesign.com>

Date: Mon, 30 Oct 2000 05:38:22 +0000

"Paul Walker" <arafel@spamcop.net> wrote in message
news:slrn8vk54e.3vh.arafel@nova.blacksun.org.uk...
> On Wed, 18 Oct 2000 18:32:14 -0400, MindShift Design wrote:
>
> Replying to two at once here, to save some time. Apologies for the length
of
> the post.
>
> >"Tim Franklin" <tim@leaphome.pelican.org> wrote in message
> >> Connect, slurp all the info in the player's vicinity, disconnect.  You
> >> need to be *very* careful about showing the player things he has no
right
>
> That's more or less what I had in mind, with the additional feature that
you
> could connect for updates every X time periods that the player's online,
so
> that when they disconnect, it's as up-to-date as it can reasonably be.

Makes sense. It can also be used to download the latest version of the
client program itself as another feature, including minor or major updates.
It also depends on how often the game data changes of course.

> >new session key has to be created and a new data package downloaded. This
> >would take a little bit of work to make work, but it could stop the data
> >packet being hacked as the client program would be the initiater of the
data
> >transfer and would control it all. If the session key doesn't match
what's
> >in memory at any time, then the download or import aborts. Of course,
>
> Um. Before anyone can comment, I think you need to be a lot more precise
> about what you mean by "hacked". Faked at the server end? faked at the
> client end? sniffed on passthrough? what?

Hacked as in either hacking the packet and changing its contents, or
spoofing the server with fake command information from what seems to be a
valid source.

> It's also worth noting that the easiest way to securely transfer a session
> key is the way that ssh does it - generate a keypair when first installed
> (per user in ssh's case), and exchange public keys with the server. (Don't
> remember offhand whether the server transmits key every time, or just ID.
> Mostly irrelevant.)

That's what I was thinking of. PGP for PBM <g>. The other option is to
initiate an SSL connection to the server as well, although that won't stop
the actual data packages being compromised, just the delivery system
(usually).

> This is fine, and the client can do it on install - it can then send that
> key to your server when the user registers, so you can securely exchange
> data. You need to think about a way to let the user change it with the
> minimum of fuss when they lose the client install, however; probably just
> user/password for web-account access would do, I guess. :-)

If game information is sent in a data package burst then it can be included
at the beginning, middle or end of the actual file, or even be used to
create the the encrypted data package burst itself. The game information
being delivered to the server can be encrypted using the key.

> Um. This ended up being somewhat rambling, sorry; I was doing a little
> thinking through while writing. As you might have guessed, I've spent a
> reasonable amount of time recently looking at this stuff. ;)
>
> >It's a different story when the data is held in the local datastore for
the
> >client program .. and a whole other problem ... Sound workable though ?
>
> It depends on how protected you want to make it, and how sophisticated you
> assume any attackers will be. If you want to pin that down a little more,
I
> don't have to write so much in this post, and I'm all for that. ;-)

Hmm. I'm thinking of how best to handle data that "could" be manipulated. If
the information held on the local computer is in fact on a public
client-only version of the real data stored on the server then I don't see
it as a real problem. If the packages being sent to and from the server in a
delayed manner (download, process, upload, process) and not happening with a
real communicaiton pipe with bi-directional communication and with only data
that can't be manipulated to modify server data, then it should be workable
enough. So you download a copy of the real server data to show you what your
position is in a game, and when you send back information to the server,
it's just commands to modify your position. Error checking and
authentication on the server make sure that the commands are valid and that
they aren't trying to misreport information. The server should only run
pre-designated commands anyway and shouldn't allow access to the raw data
for a game - though I've ran into client/server programs that have !

I'll ramble more once you're rambled more <g>.

--
Jason Paul McCartan - jasonm@mindshiftdesign.com
CEO/President
MindShift Design LLC
http://www.mindshiftdesign.com

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

References

Re: PBM report
MindShift Design LLC <mindshift@my-deja.com>
Thu, 12 Oct 2000 00:00:00 +0000
Re: PBM report
madcentral@aol.com (MadCentral)
Fri, 13 Oct 2000 00:00:00 +0000
Re: PBM report
"MindShift Design LLC" <admin@mindshiftdesign.com>
Fri, 13 Oct 2000 00:00:00 +0000
Re: PBM report
tim@leaphome.pelican.org (Tim Franklin)
Mon, 16 Oct 2000 00:00:00 +0000
Re: PBM report
"MindShift Design" <teammsd@mindshiftdesign.com>
Wed, 18 Oct 2000 00:00:00 +0000