[4674] in WWW Security List Archive
Re: SecureID alternatives?
daemon@ATHENA.MIT.EDU (Vin McLellan)
Wed Mar 5 19:52:23 1997
In-Reply-To: <331D72FB.5D20@tim.it>
Date: Wed, 5 Mar 1997 17:23:08 -0500
To: rgaloppini@tim.it
From: Vin McLellan <vin@shore.net>
Cc: jch@vasco.com, www-security@ns2.rutgers.edu, tel1dvw@is.ups.com,
aisecur!KClancy@bpd.treas.gov, adam@homeport.org
Errors-To: owner-www-security@ns2.rutgers.edu
Vin McLellan wrote:
><snip>
>> Vasco's Internet AK II offers two-factor (token and PIN)
>> authentication in the classic role of the hand-held authentication (HHA)
>> token: at the gateway, validating user IDs before allowing access to a
>> protected Netscape server (with a neat little Java applet that drops a
>> token-readable bar code on the user's screen.)
Another Tolkien-lover, Roberto Galoppini <rgaloppini@tim.it> responded:
>About that applet I'd be curious to know how the user could safely check
>out it's the 'right' and not a malicious one.
Good question. I've been impressed at how far the Europeans go
(even beyond "authenticode" sigs) to ensure that their commercial Java
applets are not used as virus carriers or trojans. (See, for example,
Brokat's xpresso Java package <http://www.brokat.de/xpresso/> which may set
the standard for web security European banking. Xpresso dynamically
replaces Netscape/Microsoft's exported (espionage-enabled) SSL with
full-strength SSL... and optionally, I think, offers an even stronger
cipher: SST.)
Didn't Checkpoint recently announce that SurfinGate -- a similar
sort of applet-scan, from Finjan, another Israeli company -- is to be
integrated into Firewall-1, via its content vectoring protocol?
McLellan also described SDTI's WebID:
>> After authenticating the user, the
>> WebID (which is part of the NT ACE/Client, on the web server) passes a
>> timed cookie to the user's browser, which gives him continuous
>> authentication to other protected items on that server (subject to his NT
>> permissions) until the cookie times out.
Galoppini noted:
>Cookies (or hidden tag or digest auth or ..) without ssl AND a 'short'
>timeout (short enough to not let bad guys decrypt it!) are pretty
>useless from a security point of view.
>An example of this is the way Checkpoint's firewall allows http proxy
>auth through secur-id tokens. It permits to define a period of time
>during which any http request presenting an http auth user/password with
>a good (but outdated) passcode is considered valid.
Agreed on the first point (I think.) What I like most about WebID
is that with it the web server can _require_ an SSL connection to a
particular object: directory, page, or portion of a page. You can have
both secured and public HTML pages on the same server. The controls on the
WebID cookie are of two types:
* a configurable time-out, with the default set at a half-hour;
* and/or a control which keeps the cookie viable so long as the
time between serial web-accesses is no more than a set (configurable)
period.
(I'm confused by your statement that cookies, tags, or digests
"without ssl AND a 'short' timeout....are pretty useless...." Since SSL
gets established first, I don't see any threat to cookie, etc.,
subsequently transmitted through the secure SSL pipe.)
I'm also not current on what controls a FW-1 makes available for
limiting its pseudo-stateful SecurID authentication under HTTP. Are you
saying the control is somehow set too long or is it just awkward to use?
(Used to be, FW-1 could be set up with either CRON or an INSPECT
script to limit access to a specific day and/or a time-of-day window. I
don't know if they ever developed a time-out access chit, but a Checkpoint
firewall wouldn't need to send a cookie to the browser, given the way its
virtual policy engine vets the traffic both ways, would it? Any Firewall-1
Mavens out there willing to educate the ignorant???)
Suerte,
_Vin
Vin McLellan + The Privacy Guild + <vin@shore.net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
