open-source cryptocard libraries
Ken Hornstein
kenh at cmf.nrl.navy.mil
Tue Jan 23 10:14:32 EST 2007
>> And how would the attacker know what the old cryptocard response is?
>
>By brute forcing the AS_REQ. If use-sad-as-key is set, game over.
>If send-encrypted-sad is set, it's probably better, but presumably
>you use hardware preauth to prevent against weak passwords. But
>in the case where a weak password can be guessed, send-encrypted-sad
>makes the hardware auth superfluous if it can be replayed. Both
>of these cases are actually noted (to some degree) in the SAM draft.
I know these are all issues with SAM ... but we were specifically
talking about CRYPTOCard, and of course in that case neither
use-sad-as-key nor send-encrypted-sad is used (well, you _could_ use
send-encrypted-sad, I suppose, but there is no need ... and it's not
clear to me if the MIT codebase supports use-sad-as-key). So, I still
stand by my original statement ... if you're using SAM with CRYPTOCard
_properly_ then there is no issue with replaying an exchange against
another KDC. If you are really paranoid, I can think of a simple fix:
place inside the sam-track-id the hostname or some other KDC-specific
identifier, and have the KDC check that when it processes the preauth
data.
>In any case, my company, TRI-D Systems (www.tri-dsystems.com) solves
>this problem with a kdc plugin to talk to our server (otpd) which
>then handles all the OTP stuff including global token state mgmt
>and safe to use in use-sad-as-key mode. Thus giving the possibility
>to eliminate user passwords altogether but without the difficulty
>of a smartcard/PKI deployment.
Hm. My big issue with use-sad-as-key is that none of the tokens I have
seen have enough entropy where I would be comfortable using them as the
only source of keying material (e.g., the CRYPTOCard only gets you 32
bits best-case). Do you guys have a solution to that? If so, that
would be pretty cool.
>*AND* probably more usefully, it allows you to use the same OTP
>device across multiple authentication technologies.
I agree, that does sound nice.
--Ken
More information about the krbdev
mailing list