[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SAGE] Security tokens



On Fri, Jan 17, 2003 at 09:10:12AM -0800, Jim Hickstein wrote:
> OK, so I need to stop allowing reusable password authentication for certain 
> systems.  Years ago I got hold of some tokens for around $100 each and 
> rolled my own server; SecureID wanted ten grand just for the server 
> software, which made my unofficial experiment impossible, even for a start.
 
> Lately I'm starting to talk to ActivCard, having evaluated them in the 
> past.  Their server (no price yet) runs on Solaris, but requires Oracle 
> (!?) to talk to; administration of the authentication database requires 
> Windows; and I haven't really studied client integration yet.  This will be 
> for Windows, Mac, and UNIX users (FreeBSD, Linux) hitting my inward SSH and 
> VPN servers and a few web servers and maybe Citrix.
 
> What's the most open-standards-friendly of the several commercial systems? 
> (I know about S/Key and Opie, but these don't strike me as suitable for 
> non-sysadmins to use.)  Which one has the best integration with LDAP and 
> PAM and RADIUS and that sort of thing?  Which one works even if there is no 
> Microsoft product anywhere in sight, yet supports end users on Windows?
 
> I just might come up with the ten grand this time, if it would buy me 
> exactly what I want.  But entirely free (open source) would be fine.

 Would a PDA software solution be acceptable?

 I've heard that there exists a combination of UNIX/Linux server
 software (PAM modules, presumably) and PalmOS client software that 
 provides a software OTP system.  If PalmOS would be acceptable on
 the client/hardware side I'll look into it and see if I can dig it
 up.  

 Warning, it might be nothing more than OPIE (S/Key) ported to Palm
 on the one side.
 
 Incidentally, ISTR that the OpenBSD folks modified their OTP system
 (OPIE based?) to provide one-time LOGOUT verification.  This was to
 confirm that your logout command was actually executed on the remote
 host (to mitigate a rather nasty risk of an MITM (man-in-the-middle)
 keeping your shell session open after you thought you were logged out.

 Of course, if you have an active MITM --- I don't know of any general
 way (using exising shells and given the availability of software like
 'screen') to really protect nor even alert yourself of such an attack.

 (Scenario: you log in through my MITM, I faithfully relay the 
 challenge and response and possibly any interdiate shell prompts and
 commands; when I detect a privileged shell, my MITM installs a 
 screen-like program, execs it, and provides you with another copy of
 your shell.  Meanwhile, I have access to the multiplexed session,
 to other processes which you can neither see nor access).

 My thoughts on this have lead me to a deep suspicion of OTP in 
 general.  OTP is fundamentally there when I can't trust my client
 software (the copy of ssh on the terminal room computer) or when I
 have no choice but to run an insecure protocol (telnet).  If I can
 trust my client software then I don't need OTP.  But if I can't, 
 I'm not sure I gained much against the possible active MITM!

--
Jim Dennis