From owner-cvs-lib  Fri May 10 09:28:23 1996
Return-Path: owner-cvs-lib
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA02774
          for cvs-lib-outgoing; Fri, 10 May 1996 09:28:23 -0700 (PDT)
Received: from wzv.win.tue.nl (wietse@wzv.win.tue.nl [131.155.210.17])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA02674
          Fri, 10 May 1996 09:28:04 -0700 (PDT)
Received: by wzv.win.tue.nl (8.7.4/1.45)
    id QAA07329; Fri, 10 May 1996 16:27:58 GMT
Date: Fri, 10 May 1996 16:27:58 GMT
From: wietse@wzv.win.tue.nl (Wietse Venema)
Message-Id: <199605101627.QAA07329@wzv.win.tue.nl>
To: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org,
        cvs-lib@freefall.freebsd.org
Subject: Re: cvs commit:  src/lib/libskey skeylogin.c
Cc: wietse@wzv.win.tue.nl
Sender: owner-cvs-lib@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

This change seems to miss an important point: the file /etc/skeykeys
contains the last S/Key password used.

The primary reason for using S/Key is that passwords may be sniffed
from the wire. When intruders can sniff the S/Key password from the
wire, there is little point in keeping it in a secret file.

If you're worried about dictionary attacks on one-time passwords, it is
better to adopt a scheme that is based on pseudorandom numbers, such as
SecureNet keys or other.

	Wietse

>   Modified:    lib/libskey  skeylogin.c
>   Log:
>   /etc/skeykeys was basically suffering from the same vulnerability
>   as any non-shadowed /etc/passwd.  Ironically, all programs using S/Key
>   have already been setuid root except keyinfo(1).
>   
>   This modification creates /etc/skeykeys with mode 0600 to prevent it
>   from being examined by ordinary users.
>   
>   Revision  Changes    Path
>   1.7       +3 -1      src/lib/libskey/skeylogin.c