1996-11-18 - Re: RFC: A UNIX crypt(3) replacement

Header Data

From: The Deviant <deviant@pooh-corner.com>
To: “Joshua E. Hill” <jehill@w6bhz.calpoly.edu>
Message Hash: 8b635a552bbd26a73130e3d328fbb4d5cd4a1a291ffd585316c8a8deb8eeacd7
Message ID: <Pine.LNX.3.94.961118000726.870A-100000@random.sp.org>
Reply To: <199611180000.QAA15865@hyperion.boxes.org>
UTC Datetime: 1996-11-18 00:11:57 UTC
Raw Date: Sun, 17 Nov 1996 16:11:57 -0800 (PST)

Raw message

From: The Deviant <deviant@pooh-corner.com>
Date: Sun, 17 Nov 1996 16:11:57 -0800 (PST)
To: "Joshua E. Hill" <jehill@w6bhz.calpoly.edu>
Subject: Re: RFC: A UNIX crypt(3) replacement
In-Reply-To: <199611180000.QAA15865@hyperion.boxes.org>
Message-ID: <Pine.LNX.3.94.961118000726.870A-100000@random.sp.org>
MIME-Version: 1.0
Content-Type: text/plain


On Sun, 17 Nov 1996, Joshua E. Hill wrote:

> > This is backwards logic; when security begins to hender in the
> > functionality of the system, the security needs to be gotten rid of.
> hmmm... Now that _completely_ depends on the system.  Now for the system
> I administer, the level of security really isn't _that_ high (on the
> grand scale of things).  It is, however, high enough that I inconvenience
> the users with a pro-active password guesser, and passwords that expire
> occasionally.  I suppose that this is a _minor_ inconvenience, but it
> raises the level of security a very large amount.  On a less mundane
> system (one run by the government, say), security is only _slightly_
> less important than being able to use the system in the first place. :)
> On this type of system almost any inconvenience is worth the cost.
> 
> > > You have previously said that the passwd file should not be available 
> > > for public consumption.  Though this is certainly true, it does not
> > > hurt that even if the passwd file is available, nothing particularly 
> > > useful can be done with it.
> > Hince you use pseudorandom password generators and crack.  If you count on
> > somebody not being able to preform an opperation quickly, they'll usually
> > prove you wrong.
> 
> whoa... didn't you just say:
> > when security begins to hender in the
> > functionality of the system, the security needs to be gotten rid of.
> I think that psedu-random password generators would almost certainly
> "hinder in the functionality of the system"...  :-)
>

Sorry, we place different values on "hinder"... when I say hinder, I mean
get in the way.  Last I checked, a faster machine gets more work done.
Sure, technicly having a password at all hinders usage of the system, but
there is still such thing as necisary evil.  I think trying to develop a
password routine that is deliberatly ineffecient is a Bad Thing though.

> 
> I want to make it so that users can use passwords > 8 characters, and I 

That I can agree with.

> want to use something a bit better than FreeBSD's solution.  Whether or 
> not this is necessarily the One True Way (TM) to security, it will increase
> security.  I'm not saying "Hey everyone.  Here is a spiffy new password
> system that will make your entire system completely secure!"  I'm saying
> "Could everyone please look at this algorithm that I'm thinking of using.
> Could you please comment on it, so that I can make it better."  That's it.
> All questions on whether or not passwords should shadowed, crackable,
> not crackable, or consisting only of the letter "e", aside.  Is this
> algorithm secure, and if not, why not.

Ok, I see your point; I still think its not worth the effort.

> 				Joshua

 --Deviant
Horse racing *is* a stable business ...







Thread