[MUD-Dev] strong encryption for authentication

[Caliban Tiresias Darklock]

On Wed, 18 Jul 2001 21:09:23 -0500 (CDT), shren <shren at io.com> wrote:
> On Sun, 15 Jul 2001, Caliban Tiresias Darklock wrote:

>> Security through obscurity is no security at all. Assume everyone
>> knows the content of every byte in every packet you send them,
>> and if you don't want them to know it, don't put it in the
>> packet. If the packet ends up empty, don't send it.

> Don't forget the flip side here.  Never assume that every action
> sent by the client is a valid action.

Absolutely. But let's not forget the flip side of *that*: never
assume that every INVALID action is the result of malicious
hacking. I actually have a horror story about this. :)

While I was working in AOL's tech support, a NWN player I spoke to
had a computer crash while playing the game, and upon rebooting he
was unable to rejoin the game. So he called tech support because he
didn't know why. When I picked up the call and checked his account,
I found it had been terminated for violating AOL's terms of service.

What had happened was that the crash had corrupted his player file,
and the server decided that the player was attempting to cheat. It
therefore kicked him out of the game and sent a notice to the game's
administrators. While he had been on hold in the tech support queue,
they got the notice that he had attempted to log on with an invalid
player file, and decided he had been attempting to hack the
game. Since this is most definitely against AOL's terms of service,
they terminated the account. So as the result of a computer crash,
the caller's entire AOL account was lost.

I found this absolutely outrageous, and embarked on a personal
crusade to find out what exactly had gone wrong and why he had lost
his account.  Since he lived nearby, I dropped by after work to
examine his player data. What I found was that the file had been
truncated to 0 length, and when the client loaded it, no error
checks were made: it simply assumed that if the file existed, it
would be of the expected length. A scan through the system calls
uncovered that the NWN client was opening the file in read/write
mode, which would create the file if it did not exist -- so the only
error check made by the client would effectively never fail unless
the disk was full or write-protected. This meant that a zero-length
file simply left whatever garbage was in that memory area untouched,
and assumed it had been overwritten by the file even when the read
failed. (Furthermore, it read until EOF, so a *longer* file than
expected would cause other problems and potentially segfault.)

Knowing why this allowed the user to login with invalid player data,
I went to development the next day to explain what was wrong and how
to fix it. (Read only as much data as you expect, and verify that
you got exactly that much data. Basic stuff.) We spoke at length
about this, and they indicated that I would have to talk to the game
administrators about the account problem, but they would put this on
the bug list for the next version of the client. To make matters
worse, they explained that the player file was recognised as invalid
because the NWN server *also* kept a copy of the player data and
compared it to the copy provided by the client. In other words, the
error was perfectly recoverable: when the data was found to be
invalid, the server need only have reported that it was corrupt and
replaced it with the valid copy they had on the server.

The user didn't get his account back, incidentally, and the game
administrators terminated *my* account for violating the terms of
service because I had partially disassembled and reverse-engineered
the client. Since maintaining my AOL account in good standing was a
condition of employment, I got fired. But that's a whole 'nother
thread about "the average system does not reward success, and often
punishes it". ;)

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