Re: [SAGE] Security tokens

[Eric Sorenson <eric@explosive.net>]

On Mon, 20 Jan 2003, Jim Hickstein wrote:

> >>  [ Jim Dennis wrote: ]
> >>  My thoughts on this have lead me to a deep suspicion of OTP in
> >>  general.

As in many things security-related there is some snake oil and some real 
benefit to OTP.  However the existence of snake oil (which can usually
be identified by "one size fits all" or "magic bullet" language by 
people who, for pay, provide a particular solution) does NOT constitute
proof of the non-existence of real benefit. In other words, suspect
away, but the truth is there are very real benefits to OTP when it's used 
appropriately.

> My goals are a little simpler than all these attacks imply.  This would 
> only be used down encrypted channels from trusted client hosts, so the MITM 
> stuff isn't my biggest concern.  The objective is simply to preclude the 
> use of re-usable passwords, when reaching in across my physical network 
> boundary, so people can't trivially give them away to each other (and to 
> customers, friends, etc.).

And this is a great example where OTP will get you vast improvements in
real-world security for relatively minor pain. 

> Disabling, say, a former employee's reusable-password access to company 
> systems utterly fails to ensure that they don't know the reusable password 
> of another, current employee.  There is far too much laxity here about 
> keeping passwords secret, even if they're strong.  This then transfers the 
> problem the PIN that unlocks the stored secret, but this is why I want a 
> token rather than simply using the PIN _as_ the secret -- as S/Key and Opie 
> do -- because they'd give away their PINs if they could.  Forcing them in 
> this case to surrender the one device that gives them their own access, 
> i.e. making it non-duplicable, is the only way I can see to stop this.

This paragraph looks right on point to me.

I wrote a message to the list a month or two ago describing our use
of CryptoCard tokens in a thread called "Non-reusable Password Systems";
while I won't repeat what I said then, here are a few comments from our
rollout, eight weeks on: 

Make sure you impress upon your users that they are responsible for
their token in the same way as their access badge or physical keys; if
possible get approval to charge the real cost of the token (maybe plus
some "feel the pain" money) for losing it. We've had people say "oh I
threw it out when cleaning my desk", "I didn't think I'd need it" and so
forth, which are ultimately our fault for not making their importance
more clear.

If your tokens have a 'lockout' feature which disables access after 'n'
wrong PIN attempts, make it pretty generous (5-10) and show via physical
demonstration or illustrated docs what it looks like when you put in the
wrong pin.  Several of our users have inconveniently locked themselves
out by putting in the same wrong PIN five times in a row.

Our users really aren't that dense! It's just a new habit for them to
get into and it takes a little time.

-- 

    Eric Sorenson - EXPLOSIVE Networking - http://explosive.net