Date: Mon, 25 May 1998 11:35:37 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-security@FreeBSD.ORG Subject: Re: SKey and locked account Message-ID: <199805251535.LAA05810@brain.zeus.leitch.com> In-Reply-To: Matthew N. Dodd's message of "Fri, May 22, 1998 12:35:15 -0400" regarding "Re: SKey and locked account " id <Pine.BSF.3.96.980522123353.17033i-100000@sasami.jurai.net> References: <Pine.GSO.3.96.980522112610.18198B-100000@echonyc.com> <Pine.BSF.3.96.980522123353.17033i-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[ On Fri, May 22, 1998 at 12:35:15 (-0400), Matthew N. Dodd wrote: ] > Subject: Re: SKey and locked account > > On Fri, 22 May 1998, Snob Art Genre wrote: > > How? I don't like this: isn't it standard practice across unixes to set > > a nonexistent shell to disable logins? POLA etc. > > I remember getting around this by ftp'ing a .forward file containing nice > things to reset my shell. Of course, this assumes that ftp is setup as to > allow logins for users with 'invalid' shells. Usually that's an accident (i.e. allowing ftp for users with "invalid" shells), sometimes based on a nasty but all too common misunderstanding about /etc/shells. Naturally /sbin/nologin should *never* be included in /etc/shells. If someone thinks they want it there then they really need to think of some other way to allow users to disable their accounts on their own! ;-) Unfortunately the shells(5) manual page doesn't mention this quirk related to ftpd [I'll file a PR if I remember when I have a spare moment]. Of course if you really want to disable a user's account then you should set their shell to /sbin/nologin, *AND* disable their password, either by adding some string such as "*NOLOGIN*" to the beginning of the field (in order to invalidate their current password but leave it intact), or simply replace the entire field contents with an invalid encrypted string, such as "*". Note too that SSH at one time did not correctly implement password field handling for invalid encrypted strings (and may still not do so) and in addition it (until the most recent release) revealed the existance of an account by giving a different response to an incorrect password. I've still not had time to examine the code to see that this was fixed on the server side either -- if not then a malicious client could still be used to probe for valid accounts. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805251535.LAA05810>