client side password store best practices?

[Chris Hecker]

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
>
>