Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!uunet!shelby!SNLL-ARPAGW.LLNL.GOV!hilary
From: hilary@SNLL-ARPAGW.LLNL.GOV (Hilary Jones)
Newsgroups: comp.protocols.kerberos
Subject: Re: Storing tickets safely
Message-ID: <9103040022.AA13931@snll-arpagw.llnl.gov>
Date: 4 Mar 91 00:22:28 GMT
Sender: news@shelby.stanford.edu (USENET News System)
Organization: Internet-USENET Gateway at Stanford University
Lines: 45


	
>Whether or not tickets are stored in the Kernel or in a file is not a
>function of Kerberos, but of the system platforms that run Kerberos....
>However [...] it should not be hard to implement a ticket cache
>abstraction that uses it.
	
I was hoping that the next release of Kerberos would in fact have some
form of ticket caching that didn't depend on the file system.  Perhaps
some sort of shepherd process so that Kernel mods wouldn't have to be made.
Without this, I still think the ticket is just a glorified password.  I will
admit I am being the gadfly here, but this is the one part of Kerberos that 
I haven't completely bought off on.
	
Besides, if it's easy to implement a ticket cache, it should be trivial
to implement a plaintext password cache and do away with Kerberos
altogether.  (I realize that Kerberos solves other security problems, so
I am not being serious, just argumentative :)

>It *is* more secure to only store the ticket rather then the password.

Yes, but not a whole lot more secure.  And if you allow infinitely long
lived tickets, then the difference goes away completely.  Admittedly my
users shouldn't ask for long-lived passwords, and I should enforce that.
But then one of the biggest advantages of Kerberos goes away for my users.
Namely, they won't be able to run batch jobs that may take many days to
run before needing a password.

>...point out that normal (many hour duration) tickets are *not* valid for
>*password* change requests. 

Yes, but a ticket thief isn't really likely to change my password.  I
will notice the problem, so he risks exposure while gaining almost
nothing, beyond annoying me.  [Come to think of it....]  So the issue
isn't whether the password is in plaintext or in an encrypted form like
a ticket; rather, it's whether a thief can use the information without
additional information.

Of course all of this is something of a pointless argument; the spy is
going to take over my workstation and gather my password as I type it,
and I am helpless to prevent that.  But I was hoping to make his job as
difficult as possible.  In particular, I was hoping that the protection
would be better than the protection one gives to a file containing a
password spelled out in plain text.  However, as Kerberos is currently
configured, that is not the case.