[33639] in Kerberos
client side password store best practices?
daemon@ATHENA.MIT.EDU (Chris Hecker)
Sun Jul 24 05:33:16 2011
Message-ID: <4E2BE6D0.5090600@d6.com>
Date: Sun, 24 Jul 2011 02:33:04 -0700
From: Chris Hecker <checker@d6.com>
MIME-Version: 1.0
To: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
