client side password store best practices?

Chris Hecker checker at d6.com
Sun Jul 24 05:33:04 EDT 2011


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





More information about the Kerberos mailing list