Date: Sat, 19 Jan 2002 17:40:43 +0000 From: Mark Murray <mark@grondar.za> To: "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: Kris Kennaway <kris@obsecurity.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpam/modules/pam_opie pam_opie.c Message-ID: <200201191740.g0JHeht22808@grimreaper.grondar.org> In-Reply-To: <20020119165553.GF10976@nagual.pp.ru> ; from "Andrey A. Chernov" <ache@nagual.pp.ru> "Sat, 19 Jan 2002 19:55:53 %2B0300." References: <20020119165553.GF10976@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sat, Jan 19, 2002 at 16:29:46 +0000, Mark Murray wrote: > > If the sysadmin turns on OPIE for a particular facility (like say, ftpd) > > then there MUST be an OPIE challenge for all users (except perhaps root > > Why not for root? Er, "perhaps root". This is a policy decision that would be up to the sysadmin. > > and the anonymous user). That way, the external user gets much less info > > about the internal security arrangements (like who is using OPIE, and who > > may be using (insecure) unix passwords). The less you tell the attacker, > > the better. If that means giving a bogus OPIE challenge for a user who > > has no OPIE enables, then that is GOOD, because it gives the attacker > > something bogus to chew on. > > > > The fact that this may be open source is irrellevant. With the external > > attacker, the contents of /etc/ are still partially protected. > > But from standard CD installation there was the same default range (i.e. > month) appearse in most of /etc/'s which admins use default rules or > think that this parameter is not important. So lets choose another system based on system constants: HASH(`hostname`|month($date)|UID|$IPADDR). With a very small amount of effort, this can be done with ease. > Well, this discussion is pointless, because we not discuss a real thing, > i.e. I see no implementation code for this thing yet. Lets continue with > some real code in hand. > > PLEASE NOTE > > That my change is unrelated to that because the old method used gains > nothing even from your point of view, so my change must stay in, at least > until replacement appearse. No. I object on the grounds that this code is worse than the old. Agreed that the old code could do with some improvements, but the improvements are built from that old base, not the current code. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201191740.g0JHeht22808>