Bug 20909

Comment 1 Sheldon Hearn 2000-08-29 09:57:31 UTC

Responsible Changed
From-To: freebsd-bugs->kris

Kris, you committed Jim's pam_opie.c.  The patch seems to 
make sense.  Could you take a look or coordinate with Jim?

My apologies for not drinking more coffee before submitting my report, but
the patch I sent is wrong.  I didn't describe the exact nature of the
problem--please let me clarify...

The pam_opie module doesn't handle the echo_pass PAM option properly.  The 
module always allows password echoing at the second prompt if the user types
<return> at the first prompt.  If you add "echo_pass" as an option for the
module in /etc/pam.conf, it will echo the password at both prompts.  Correct 
me if I'm wrong, but my understanding is that under normal conditions
password echo is supposed to be off unless the "echo_pass" option is 
specified.

The new patch (included below) implements the following behavior:  the
first prompt never echos the password, but if the user types <return> and
"echo_pass" is set in pam.conf, a second prompt will be displayed that
echos the password.

Thanks,

Mike


Index: pam_opie.c
===================================================================
RCS file: /sbox/freebsd/cvs/root/src/lib/libpam/modules/pam_opie/pam_opie.c,v
retrieving revision 1.1
diff -u -r1.1 pam_opie.c
--- pam_opie.c	2000/04/17 00:14:42	1.1
+++ pam_opie.c	2000/08/29 18:01:29
@@ -74,13 +74,12 @@
 	if (opiechallenge(&opie, (char *)user, challenge) != 0)
 		return PAM_AUTH_ERR;
 	snprintf(prompt, sizeof prompt, "%s\nPassword: ", challenge);
-	if ((retval = pam_get_pass(pamh, &response, prompt, options)) !=
-	    PAM_SUCCESS) {
+	if ((retval = pam_get_pass(pamh, &response, prompt,
+	    (options & ~PAM_OPT_ECHO_PASS))) != PAM_SUCCESS) {
 		opieunlock();
 		return retval;
 	}
-	if (response[0] == '\0' && !(options & PAM_OPT_ECHO_PASS)) {
-		options |= PAM_OPT_ECHO_PASS;
+	if (response[0] == '\0' && (options & PAM_OPT_ECHO_PASS)) {
 		snprintf(prompt, sizeof prompt,
 			 "%s\nPassword [echo on]: ", challenge);
 		if ((retval = pam_get_pass(pamh, &response, prompt,

Comment 3 Kris Kennaway 2000-09-02 03:00:31 UTC

On Tue, 29 Aug 2000, Michael Kiernan wrote:

>  The pam_opie module doesn't handle the echo_pass PAM option properly.  The 
>  module always allows password echoing at the second prompt if the user types
>  <return> at the first prompt.  If you add "echo_pass" as an option for the
>  module in /etc/pam.conf, it will echo the password at both prompts.  Correct 
>  me if I'm wrong, but my understanding is that under normal conditions
>  password echo is supposed to be off unless the "echo_pass" option is 
>  specified.

I think this is valid behaviour: it accords with the behaviour of other
OTP utilities. The reason it echos on the second attempt is because
(depending on how it's set up) you can either log in with a unix password,
or a one time password (that is echoed back to you so you can confirm the
passphrase) by just pressing enter the first time. echo_pass is intended
for when you want it to always echo the passphrase because the utility
doesnt use non-OTP authentication.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>

Hello Kris,

You wrote:
> I think this is valid behaviour: it accords with the behaviour of other
> OTP utilities. The reason it echos on the second attempt is because
> (depending on how it's set up) you can either log in with a unix password,
> or a one time password (that is echoed back to you so you can confirm the
> passphrase) by just pressing enter the first time. echo_pass is intended
> for when you want it to always echo the passphrase because the utility
> doesnt use non-OTP authentication.

I had assumed that the echo_pass option was meant to alter the behavior from 
echoing turned completely off to echoing turned on only for the second prompt. 
Thank you for clarifying this.

Mike

I agree with Kris that the behaviour is as designed.  It should agree with
pam_skey (one of the other OTP utilities) upon which this module was based.

Kris, it sounds like Michael accepts the explanation (according to his
subsequent e-mail) and this PR can be closed.

Jim Bloom
bloom@acm.org


Kris Kennaway wrote:
> 
> On Tue, 29 Aug 2000, Michael Kiernan wrote:
> 
> >  The pam_opie module doesn't handle the echo_pass PAM option properly.  The
> >  module always allows password echoing at the second prompt if the user types
> >  <return> at the first prompt.  If you add "echo_pass" as an option for the
> >  module in /etc/pam.conf, it will echo the password at both prompts.  Correct
> >  me if I'm wrong, but my understanding is that under normal conditions
> >  password echo is supposed to be off unless the "echo_pass" option is
> >  specified.
> 
> I think this is valid behaviour: it accords with the behaviour of other
> OTP utilities. The reason it echos on the second attempt is because
> (depending on how it's set up) you can either log in with a unix password,
> or a one time password (that is echoed back to you so you can confirm the
> passphrase) by just pressing enter the first time. echo_pass is intended
> for when you want it to always echo the passphrase because the utility
> doesnt use non-OTP authentication.

Comment 6 Kris Kennaway 2000-09-17 06:48:43 UTC

State Changed
From-To: open->closed

The submission has been analyzed and determined to be correct 
behaviour.