I never got a reply to this (presumably it was lost in the flurry of other mails I send! :), but it seems like storing a keytab is the best thing to do for this situation.
However, I've hit a snag: when creating a keytab on the client using the code from ktutil as a reference, how do I know what kvno to use? In other words, the client might have changed his or her password multiple times through my web interface, so I have no way to know what the latest kvno for the key should be. Do I have to do an init_creds_password and get the key/kvno/etc from the cc, rather than creating it myself? That greatly complicates things, since I'm doing all KDC communication asynchronously on another thread...my login state machine is getting a little crazy... Hmm, wait, can I even do that? The kvno's in the ccache are from the ticket's server's key...yeah, I just tested this... Okay, from looking at kvno.c, if I get creds with myself as the server, then that will have the kvno of my latest key. But, I have -allow_svr set on clients, so I guess I have to do u2u creds to myself...argh, no, I just tested this, and the kvno is 0 for a u2u ticket. What can I do to get the latest kvno for a client with -allow_svr set, or more generally, how can I create a keytab on the client with the latest kvno? I really don't want to write another service to fetch the kvno. Chris On 2011/07/24 02:33, Chris Hecker wrote: > > This is my last mail tonight, I promise! > > Okay, so I know the best answer to "What's the best way to store the > user's password on his or her machine?" is "Don't!" > > However, the reality of my industry is security is somewhat important, > but usability is very important, so I need to find the right balance. > > Basically, the goal is to have somebody click on the game's icon and be > playing immediately, and they should only have to enter the password > once unless they decide (or I force them) to change it. > > It seems like the best way to do this is store the password on the > user's machine. Since you're not supposed to store passwords in > plaintext, it seems the best way to store the password is to use a > keytab to store the key, since it's already salted and hashed and ready > to be used by krb5_get_init_creds_keytab and I don't have to do any work. > > The only other alternative I could think of was to use long-term > renewable tickets, but that requires the user to actually run the game > every day to renew tickets if I have 24h lifetimes on the tickets, which > is a non-starter. I don't want to have longer than 24h tickets since > short-lived tickets seem to be core to the Kerberos security model. > > Storing the keytab, plus figuring out how to disable accounts at the KDC > seems like it's the right mix of security, user control, and > accessibility. If the client's machine is hacked, the bad guys only get > the one key, and I disable the acount. > > Thoughts? Am I missing a better solution? > > Thanks, > Chris > > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
