[19173] in Kerberos
Re: Apps aquiring tickets (was Re: gssapi/openssh)
daemon@ATHENA.MIT.EDU (James F.Hranicky)
Fri May 2 11:34:22 2003
Date: Fri, 2 May 2003 11:33:30 -0400
From: "James F.Hranicky" <jfh@cise.ufl.edu>
To: kerberos@mit.edu
Message-Id: <20030502113330.6c08c5f2.jfh@cise.ufl.edu>
In-Reply-To: <3EB28936.8C5B209C@anl.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Fri, 02 May 2003 10:05:26 -0500
"Douglas E. Engert" <deengert@anl.gov> wrote:
> You are asking for trouble if any application can ask the user to
> enter their password at any time. They will, and will try all of
> their passwords if they have too. Better to train them to entry it
> only specific times, like login, and be suspicious if any application
> asks for their password.
Even a standard, well documented one?
Users of Kerberized apps have to "do something" when the TGT expires, why
not let them be prompted?
This sort of social engineering can happen whether or not "kinitd" exists,
so why not train them to *only* input the password when the kinitd pops
up the prompt?
I would surmise that the likelihood of someone popping up a trojan prompt
is roughly equivalent to the likelihood of someone replacing the kinit
binary itself.
> Kerberos does this.
Well, it can do this, or apps can set their own with the KRB5CCNAME
env variable. I submit with 2), you wouldn't need to do this nearly
as often.
> > 2) the ticket cache could contain TGTs for multiple realms
Jim
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
