[Divunal-list] Security Considerations

[Mark Benvenuto]

    Public projects regardless of their status as Open Source or their
ambitions for commercial success must take into consideration security.
In the first days of the Internet, everyone was very open and security
was not a concern. The early IETF standards show this (POP, SMTP, FTP,
DNS, IPv4, TCP, UDP, etc.). The IETF is now taking security into
consideration for all of their current proposals and drafts. (SEC-DNS,
TLS, OpenPGP, S/MIME, IPSec, IPv6, SSH, etc.). Divunal should be know
different.
    The current strength of Divunal and Twisted Reality is the fact that
all of the objects and data files reside on the server along with all of
the commands and command validation. The principal weakness of the
current model is its openness. It uses a plain text protocol. It sends a
short int specifying the command, a byte specifying the number of
additional data entries, and then a series of byte and data pairs
containg the type of data and the actual data (byte array(length byte,
then data), string, or null. This is a very simply designing protocol
but it lacks security considerations. The users requests to the server
are public. Anyone potentially could read the data. They could alter it
by using known attacks or simply gain curcial data. They could be
provided with addtional information about the game or with the passwords
of the users. The passwords are particulary valuable as an attacker
could damage the came if he got a god account or damage an individual
user's account.
    Unfortunately, security cannot be adequately dealt with do to U.S.
export restrictions on strong cryptography. The easiest way to improve
security would be to use an SSL connection between the client and
server. This would increase the strain on the server unfortunately and
cannot be done by U.S. citizens because of export rules. For the time
being, this security problem must be lived with (maybe the U.S. will
drop the restrictions).
    A total security implementation cannot be attained but the security
of the password mechanism can be improved. The password is currently
sent in plain text across the connection and stored with
twisted.util.UnixCrypt. Following the Linux security model with PAM, it
should be stored in a hash such as MD5 or SHA-1. Both are more secure
and require no additional software then JDK 1.1+ (For the GTK+ version,
I can get an MD5 version for any license). Also, the password should be
sent over the connection in a hashed form. Following a model such as OTP
(rfc2289), a small challenge string should be sent with the LOGIN
message and then the password hash commputed by a command such as HASH(
challenge & HASH( password )) should be sent across from the client. The
server would take the stored password hash and challenge and execute
HASH( challenge & stored-password-hash )). The server would compare the
client generated with the server generated and if they match then allow
the client to login. This would be an improvement over the current model
as it prevents a plain text password from crossing the network and keeps
it stored in a secure form on the server.

Mark Benvenuto