>> What I'm wondering is if the s/key reminder in the prompt may be used
>> to probe for valid usernames.  Isn't this a security hole, and if so,
>> how bad is it?  When I mentioned my concern to Luke, he mentioned that
>
>Yes, that's why I originally did it the other way. Of course it
>wasn't complete. ftpd still had to prompt, and you can still find out if
>the user is real or not[*] by entering "s/key" as the password, so it
>really doesn't buy much. I suppose you could forge a fake challenge,
>but it'd be hard to do in a convincing manner.

having the s/key reminder in the prompt doesn't tell you about
valid/invalid accounts, only those that do have s/key and those that
don't.  what's wrong with leaving it the way it is?  when asked for
the password, the user responds with "s/key" and is given the s/key
prompt.  otoh, the fake challenge, imho, wouldn't be that hard...

>[*: actually, it will tell you if a user does exist, but won't tell you
>if a user doesn't exist.  Maybe athere is no such user, or maybe the
>user just doesn't have an S/Key]

incorrect, i believe.  i may be wrong (since i'm not quite -current)
but it seems to me that if a non-user asks for s/key, they are simply
told login incorrect, but if it's an actual account with no s/key, then
they are told they have no s/key.  if this was changed to do the same
in all cases (ie, eliminate the info about s/key) you wouldn't be
giving any information away.

>> I think the password prompt should be enabled only if another option
>> (-S? -c? other suggestions?) is given.
>
>The whole S/Key implementation needs desperately to be thrown out and
>redone, preferably with plugin modules and a great deal more flexibility
>for the sysadmin (such as rules saying who can login in when, where,
>where from, and with what auth method, rather than the simple -s flag,
>which is really insufficent even for simple cases.  I have some thoughts
>on how to do this, if anyone is interested).  Failing that, if we're
>going to show the challenge all the time anyway, we might as well do
>away with the "enter S/Key at the Password: prompt" thing and do it like
>everyone else does it (and like ftpd does it).

controlling who can login when (many programs), where (meaning what?),
where from (controlled by tcpd?), and with what authentication method
(see below) are several not necessarily related issues.  while all
important issues in and of themselves, some solutions will be simple
and others, far more complex.  i prefer the "enter s/key ..." method,
but i think the error message for legitimate users who have no s/key
should be changed.  in the interests of security, the behavior of
login should not vary from allowing people in or saying "login
incorrect" (and logging a more verbose reason for the error).  these
errors that explain why are way too informative.

but since we're discussing the security aspects of the various error
messages from login, the first things i did to my login program were
(a) change the "root login disallowed" message to the generic "login
incorrect" and (b) have login syslog (when it logs success/failure)
which auth mechanism (unix, s/key, kerberos...) the person used.  this
is so i can tell which of my "users" is in line with my security
requi^H^H^H^H^Hrecommendations...

perhaps the ty_status values field (from /etc/ttys) should be extended
to have flags like TTY_UNIX and TTY_SKEY, so that one can control the
authentication mechanism used.  i would like to disallow any standard
unix password use on network terminals, but allow it on consoles,
similar to the way root logins are controlled, but i don't want
general overuse of the same flag.

bsdi has login configuration file called /etc/login.conf, but i think
it's a little overboard...

-- 
|-----< "CODE WARRIOR" >-----|
andrew@echonyc.com (TheMan)        * "ah!  i see you have the internet
codewarrior@daemon.org                               that goes *ping*!"
warfare@graffiti.com      * "information is power -- share the wealth."