[MUD-Dev] strong encryption for authentication

[Ben Tolputt]

Coming up briefly from the dark depths of lurking...

Quoted from Caliban Tiresias Darklock (Thursday, July 12, 2001 01:29 PM)

> So... you don't consider these perfectly legitimate applications
> of player ingenuity?

No, I don't - I think that they're applications of hacker ingenuity.

The general player (of my MUD) does not have the technical expertise
to hack the protocol, sniff packets from a router, etc. It is giving
players an out of game advantage unrealated to their character - in
my book a Bad Thing (tm).


> You do at this writing. Whatever encryption scheme you decide
> upon, the player has to acquire a compatible client. At first,
> that will be...  your client. Period. And you will NEVER really
> free the user to choose his *own* client. I don't like that.  That
> means I have to develop TWO products, instead of just one.

I would have to agree with you here, but I would classify that
starting a 'trend' in encryption is a good thing. After all, if all
clients start implementing some form of encryption, then it can't be
a Bad Thing (tm). After all, you don't have to use the feature - but
other may want to...

> I think encryption is a pain in the ass. If I can avoid it, I
> will. If I don't think it's necessary, I don't want it. I need a
> *real* reason to use encryption, and it better be a good one.

It can be a pain in the ass, but so is dying because a player had an
out of game advantage of knowing you were weak.

> And until that situation changes, this will remain the case. I
> didn't like PGP even when I could right-click to encrypt and/or
> sign my mail messages in Eudora.

Another thing I agree with. If the other end doesn't do it
automatically and/or you must take extra step for every transaction,
encryption is not worth the effort. However, if the encryption is
transparent to you the user - how is it a pain?

> Why? Because there was no compelling reason to do so. And there
> still isn't. My credit card information has been sent in the clear
> across the net dozens, if not hundreds, of times. I have never had
> a single problem. Now, if I can happily send my credit card info
> spiraling off through who knows how many routers, SMTP servers,
> and gateways without a problem... don't you think the average
> player can pretty much do the same with his gaming?

The reason you CAN send your credit card information of over the
Internet is due to the transparent encryption of the information by
your web-browser...

> Then the people who engage in real-world transactions should apply
> what they consider an appropriate level of security. But the game
> itself is... well, a GAME. It's not a business transaction.
> Should my MUD support credit card transactions and escrow
> arrangements with shipping calculations because someone may want
> to buy someone else's character? I don't think so. That's not part
> of the game.

It may not be part of the game, but I can see how it could become a
part of the company's income. If you could setup secure transactions
within the game, you could perhaps add a small surcharge, or
percentage of said transactions to be kept by the company. A viable
method of making money from you MUD. If, however you don't wish to
have control over this (free MUD, or perhaps just not interested) -
you don't have to employ encryption - but others may.

> So far, you've pegged three potential problems.

>   1. People could be spied on.
>   2. People will want privacy.
>   3. People may engage in RL commerce.

> My response to these three situations is:

>   1. The game is a public environment. Deal with it.
>   2. The game is a public environment. Deal with it.
>   3. The game is a public environment. Deal with it.

Great, but I would like to implement a game where the player can
feel secure that they aren't being spied on, for whatever reason.
Is this a bad thing? I don't think so.

> I'm not violently opposed to the idea of
> encryption in MUDs,

That's good to know! :-)

> but I *am* violently opposed to the idea
> of adding features to software that serve no good purpose.

I agree with you here - but I can see valid reasons.

> Let's look at what we have.

>   1. Encryption would be a Good Thing. Why?

It adds a level of security to the game (see the example of
the player using out-of-game knowledge to kill another player
in a PVP MUD). It also allows us to implement features such as
in-game transactions which can bring in (much needed) income to
the MUD.

>   2. Because it is a Desirable Feature. Why?

See above, and an added bonus is you can add another feature to
that long list no-one ever reads :-)

>   3. Because it prevents Undesirable Results. What are they?

Players using out-of-game knowledge to gain an in-game advantage
for one. I'm sure others can think of more.

Points 4 thru 6 are based solely on your opinion, which is not
a bad thing - but can't be argued as every-one's opinion is
correct. Don't believe me, just ask them!  :-)


>   7. Ummmm about 20% of the CPU power used by the game. Wouldn't
>      a 25% speed increase be better? (current speed == 80%, new
>      speed == 100%, 100/80 == 1.25 == 125%)

Possibly - but this depends on how costly the encryption is you're
using, whether or not you are achieving full load on you MUD anyway,
and whether you think encryption is worth this sacrifice. I do.

>   8. Ummmm not with those problems. Doesn't a 25% speed increase
>      benefit all the players all the time?

>   9. Ummmm yes but ummm what about those problems? Do all players
>      have them all the time?

Depends on your priorities - mine lean towards a more secure game,
and hence my 'opinion' is that all players DO benefit from
encryption all the time - especially considering my MUD is both PVP
and has permadeath.

>   10. Ummmm... no. Doesn't that pretty much make your decision for
>       you?

Perhaps it would make it for you - but I think we're approaching
this from different ends of the spectrum.

> If you'd like me to continue this line of reasoning through
> hardware encryption accelerators and convincing ISVs to add
> encryption to their clients, I could, but the results aren't
> pretty. ;)

I'm sure they aren't *grin*. But I agree with you on the
hardware encryption area anyway. As for ISV's, they're smart
enough to implement it themselves when they see that encryption
is picking up in the 'free' clients.

> Only a very few of them. The rest will go on not even properly
> supporting the telnet standard. :P

Well, you get what you pay for :-)


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