Ken Hardy <ken @
mailhost .
bridge .
com> injected a Fwall-hooked and
thought-provoking caution into the recent thread discussing the high risk
of laptop theft for business travellers.
>The user absolutely should
>_not_ have any software on the laptop that connects to the corporate
>network, either through or around the firewall, without the manual
>entry of a password, PIN, token, or whatever. I.e., the thief better
>not be able to plug the laptop into a phone jack an be inside your
>defense perimeter.
An open data line, fully authorized -- ouch! Nightmare! It would
be nice if this sort of risk could not exist, but since it is possible, it
should be forbidden by policy. Perhaps most important, users should be
educated to the fact that they themselves are crucial components in the
security paradigm that protects their own workspace and the online work of
others.
A stolen laptop should be reported immediately (to someone who says
thank you, and doesn't berate the victim), and a security administrator
should quickly react to minimize any danger of the thief masquerading as
the authorized user in corporate systems with remote access. (It may also
be useful to quickly evaluate the loss of corporate data, particularly when
the laptop files are not encrypted. Note that some file encryptors with
centralized network-install schemes now allow a corporate manager to
designate certain named files for automatic encryption.)
>I heard 2nd hand that there was a PCMCICA card for SecurID that
>automatically enters the time-sensitive token for the user. Is this
>true? I envision that an enterprising user could perhaps put his
>PIN number into his login script and then have hands-free access to the
>net. Hope I'm wrong.
Was true -- but SDTI backed out of PCMCIA cards, and Motorola
killed off its line of PCMCIA-based SecurModems (which integrated a SecurID
into a PCMCIA modem.) Not that the same issues don't pop up again with
smartcard-based authentication. And not that the same risks don't exist
all over the place with contemporary "soft tokens" (wholly software-based
token emulators) and S/Key, OPIE, OTP systems.
The elegant simplicity of classical tokens (hand-held
authenticators, HHAs) -- with their total lack of circuit connection
between the users workstation and the physical token -- is something that
will be difficult to duplicate with mere policy. (You know exactly what an
HHA token is doing, and you know that a HHA token is _only_ doing what you,
at the keyboard, allow it to do. That level of assurance is not easy to
duplicate with a wired connection.)
Wire the token to the user's CPU, and you effectively downgrade
your authentication -- as you always do with any "soft toke."
Wire the token (something you have) and allow a script that will carry a
password (something you know) from one logon to another -- and you've
downgraded the authentication much further. Now, you've got a
single-factor authenticator (something you have) which... yup, can be
stolen.
There are ways in which one can attempt to force the user to put in
a password at each logon, but none are likely to be beyond the ability of
that archtypal "enterprising user" to circumvent.
Any thoughts on the need to routinely qualify an authentication
call as to grade, quality, of the authentication? I think this will become
a major issue with X509 Certs of the sort we use for S/MIME mail, and SSL,
with Communicator and Explorer 4 browsers in their tens of millions. As
typically used, I think you have a fairly good authentication on the user's
machine, but (even with a password) only a relatively weak one-factor-plus
authentication on the user.
The distinctions become somewhat vague, but I notice the new
Gartner Report on CAs urges high-security sites to require old-fashioned
HHAs for high-level user authentication.
Suerte,
_Vin
Vin McLellan + The Privacy Guild + <vin @
shore .
net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
-- <@><@> --
|
|
