There are really two ways to use S/Key:
(1) Give users printed sheets of their 100 (or whatever) passwords.
A random key can be used, presumably defeating dictionary
attacks. On the other hand, users are running around with
sheets of passwords printed out.
(2) Users use a trusted, local computing device to generate
the one-time passwords, typing in their secret key. This means
users need to know their secret key. If you let them choose it,
it may be vulnerable to a dictionary attack. If you assign them
one, they may write it down. And sometimes, there is no trusted,
local computing device available, so you're back to approach (1).
I'm about to try something for a client: use approach (1), but
getting through S/Key just gets you to the standard login prompt:
you still need to type your regular (non-S/Key) password.
Sure, an eavesdropper can snarf your regular password, but
if all entry paths are through S/Key, s/he also needs a one-time
password. Hardly foolproof or ideal, but the combination of
requiring "something you have" (the printed sheet of one-time
passwords), plus "something you know" (the secret passwords)
seems pretty strong, and adequate for this client's needs.
jas
|
|
