Date: Sat, 19 Jan 2002 06:23:15 -0800 From: Kris Kennaway <kris@obsecurity.org> 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: <20020119062315.A78025@xor.obsecurity.org> In-Reply-To: <20020119134810.GB9275@nagual.pp.ru>; from ache@nagual.pp.ru on Sat, Jan 19, 2002 at 04:48:10PM %2B0300 References: <200201191009.g0JA95b91076@freefall.freebsd.org> <20020119042808.A67985@xor.obsecurity.org> <20020119123903.GA8776@nagual.pp.ru> <20020119124322.GB8776@nagual.pp.ru> <20020119053506.A77530@xor.obsecurity.org> <20020119134810.GB9275@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 19, 2002 at 04:48:10PM +0300, Andrey A. Chernov wrote: > Now back to unreal method you suggest. Just think about keeping=20 > internal state for every possible 16-letters (user name) combination and= =20 > regenerating it once a week. Nothing to it; you'd store a few bytes in /var/run or somewhere, and hash them with the provided username to generate the fake challenge. > > 2) If you don't fully understand the PAM code, as you admitted in an > > earlier email, then it's surely very easy to introduce inadvertent > > security vulnerabilities, and you should be a responsible enough > > programmer to solicit review without me having to tell you to. >=20 > This is not PAM code area, many non-PAM OPIE applications, f.e. from=20 > ports, already do that way, i.e. not print out fake responses generated. > Since weh have PAM defined by default, this is OPIE area. Again, in 2) I'm not talking about the _way_ you changed the behaviour of PAM, but the fact that you made a not-completely-trivial change to the behaviour of PAM at all (without review). PAM is a fearsome beast, and if you accidentally screw up the behaviour of a PAM module with an otherwise well-intentioned change, you can easily blow a hole in the side of the entire FreeBSD remote security model. That's why you need to get reviews; not (necessarily) the results of the change, but the details of how you implement the change in PAM, to make sure it doesn't have other nasty consequences you didn't intend. Kris --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8SYFTWry0BWjoQKURAlOnAJ9PAJqyaqfejDs6tNsmInWnpAOkowCgmnuo /xhSKoQ6haU6NQBD1wW3XCA= =hbBL -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- 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?20020119062315.A78025>