[MUD-Dev] TECH: Securing Symetric Encryption.

[Amanda Walker]

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

> 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. The encrypted random key is sent to
> the client. The client who should already know their password
> decrypts the random key. The client then uses this random key to
> encrypt a login message that does not contain their password. The
> random key encrypted login message is sent to the server. The
> server then uses the random key it generated earlier to decrypt
> the login message. Finally if login message is sucessfully
> decrypted, then the server knows that client was able to decrypt
> the random key and therefore knows the password.

This is a variation of a common authentication approach called
"challenge/response".  Most systems use a somewhat simpler approach:

  User opens connection, supplies user name

  Server sends back a random challenge string

  User encrypts challenge string with password, sends as response to
  server

  Server encrypts challenge string with stored password, compares
  with user response

This gives the same level of assurance as your method above, but
involves fewer steps.

> The weaknesses that I am aware of are

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

Well, yes.  To some extent, this is unavoidable.  There are
variations that avoid having to store the password in a recoverable
form on the server, however.  These are generically called "one time
password" (OTP) systems.  S/Key was the first that I'm aware of.
They are slightly more computationally intensive than a simple
challenge-response system, but not by much, and are great if you
want/ need to protect passwords against server compromise (for
example, if you're using a hosting service).

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

This is always true if you're only relying on single factor
authentication (i.e., something someone knows).  Two-factor
authentication (something someone knows + something they have, like
a smartcard or fingerprint reader) is more secure, though I don't
know of any game that uses it.

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

If you're thinking about using cryptography for authentication or
encryption, I strongly recommend picking up a copy of "Applied
Cryptography" by Bruce Schneier.  It's a very complete intro to the
topic, written for people who are not already familiar with it.  It
also contains sample code.

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

That depends on your threat model.  Generally speaking, an
authentication scheme should not depend on the source code being
secret.


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