[MUD-Dev] TECH: Securing Symetric Encryption.

[Jeff Bachtel]

On Thu, Jul 14, 2005 at 10:33:33AM -0400, William Leader wrote:

> I was brainstorming about this and I was hoping someone could
> check my logic. I want to be able to secure the connection between
> a client and server using encryption. Now from a technical
> perspective I know that an Asymetric system is best because you
> don't have to worry about sending keys over the network in plain
> text, but lets assume for the discussion that Asymetric encryption
> is not an option (mainly because I don't want the hassle of
> managing key pairs).

I'll reply to technical considerations of your proposal below, but
let me just say: use asymmetric (public key) encryption. Consider a
web browser. Hundreds of banks allow their customers to securely
access their bank accounts with a target audience arguably less
computer literate than the typical gamer. Use OpenSSL, generate a CA
certificate for use by your game, and just distribute it with the
game. Sign your server's SSL key with that CA cert, and your game
clients can securely connect to your game server (and be somewhat
assured they are connecting to your server. You get the added
benefit of having a secure channel established for anything you
might need in-game. The concepts and code for this aren't overly
difficult.

> What I needed was a way to make the login message different every
> time. The following is what I came up with and I hope to get help
> on. When a user first connects they send a message to the server
> contianing thier username in plain text. The server then looks up
> the user in a database and loads that users password. The server
> also generates a random key. The server then encrypts the random
> key with the users password.

In general, this is a bit backwards and you don't really want to be
sending out streams that can easily be captured and used to retrieve
the user's password, especially when you don't even know it is the
proper user connecting (that extends a vulnerability to snooping
even further).

So, roughly speaking:

  Client: Hello
  Server: Hello. Foo-1, Bar-2
  Client: Encrypt(Hash(Bar-2&Password), Hash(Foo-1&Password)) , Username
  Server: OK

> The advantages of this processes from my perspective are:

>  1) common packets are different with each session because they
>  are influenced by random input.

>  2) the user password is never sent in any form.

>  3) high power asymetrical algorithms like AES (Rijndael) are
>  suitable.

>  4) No management or generation of key pairs.

> The weaknesses that I am aware of are

>  1) Both parties must know a password ahead of time

>  2) The password is vulnerable when sent by mediums such as email

>  3) I don't know enough about encryption to know what other flaws
>  may be.

>  4) In my implementation the Initialization Vector is easily found
>  in the open source code. (Is this a problem?)

The bigger problem is that that vector is constant, and there's no
reason it couldn't be part of the encrypted payload in your original
design.

> Any encryption experts out there willing to point out a weakness
> that I don't already know about or comment on the severity of the
> weaknesses I do know about?

I'm not by any stretch an expert. Sometimes when I want a raise,
I'll call myself a "security expert". That said, I know enough to
let others do my thinking and implementation unless there is an
overwhelming reason to do otherwise.

If you aren't willing to use SSL (I so highly recommend it it
hurts), then I would suggest checking out http://srp.stanford.edu/
. That project addresses exchanging credentials in a secure fashion
much better than your original design (and much better than my note
on correct message order).

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