[16901] in Kerberos_V5_Development
Re: gnome-keyring Obtaining a TGT without unrestricted access to
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jun 16 12:07:22 2011
MIME-Version: 1.0
In-Reply-To: <20110616154932.GE12572@mournblade.imrryr.org>
Date: Thu, 16 Jun 2011 11:07:16 -0500
Message-ID: <BANLkTinNN_=jx3dOYG=9rVCXaNB5O=gFGA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Roland C. Dowdeswell" <elric@imrryr.org>
Cc: Russ Allbery <rra@stanford.edu>, Guido G?nther <agx@sigxcpu.org>,
David Woodhouse <dwmw2@infradead.org>, stefw@collabora.co.uk,
krbdev@mit.edu, gnome-keyring-list@gnome.org
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, Jun 16, 2011 at 10:49 AM, Roland C. Dowdeswell <elric@imrryr.org> wrote:> How about the prevalence of userland programs that presume that> the presentation of a user's passwd indicates that the user is> actually sitting in front of the keyboard? There are many programs> that will intentionally reprompt for a user's passwd to perform> administrative or high risk activities. Examples that come to mind> are kadmin, kpasswd, sudo. This model is also used in enterprises> for high risk business transactions (frequently with pressure from> regulators).>> How does one square away the storing of a passwd in memory against> this existing prevalent use case? Other than simply transitioning> to OTP in order to defeat it?
You either ignore this problem or you use OTP or PKINIT withnon-extractable private keys stored in smartcards.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
