Re: [SAGE] Security tokens

[Chuck Yerkes <chuck+sage@snew.com>]

Given those goals, you might simply require ssh with a key,
no passwords allowed at all.

Or Kerberos.  Or both :)


I picked up one of those USB storage units ($4 after rebate,
purely for toy factor) and am looking at keepings keys and what
not on THAT so it's portable with me.  Cons include that it would
need to be mounted on whatever machine I'm at.

I've used DES challenge response devices and used them with
OpenBSD (built in support) and SunOS a lot (venema's daemontools
had a login(8) that could support it with an unrecalled amount
of work.  I used fwtk proxies for its support of them as well.

The device, an SNK-4 now owned by Raptor, last I looked, still
works after 7 years, cost me $35 each for 3.  I know there are
software versions available and other calculators.


The final part is a strong policy about sharing secret information
like passwords.  Tell someone your password, your belonging can
be picked up at the loading dock at 4.

I worked for a client (very short term) that had switches locked
down by Mac address, they ran Bochs (sp?) - some commercial Unix
priviledge partitioning software.  My job was to install a large
application, so I needed root and had to reboot a dozen times.

They were so secure that I couldn't use the tools on my laptop
to debug (though I showed that I could change MAC addresses in
a moment to match the useless Solaris box that had used the port).
It was so secure, they couldn't change the root password for this
machine for 2 days because they were all the same on all the
machines.  It was so secure that you needed privs to print from
certain machines, so they all told each other their passwords to
do these basic functions.  And they never saw that their security
was close to nil for all their measures.

Quoting Jim Hickstein (jxh@jxh.com):
> >> My thoughts on this have lead me to a deep suspicion of OTP in
> >> general.
> 
> 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.).
> 
> 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.