open-source cryptocard libraries

Ken Hornstein kenh at
Tue Jan 23 15:38:56 EST 2007

>Back to what works today, assuming the PIN isn't compromised, 6-7 digits
>plus a 5-6 character PIN is probably good enough for most folks. (?)

I would agree on that for some people, assuming you had reasonable
quality checking or a good verification process on those PINs.  We
have at least 9 characters for passwords plus a strict quality checker
and regular passwords changesss added to our 32 bits of entropy we
get from the CRYPTOCard.

>I guess at this point it's really like having a password and an OTP

Yeah ... the advantage of PIN + OTP is that you could just do a regular
AS_REQ/AS_REP without the SAM protocol at all if you wanted.  But that
would make doing a window of responses harder (I guess if you did
timestamp preauth you could cook something up).  And that would make
my trick about using the sam-track-id to stash a KDC cookie not work.

Decisions, decisions ...

>Which makes me think of something else.  If you use hardware tokens
>because you are worried about a password compromise, then if you have
>a short OTP, ie one where use-sad-as-key is a problem, even the default
>(good) mode of SAM does not protect you from either a replay attack (if
>OTP is not synced to backup KDC) or from an online guessing attack or
>from a snooping attack.  I am talking about the case where a password
>might be known or LEARNED, not the case where a weak password might be
>GUESSED.  In the password-is-guessable case, the OTP does protect the
>password to some degree.
>Do you agree?

Yeah ... but I guess it depends on your definition of "short" when it
comes to OTP strength.  I am personally not happy with even 40 bits of
entropy when it comes to keying material for the AS_REP, but it's better
than nothing (and it might even be better than some passwords).

I don't like to depend solely on the OTP, but probably the user's
password is compromised in some cases out in the wild.  At least being
combined with the OTP there is some protection, and we do implement
regular password changes; I think given the limitations that we're
faced with, it's the best we can reasonably do.  Sigh, everything is a


More information about the krbdev mailing list