MOO-cows Mailing List Archive


Peculiar security problem

> From: Andy Selle <>
> Date: Sun, 14 May 1995 08:25:40 -0500 (CDT)

> > > Date: Sat, 13 May 95 17:31:16 -0800
> > > From: Alex Stewart <>
> > 
> > > Listen, morons.  [...]

> > > everyone calling it a bug and posting idiotic "solutions" [...]

> > > WORK. 
> > 
> > And it's poor design.

> It isn't a poor design.  It is so that if the password property gets 
> accidently set to a non string value the person is still able to login.  

While I see the utiltity of that design, I don't want that particular
safety net.  I think there are two camps here: those who think the
password system should "fail open", and those who think it should
"fail closed".

> Without this feature there could be bad results.  Say you are the arch 
> wizard of  a MOO and there are no other wizards.  Say you have a program 
> that accidently sets the password property to a list.  You can't login.  

... without killing the MOO and editting the DB by hand.  I would make
that tradeoff to keep the password system from failing open.

> Also, if you don't like something you can 
> change it, but don't go around telling everyone it is stupid. 

I'm sorry if my words "poor design" were considered insulting to
someone on a personal level.  It was not my intention.

I called it "poor design" because I thought it wasn't self documenting
code (i.e., I saw no "candidate in children($guest)" anywhere in the
code) and because the failure mode is to widen access rather than
restrict it.

> This is not meant to be a flame.

Thanks.  I'm also trying to keep the signal-to-noise ratio as high as
Francis Litterio   
02 37 DF 6C 66 43 CD 2C
10 C8 B5 8B 57 34 F3 21      PGP-encrypted email preferred

"Those that give up essential liberty to obtain a little temporary 
 safety deserve neither liberty nor safety." -- Benjamin Franklin (1773)

Home | Subject Index | Thread Index