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