From owner-freebsd-security Thu May 21 17:06:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA04746 for freebsd-security-outgoing; Thu, 21 May 1998 17:06:14 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA04633 for ; Thu, 21 May 1998 17:05:49 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id UAA00936; Thu, 21 May 1998 20:05:20 -0400 (EDT) (envelope-from wollman) Date: Thu, 21 May 1998 20:05:20 -0400 (EDT) From: Garrett Wollman Message-Id: <199805220005.UAA00936@khavrinen.lcs.mit.edu> To: Philippe Regnauld Cc: freebsd-security@FreeBSD.ORG Subject: SKey and locked account In-Reply-To: <19980521183148.07894@deepo.prosa.dk> References: <19980521183148.07894@deepo.prosa.dk> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk < said: > 1) First thing I noticed is that it's possible for someone to log > into the system, even if the account is disabled ('*' in the > passwd field), when S/Key is enabled for that user. Having an invalid password in the password file doesn't mean that the account is disabled; it just means that that user can't use a plain-text password to log in. Several of us have invalid passwords on freefall since we always use an alternative authentication mechanism like S/Key. It might not be a bad idea to use the login class mechanism to define a specific class meaning ``disabled'' -- as distinguished from the ``account expired'' we can already represent in master.passwd. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message