In article <CMM.0.90.0.769416261.tls@panix2.panix.com> Thor Lancelot Simon <tls@panix.com> writes:
> Ty Sarna writes:
> >With these patches you can enter "s/key" at a {su,login} Password:
> >prompt and then be prompted for a s/key one-time password, or if you're
> >on a secure login you can just enter your regular password.
> 
> I don't think this is the right way to do things.  Why not just have
> /bin/login prompt for an s/key if you have one, and likewise for su?

Because I don't want to FORCE people to use S/Key all the time if they
don't want to.  Consider my own situation: I normally login in locally,
so I don't want to bother with S/Key in that case.  But I want to have a
key for when I log in remotely.  Also, once have a key there's no easy
way for me to get rid of it, so then I'd have to continue using S/Key
all the time, even for local logins.  Finally, by leaving the choice the
user is provided an "emergency exit", so if they absolutely need access
to their account and don't have prepepared keys or the key program
availible, they can use their regular password and risk it. 

> Actually, why keep the old NetBSD /bin/login hanging around, s/key patches or
> no?  Wietse's login package which comes with s/key is much nicer and has meny
> new security features, like a login.access file.

I wanted to make minimal changes to start with. If somebody wants to try
to get NetBSD's login replaced with Weitse's in the tree, they can go
ahead. I would ask that they change it to handle passwords like my skey
version does.

My ftpd changes also allow either S/Key or regular passwords, but handle
it slightly diferently.

> I have a fully working (except that I told it that netbsd used the wrong kind
> of rlogind) port of s/key 1.1b, plus a few local enhancements, for 0.9 or
> -current.  Gimme a day or so to clean it up if you want it, and everyone's
> more than welcome.

I finished up my port yesterday and sent it off to Theo, so hopefully it
can go into the tree soon. Mine's cleaned up and NetBSD-ized in terms of
directory structure and Makefiles.

> >the core team is agreeable...  I think that would be a Really Really
> >Good Thing, what with the recent spate of password snooping.
> 
> I still really, really hope that access to the master -current tree is
> controlled by one-time passwords somehow.  I still don't know if it is or not,
> but when it's so _easy_ to install and run s/key, I can't see any reason why
> everyone in the known universe oughtn't be using it -- operating system
> developers in particular.

Definately agreed...  sun-lamp people are at a high-risk for password
snooping, I'm sure, since access to the NetBSD tree for purposes of
adding trojans would be a valuable prize for a cracker.  Of course, Theo
probably wants to make sure I din't add my own trojans to S/Key before
he commits it or starts using it :-) You have to be careful when someone
sends you patches to things like login and su :-)

-- 
Ty Sarna	     "It pays to be obvious, especially if you have a 
tsarna@endicor.com    reputation for subtlety" -- Salvor Hardin

------------------------------------------------------------------------------