[MUD-Dev] Guest Voices #2: Griefing in Online Games

John Buehler johnbue at msn.com
Fri May 20 05:32:32 New Zealand Standard Time 2005


J C Lawrence wrutes:
> On Tue, 17 May 2005 12:42:20 -0400
> Paul Schwanz <pschwanz at bellsouth.net> wrote:
>> J C Lawrence wrote:

>>> PK crypto is a frequent suggestion for such problems but suffers
>>> from two central problems:

>>> There is significant reward for an inimical player to ensure
>>> that their private keys are shared, and shared in a way which
>>> makes accurate detection and handling exceedingly
>>> difficult/expensive.

>> What if we were able to work something into the private key that
>> gave the player a strong incentive not to share it?  Like, for
>> instance, the credit card information against which the account
>> is paid must be present along with the key in order for it to be
>> usable?  Of course, this move beyond simple PK crypto, but I'm
>> just thinking out loud.

> I think that binding directly against the credit card data isn't
> going to work, and in fact, can't be allowed to work by those
> affected.  I think that VISA and the other charge companies would
> have a fit over the increased fraud risks, that service
> competitors would raise a personal privacy/information stink, and
> that customers would absolutely hate the idea of a) their credit
> card number being stored directly on their PCs and thus in threat
> of exposure, or b) of having to constantly re-enter it for
> verification instead.

I may be missing something significant here.  I'm trying to come up
with some kind of a copy/stealing discouragement strategy for a
piece of software that I'm working on.  Paul's suggestion caught my
eye.  I was thinking of applying it during installation.  Supply the
credit card number that was used to buy the software, and the
software will install.  Lacking the number, the software won't
install.

The installation package doesn't have the credit card number in it
and it doesn't save it once supplied.  It treats the credit card
number like a password, holding only a one-way encryption of the
credit card number in the installation package.  Supply the wrong
credit card number, it gets encrypted to a string that doesn't match
the stored one and the installation is stopped.

I just want something that will discourage casual theft of the
software.  Problems that I see with this approach are:

  1. The installation package can be hacked to bypass the check.  (A
  competent hacker)

  2. The installed software can be gathered up and less-conveniently
  installed on other systems.  (A determined thief)

  3. Credit cards are fairly easy to obtain.  Get one, buy the
  software, cancel the card.  The number just becomes a number at
  that point. (A determined thief)

  4. Credit card numbers are only about 16 digits long, and not all
  numbers are valid.  It might not take that long to figure out what
  the credit card number is. (A patient hacker)

  5. Friends and family who trust each other with credit card
  numbers, or who can be present to supply a credit card number at
  installation time, will not have need to buy multiple copies of
  the software. (life)

JB
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev


More information about the MUD-Dev mailing list