RE: Passwords (fwd)

[Arthur Chandler <arthurc@crl.com>]

  There's a thread on MOO-Cows -- a list primarily for folks interested in
the technical side of maintaining MOO databases (new releases of the core,
bugs in current core, questions about MOO-coding, etc.) -- that has to do
with passwords and encryption. It's been the fond hope of many people in
the MOO world that someone will come up with a kind of gateway that will
let players move from one MOO to another. There are lots of problems --
different ID numbers for the (essentially) same objects in each MOO,
different criteria for membership in different MOOs, etc. But one really
fundamental issue is: how can you use the same password to move from MOO
to MOO?
  I'm forwarding the essentials of the thread, plus one ambitious proposal
for solving the dilemma. Anyone here got any thoughts on the problem
and/or its solution(s)?



---------- Forwarded message ----------
Date: Thu, 14 Oct 1993 09:07:31 PDT
From: Off-path travel kills plants 14-Oct-1993 1122 <callas@eris.enet.dec.com>
To: "uso01@mailhost.unidata.com"@us2rmc.enet.dec.com
Cc: moo-cows.parc@xerox.com
Subject: RE: Passwords

    Somebody I know is trying to figure out a secure way to handle passwords in
    a MOO-to-MOO connection system.  The idea is to set it up so players can
    "walk" from MOO to MOO without worrying that their passwords are
    compromised.

    Something that occurred to me is that perhaps the first MOO could take the
    already-encrypted password of the player, and pass it to the second MOO. 
    Then a simple comparison to see if the encrypted passwords match.

    Does this work?

No!!!! It does not work, and as a matter of fact, it is worse than sending a
plaintext password.

The reason is that not only is your plaintext password a piece of valuable
information, but the encrypted password is, too. Possibly more valuable.

If you *merely* send the encrypted password, and then merely compare it against
what's in the database on the other side, then what you've done is manage to
reduce the problem of encrypted passwords to the previously solved problem of
plaintext passwords. All you're doing with the "encryption" is transforming the
plaintext password "alacazam" into "p9&5kgwqp%$3=l" which is less human
readable, but once snarfed off the net by an interloper, all they have to do is
hack up a client to send MOO2 a connect that says, "Hi, I'm an inter-MOO
connection, here's the encrypted password for Soandso." Poof, they're in.

If you want to have a secure login system you have to go to a little more work.
I'll describe a mechanism that is actually in place in a business oriented MUD
called "Meeting Space" today.

(1) Get yourself a 1-way hash algorithm. MD5 is good one. If you need MD5, send
me mail, I'll dredge it up for you. It's stuffed on my cognitive prosthesis
somewhere.

(2) The client to your MOO sends the server a message. The message says, "Hi, I
want to log in as Soandso."

(3) The server has in its database Soandso's password. The password has been
munched up with MD5 and also some random stuff, called "salt" in the trade.
It's there to simply make it harder for someone to grind up /etc/passwd and do
simple comparisons. The server sends back a message to the client that says,
"Cool. Do this for me. take the salt characters "fnord" and the string
"172355555" and grind them all up together, and send me back the answer. The
latter string is a quasi-random, non-repeating message. The easiest way to get
one of those is to call time() and turn it into a string. If you want to get
fancy, toss in some things like the number of pagefaults the system has done,
concatenated with the number of times that you've authenticated someone today,
and so on. The time is really good enough as it is, though tossing in the
number of times you've played this game makes it foolproof. The real point is
that you can't *ever* use this query again. How you construct such a message is
up to you. What you're doing is making a "one-time pad" in the lingo. 

(4) The client does all of this, using MD5 to grind up the plaintext password,
and the extra stuff (the client doesn't really need to know what the meaning of
the extra stuff is, it just has to grind it all up), and sends the server back
the result.

(5) The server mixes up the extra stuff with its already-hashed password and
compares the result to what the client sent. If they match, the client gets in.
If not, the server sends back a message that says, "No, sorry."

There are many other possible algorithms. The trick in thinking about them is
to assume that there are other people are listening. In our case, assume
there's an eavesdropper, with total knowledge of the algorithm. What have they
learned? Well, they learned what the system time on the server was. No harm in
that. They learned the client's password's salt. This is mildly irksome, but
only mildly. This potentially makes it easier for them to use a dictionary-
attack on the password, but not really. For anything that's really useful, it's
*far* easier for them to figure out how to hijack the whole database. All they
really know is that every time you log in, the magic question is going to have
a constant in it. Big deal.

Note that while not perfect, all forms of attack on this system involve both
hacking up a client and stealing the server's database. While not an
unattainable task, an authentication system like this is *more* secure than the
authentication system used to let you log into a privileged account on the host
operating system, even ones as reasonably secure as unix and VMS.

How's this, clear as mud?


Unsolved problems (left as an exercise to the reader):

(1) Securely changing Soandso's password in the presence of eavesdroppers.
	(very hard without a pubic-key crypto system)
(2) Managing the plaintext password on the client system (which is required
	here) so that it isn't compromised. (rather easy)

	Jon