[MUD-Dev] strong encryption for authentication

F. Randall Farmer randy.farmer at pobox.com
Fri Jul 13 14:05:58 New Zealand Standard Time 2001


> Kwon Ekstrom wrote:

> I'd like to point out that this thread seems to be degenerating,
> the points of encryption I've noticed is:

>   PRO:

>     Security
>     Prevent "out of game" knowledge
>     Allow Credit Card and other "secure" transactions*
>     Authentication*
>     Allow Privacy
>     Protocol protection

>       * not required for entire connection.
>   CON:

>     Resource overhead.
>     Compatibility


I'd like to add CONs and comment on some confusion with a few of the
PROs.

  CON:

    Encrypting everything can lead to lazy game security design It
    can mislead customers into thinking that communications are
    private, when they aren't

Honestly, some of the PROs listed (though not promoted) so
succinctly by Kwon are not real!

Once the packets arrive at the computer, they are decrypted and used
in the clear.  So what that you need SOFTICE or GAMEWSHARK instead
of a packet sniffer; the hackers have your packets just the same and
know what is in them.

If you're talking about man-in-the-middle attacks (people stealing
your packets), that's one thing. Most of our products don't have
this problem (Tamzen's exception noted.)

It's another thing entirely to believe that hidden game information
remains "hidden" once it arrives at the client. If the information
isn't safe for a user's machine to know, the server shouldn't send
it. Period. Sending a game map of all enemy positions to all players
encrypted does nothing to prevent hacking and "cheating". Likewise,
adding encryption to messages that contain information the player
shouldn't doesn't help much either. :-)

As to misleading customers: If people think that since their data is
encrypted that instant messages aren't "readable in the clear" by
server support staff (when they are) it could cause some real
legal/social/game problems as well. Keep in mind that most folks
only understand public/private, not
public/semipublic/semiprivate/private/hidden distinctions.

Ask yourself the following questions before your declare that "more
encryption is better, always": What is the threat model? What is the
best way to address those threats? More often than not, encryption
is NOT the correct solution to the problem. Often encryption is used
as a lazy way to avoid fixing the problem. Don't use encryption when
what you need is a design change.

Security is Economics -- (Damn! I can't remember who said this.)

Oday ouya eakspay igpay atinlay?

Randy







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



More information about the MUD-Dev mailing list