storing tickets in memory

[Markus Moeller]

I think the problem is the trust you have to the owner of the device you use
to authenticate yourself. If it is not your own you have lost as the owner
can put any type of keystroke logger on to it to catch your password in
clear. This might be less of an issue if you use a smartcard and pkinit to
authenticate. Yes then I agree the credential cache in /tmp is an issue (but
as mentioned earlier a memory cache doesn't help either), especially if the
credentials have a long validity time. Access to the credential cache of a
user means you can login to the systems this user is authorised to without
knowing their password. kinit -k keytab uses the keytab details for
authentication.

Regards
Markus

"Donn Cave" <donn at u.washington.edu> wrote in message
news:donn-6A68D6.13243010062004 at nntp2.u.washington.edu...
> In article <21E548A5-BB02-11D8-AA2F-000A95909EE2 at mit.edu>,
>  raeburn at MIT.EDU (Ken Raeburn) wrote:
>
> > On Jun 10, 2004, at 09:11, Adam Denenberg wrote:
> > > ok thanks for the info.  I did some reading and was basically thinking
> > > of implementing kerberos here on our unix systems but read about some
> > > security concerns about ticket credentials being stored in /tmp.
> > > Meaning anyone with root can become another user and steal his/her
> > > credentials.  How do people deal with this security issue?
> >
> > By realizing that unless your OS significantly curtails the access
> > granted to root, the root user can look at users' shared memory
> > segments and local process memory, or run processes as the target user,
> > or modify system software to do things the users don't intend; so
> > basically, the game is over once the bad guy gets root access.
>
> I think there may be two questions here.  One of them is
> your bad guy scenario, which I suppose applies just as well
> to my personal NetBSD desktop computer as to a host in the
> basement with thousands of accounts.
>
> The other is about per host level of assurance, where we
> assume that every host's administrator is to some level a
> bad guy.  Take for example a university campus -- many
> departments will maintain their own sites, with a vast
> range of security policies, and then there will be a lot
> of one-of-a-kind hosts run by some professor's graduate
> student, dormitory residents, who knows what all.  People
> on campus are using these hosts, usually several of them
> if any, and we would like to think that their access to
> a residence hall computer wouldn't compromise their account
> on the central site financial database.
>
> I think this is actually a strong point of Kerberos
> authentication, relative to the alternatives, because
> you _don't have_ credentials on the remote host, so
> it sort of doesn't matter what happens to you there.
> Only the data you actually send to that host, or get
> back from it, can be compromised, and your credentials
> are not part of that data stream.  (I wish that were
> easier for people to understand.)  In contrast, if you
> use ssh or SSL to encrypt your password, for example,
> it's going to be unencrypted on the remote end, and
> your primary authentication key is utterly exposed to
> the remote host's administrator.
>
> So it seems to me, to answer `How do people deal with
> this security issue?', I would start by asking, why is
> it an issue?  Why does your user have credentials on
> this host?  Maybe there's a good reason, like it's the
> user's workstation which is obviously where the credentials
> are going to be, but just to be aware that not every host
> that plays the Kerberos game keeps user credentials.
>
> And of course then there's the Kerberos authenticated
> filesystem, but I don't know that can of worms/garden of
> delights by experience.
>
>    Donn Cave, donn at u.washington.edu
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>