By requiring ticket renewal, if the ticket is stolen you can prevent its renewal at the KDC. Renewal will also appear in the KDC logs so you will know where it is being used from.
In 1998 it took 45 days to brute force a DES key. 14 years later it probably takes under a day. On Friday, July 06, 2012 10:43:20 PM, Jayen Ashar wrote: > We have looked into the other tools, and: > > - with renewable tickets, is any security gained? a cracked/stolen > ticket can be renewed until the renewable lifetime, which seems not much > different to me than simply changing the expiration time. > > - with keytabs, what if the keytab is unknowingly cracked or stolen? > > we have some long-running processes, which we would like to be able to > read/write to afs beyond 30 days. some of these jobs may run on clients > we don't control, so we prefer to make changes server-side. we are > looking at options that offer convenience over security. we don't want > a user to come after us after six months saying he/she has to redo an > experiment because his token expired. > > why 30 days? does it take 30 days to crack DES? is there much > difference between 30 days and 300 days? > > we're less concerned about the ticket/token being cracked and more > concerned about it being stolen. while i agree the lifetime limits the > use of a stolen ticket, if a ticket can be unknowingly stolen once, it > can probably be stolen repeatedly. > > Thanks, > Jayen > > On 07/07/12 05:56, Brian Sebby wrote: >> The lifetime of a Kerberos ticket is a security measure to prevent someone >> from being able to use your credentials if they can crack your ticket/token. >> AFS still uses DES for its tokens, which is incredibly easy to crack these >> days. The limited lifetime is part of what prevents this from being an >> incredibly large security issue. If you have lifetimes that long, with DES, >> you might as well just run your servers with -noauth to turn off all >> authentication. (Please please please do not actually do this.) >> >> If you want long-lived tickets, look into using kinit -r, k5start, or any >> of the other tools for extending the lifetime of a ticket/token. >> >> >> Brian >> >> On Fri, Jul 06, 2012 at 06:44:46PM +1000, Jayen Ashar wrote: >>> On Fri, Jul 6, 2012 at 6:08 PM, Jeffrey Altman >>> <[email protected]> wrote: >>>> The code in question is tkt_DecodeTicket5() in src/rxkad/ticket5.c and >>>> tkt_CheckTimes() in src/rxkad/ticket.c. If the 'end' value is not >>>> exactly NEVERDATE (0xFFFFFFFF) and ('end' - 'start' is greater than >>>> 30 days, the token will be rejected. >>> >>> Can I do anything (without changing code) to make the end 0xFFFFFFFF? >>> As far as I can set, the end is only 0x7FFFFFFF. If not, is it >>> reasonable to change the 'end' - 'start' to 180 days? >>> >>> Thanks, >>> Jayen > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info
signature.asc
Description: OpenPGP digital signature
