[39092] in Kerberos
Re: Always prompting for OTP
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue May 10 14:52:21 2022
From: Russ Allbery <eagle@eyrie.org>
To: BuzzSaw Code <buzzsaw.code@gmail.com>
In-Reply-To: <CAJhaRZ+i0O37fdzNzhg8PXzPtjeEgdmwv_hAT4m2hFv9VVqeoQ@mail.gmail.com> (BuzzSaw
Code's message of "Tue, 10 May 2022 14:40:41 -0400")
Date: Tue, 10 May 2022 11:49:23 -0700
Message-ID: <87pmklql3g.fsf@hope.eyrie.org>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
BuzzSaw Code <buzzsaw.code@gmail.com> writes:
> We want the full OTP+password string just passed without modification.
Ah, okay, so then in theory the problem could be solved entirely within
the Kerberos libraries, although I haven't wrapped my mind around the
problem Greg identified.
> It would also be nice if when we use
> try_first_pass/use_first_pass/force_first_pass options with pam_krb5
> that it actually did that in the OTP case without the extra prompt.
> no_prompt doesn't help as the password doesn't stay on the stack.
I'm assuming this is because the Kerberos library doesn't think that the
passed-in password can be sent after the FAST negotiation and therefore
re-prompts internally? I'm not sure I entirely understand the logic flow
here.
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
