[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Simple conversation function / linking w/ pam_pwdb



 
> Just a dumb question here.  Are you performing any encryption on that
> password?  If not, then both the old password and the new one will be
> broadcast all over the networks where the packets travel.  Anyone with a
> sniffer would be able to read the new password thereby compromising the
> account, and obviating the need for passwords at all.  You may want to
> take that into consideration.

	He  may be using PGP or  RIPEM  mail or  SSL  web pages (heck,
	maybe even S-HTTP --  if he could find a  client to support it) 
	to get the old and new passwords "in hand."

	He was probably talking about an 'expect' script that opens
	a telnet to localhost -- then attempts to login in using
	the (alleged) "old" password -- to then run the new password.

	This expect script would have to handle a few variations of 
	the user's shell (in particular the variation where the 
	user's shell *is* /bin/passwd -- which is a common part of 
	restricting users to non-interactive logins).

	A more subtle problem would be if he used the wrong CGI
	method (POST vs. GET).  One of these (I never remember which)
	stores the name/value pairs from a form in the script's 
	environment.  This is visible using the 'ps' command.

	I absolutely understand his desire to write such a 
	module/command -- since I've had similar requirements before.
	I don't like accomplishing this with SUID C programs or perl
	scripts, and the 'expect driven localhost telnet' method is 
	also a bit fragile and overly complicated.  So I'd like to 
	see a program that would accept to modes (verify and change)
	read its values via stdin and return a simple error code 
	(initial password wrong, new password not acceptable, no
	password changes allowed, inapprpriate authentication model
	etc).  

	In "verify" mode our program (which migh have to be SUID --
	or at least SGID 'passwd') would simply indicate whether the
	username/password pair was valid (useful for a number of 
	CGI, procmail, and administrative applications).  In "change"
	the program would check the validity and if that was O.K.
	would then attempt to change the passwd.

	The return values I've describe would mean:

		password wrong:   The authentication type was correct
				  but the password in hand was wrong

		inappropriate authentication method:	This account is
				locked out, or is configured for some
				sort of challenge response or other more
				complex authentication system.

			(Might separate "locked out" into a different
			code).

		new password not acceptable:	(change mode only)
				The authentication was fine but the new
				password was considered to weak for 
				that system's anti-crack policy.

		passsword change not allowed:	(change mode only)
				The authentication was fine but this
				system (or account) either doesn't allow 
				password changes -- or has a minimum 
				time between changes which has not been
				reached.

			(Might split that into two different codes)

		non-interactive pw not allowed:  
				This account does not allow this 
				non-interactive password verification 
				or change.  (Might configure 'root' 
				'news,' and other psuedo accounts for 
				this).

	This all could be a new program or (preferably) become a 
	set of extensions to the existing passwd program

	
> On Mon, 15 Sep 1997, Miguel A.L. Paraz wrote:
>> Hi,
>> 
>> I'm trying to create a PAM password changer for non-interactive changing,
>> for web-based and POP changers and the like.
>> 
>> I have been using expect but to talk to passwd over a telnet session 
>> but I've been having some bizarre problems with it.
>> 
>> Anyway, I'm trying to craft a conversation function to talk to pam_pwdb
>> based on pre-entered input, within variables.  We're not interactive here
>> since we have all the passwords already.  I'm basing it on the 
>> SimplePAMApps passwd.
>> 
>> However, when my conv function exists the first time, it segfaults.
>> I suspect it has to do with the handling of the pam_response**.  I
>> checked it against the source of misc_conv and it seems OK.
>> 
>> Does anyone have a similar function already?
>> 
>> Another alternative for debugging is statically linking it against
>> pam_pwdb. Any hint on how to debug this, or, recompile pam_pwdb
>> so that I can step into it for a clue?
>> 
>> Thanks,
>> 
>> -- 
>> Miguel A.L. Paraz                                +63-2-750-2288
>> IPhil Communications, Makati City, Philippines   http://www.iphil.net
> 
>+--------------------------------------------------------------------+
> Jason A. Pfeil                pfeil@cs.fsu.edu
> http://www.cs.fsu.edu/~pfeil FSU Computer Science Dept. System Administrator
>      "Search Engines are a great way to find out-of-date information."
>+--------------------------------------------------------------------+

--
Jim Dennis  (800) 938-4078		consulting@starshine.org
Proprietor, Starshine Technical Services:  http://www.starshine.org
        PGP  1024/2ABF03B1 Jim Dennis <jim@starshine.org>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []