Subject: RISKS DIGEST 17.27

Subject: RISKS DIGEST 17.27
REPLY-TO: [email protected]

RISKS-LIST: Risks-Forum Digest Friday 18 August 1995 Volume 17 : Issue 27

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc. *****

Contents:
Netscape transaction security breached in 8 days by 1 person (Lewis McCarthy)
Netscape security (Peter Shank)
NIST crypto announcement on export controls and key escrow (Anne Shepherd)
Intel Warns of Marred Motherboards (Edupage)
The traffic light does NOT think (Torsten Ihle)
Stale accounts and lifestreams (Martin Ewing)
Re: Insisting on explanations for failures (Paul C. Kocher)
The MSN is Hacker Heavan (Mike Wyman via Andy Chesterton)
Windows 95 Registration Wizard confusion (Elliott)
Re: Air-traffic control power struggles continue (Sergio Gelato)
What is reality anyway? Re: Which risks to fight first? (Peter da Silva)
Re: Ten years still too soon to tell (Mark Brader)
Privacy Digests
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Wed, 16 Aug 1995 06:15:17 -0400 (EDT)
From: [email protected]
Subject: Netscape transaction security breached in 8 days by 1 person

Many customers now routinely purchase products over the Internet using their
World Wide Web (WWW) browsers. Netscape Commerce Server software accepts
orders submitted from a Netscape WWW browser, which are filled out in an
on-line web form and transmitted across the net to the server.

Using the Secure Sockets Layer (SSL) protocol, the customer's name, address,
phone number, and credit card number are encrypted with the RC4 algorithm
developed by Ron Rivest of RSA Data Security. Due to export restrictions
placed upon cryptographic software by the U.S. government, the release of
the Netscape software most commonly used is limited to encrypting with a
key only 40 bits in length.

A recent demonstration strikingly illustrates that this provides insufficient
confidentiality for the task at hand -- maintaining the privacy of credit
card information. After a sample transaction had been executed, and the log
of the encrypted server-browser traffic posted to the net, a private
individual managed to decrypt the transaction information in just 8 days of
CPU time. It would seem that secure commerce on the net, under bureaucratic
constraints, is a risky proposition indeed.

-Lewis McCarthy <[email protected]>

[Copies of the message from [email protected]
sent to [email protected] were forwarded to RISKS
by Lewis, and by
<[email protected]>,
Arve Kjoelen <[email protected]>,
[email protected] (Charlie Shub).
I do not include the Doligez message and a lot of ensuing discussion.
Also, I am told that a British team actually beat out Damien
by a few hours. PGN]

------------------------------

Date: Thu, 17 Aug 1995 08:44:45 -0700
From: [email protected] (Peter Shank)
Subject: Netscape security

Late Tuesday evening a person from France posted a news article to the
hacker community claiming success at decrypting a single encrypted message
that had been posted as a challenge on the Internet sometime on or before
July 14, 1994. His response to the challenge is described in an email that
has been forwarded widely across the Internet.

What this person did is decrypt one encrypted message that used RC4-40 for
encryption. He used 120 workstations and two parallel supercomputers for 8
days to do so. As many have documented, a single RC4-40 encrypted message
takes 64 MIPS-years of processing power to break, and this roughly
corresponds to the amount of computing power that was used to decrypt the
message.

Important points to understand:

1. He broke a single encrypted message. For him to break another message
(even from the same client to the same server seconds later) would
require *another* 8 days of 120 workstations and a few parallel
supercomputers. The work that goes into breaking a single message
can't be leveraged against other messages encrypted with other
encryption keys.

2. The standard way to determine the level of security of any encryption
scheme is to compare the cost of breaking it versus the value of the
information that can be gained. In this case he had to use roughly
$10,000 worth of computing power (ballpark figure for having access to
120 workstations and a few parallel supercomputers for 8 days) to break
a single message. Assuming the message is protecting something of less
value than $10,000, then this information can be protected with only
RC4-40 security. For information of greater value, currently available
RC4-128 security should be used.

3. Inside the US, software can support a range of stronger encryption
options, including RC4-128, which is 2^88 times harder to break.
Meaning that the compute power required to decrypt such a message
would be more than 1,000,000,000,000 (trillion) times greater than
that which was used to decrypt the RC4-40 message. This means that
with foreseeable computer technology this is practically impossible.

So in conclusion, we think RC4-40 is strong enough to protect
consumer-level credit-card transactions -- since the cost of breaking the
message is sufficiently high to make it not worth the computer time
required to do so - -- and that our customers should use higher levels of
security, particularly RC4-128, whenever possible. This level of security
has been available in the U.S. versions of our products since last April.
Because of export controls it has not been available outside the U.S. We
would appreciate your support in lobbying the U.S. government to lift the
export controls on encryption. If you'd like to help us lobby the
government send email to [email protected].

Finally, we'd like to reiterate that all this person has done is decrypt
one single RC4-40 message. RC4 the algorithm and products which use the
algorithm remain as secure as always.

------------------------------

Date: Fri, 18 Aug 95 9:10:51 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: NIST crypto announcement on export controls and key escrow

Contact: Anne Enright Shepherd
(301) 975-4858

COMMERCE'S NIST ANNOUNCES PROCESS FOR DIALOGUE ON KEY ESCROW ISSUES

Furthering the Administration's commitment to defining a workable key
escrow encryption strategy that would satisfy government and be acceptable
to business and private users of cryptography, the Commerce Department's
National Institute of Standards and Technology announced today renewed
dialogue on key escrow issues.

A Sept. 6-7 workshop will convene industry and government officials to
discuss key escrow issues, including proposed liberalization of export
control procedures for key escrow software products with key lengths up to
64 bits, which would benefit software manufacturers interested in building
secure encryption products that can be used both domestically and abroad.

Key escrow encryption is part of the Administration's initiative to
promote the use of strong techniques to protect the privacy of data and
voice transmissions by companies, government agencies and others without
compromising the government's ability to carry out lawful wiretaps.

In a July 1994 letter to former Rep. Maria Cantwell, Vice President
Gore said that the government would work on developing exportable key escrow
encryption systems that would allow escrow agents outside the government,
not rely on classified algorithms, be implementable in hardware or software,
and meet the needs of industry as well as law enforcement and national
security. Since that time, discussions with industry have provided valuable
guidance to the Administration in the development of this policy. For
example, many companies are interested in using a corporate key escrow
system to ensure reliable back-up access to encrypted information, and the
renewed commitment should foster the development of such services.

Consideration of additional implementations of key escrow comes in
response to concerns expressed by software industry representatives that the
Administration's key escrow policies did not provide for a software
implementation of key escrow and in light of the needs of federal agencies
for commercial encryption products in hardware and software to protect
unclassified information on computer and data networks.

Officials also announced a second workshop at which industry is invited
to help develop additional Federal Information Processing Standards for key
escrow encryption, specifically to include software implementations. This
standards activity would provide federal government agencies with wider
choices among approved key escrow encryption products using either hardware
or software. Federal Information Processing Standards provide guidance to
agencies of the federal government in their procurement and use of computer
systems and equipment.

Industry representatives and others interested in joining this
standards-development effort are invited to a key escrow standards
exploratory workshop on Sept. 15 in Gaithersburg, Md. This workshop is an
outgrowth of last year's meetings in which government and industry officials
discussed possible technical approaches to software key escrow encryption.

The Escrowed Encryption Standard, a Federal Information Processing
Standard for use by federal agencies and available for use by others,
specifies use of a Key Escrow chip (once referred to as "Clipper chip") to
provide strong encryption protection for sensitive but unclassified voice,
fax and modem communications over telephone lines. Currently, this
hardware-based standard is the only FIPS-approved key escrow technique.
NIST officials anticipate proposing a revision to the Escrowed Encryption
Standard to allow it to cover electronic data transmitted over computer
networks. Under this revised federal standard, the Capstone chip and other
hardware-based key escrow techniques developed for use in protecting such
electronic data also will be approved for use by federal agencies.

As a non-regulatory agency of the Commerce Department's Technology
Administration, NIST promotes U.S. economic growth by working with industry
to develop and apply technology, measurements and standards.

Note to editors: Readers who are interested in obtaining more
information about the workshops can contact Arlene Carlton,
(301) 975-3240, fax: (301) 948-1784, e-mail: [email protected].

------------------------------

Date: Thu, 17 Aug 1995 21:40:11 -0400
From: [email protected] (Edupage)
Subject: Intel Warns of Marred Motherboards (Edupage, 17 Aug 1995)

Intel and other computer companies are trying to determine the extent of
problems caused by a flaw in an RZ-1000 EIDE controller chip that's included
in some early PCI motherboards manufactured by PC Tech. The flaw was
discovered in 1994 and was corrected through a software "patch," but the
latest version of OS/2 disables that patch. (Investor's Business Daily 16
Aug 95 A15)

[I thought perhaps the SUBJECT line was a typo,
and that we would now have to worry about
UNmarried motherboards. PGN]

------------------------------

Date: Thu, 17 Aug 1995 11:15:50 +0200
From: [email protected] (Torsten Ihle)
Subject: The traffic light does NOT think

The following is my rough translation of the article "Die Ampel denkt nicht"
I just read in the German weekly newspaper "Zeit" from August, 11 1995, p.12.

The "intelligent street" - a foolish flop
The traffic light does not think

Stuttgart. - There is no doubt about it, there are intelligent
traffic lights. They do recognize, when to switch from red to
green. Also, an electronic display exhibits intelligence, if it
alerts us about a traffic jam 15 kilometers (km) ahead. Indeed, our
traffic signs become more and more intelligent. We report on an
experiment to replace the common sense of a driver by traffic
signs - a failed experiment, though.

At April 29th 1995 the federal minister for traffic and
transportation, Matthias Wissmann, and the state minister for traffic
and transformation of Baden Wuertemberg, Hermann Schaufler, pressed
a little green button: The "traffic control (literally influence)
machinery" at the federal street 27 in the south of Stuttgart
started to work. A pilot experiment at a length of 18 km was
supposed to end the brass-age: Instead of stupid speed-limit 80 km/h
signs in the future there will be "variable speed limits" thanks to
"automatic video sequence processing", "radar technology" and
"computer based computational methods". The small group was sure:
this was the advent of the "intelligent road".

The drivers at this heavily frequented segment got a different
impression the other morning. The DM 14.000.000 equipment suggested
a speed limit of 120 km/h - during a traffic jam. And during the way
home at the evening the super device surprised onece again: It did
rain cats and dogs, which triggered the highly sensitive sensors to
announce "wet street".

The obvious flop made the ministry of traffic and
transportation to stick red crosses over the displays. At July 19th
started the second trial. Since then it is allowed to race. Where in
former times a speed limit of 80 km/h was in effect for noise and
emission reduction, the computer did allow 120 km/h, in non urban
areas there was no speed limit at all. Some days ago a
vespa-driver fell down, causing a jam, but the "light fiber optical
traffic sign" did suggest 120 km/h. Fortunately, the drivers thought it
over and did brake. Police and city authorities stopped the
madness. Due to their protests, the installation displays constantly
100 km/h in the city area.

There is a saying around Stuttgart: "With 40 the Swabian
becomes sensible, others not in eternity". Why should a traffic
installation make a difference.

Phillip Mausshardt

This "translation" is not to be considered as a contribution to the
intellectual heritage of this century (due to my limited ability to use the
English).

There are, however some reports on successfully installing such
devices, namely by Kuehne et. al., e.g. in:

Kuehne, R.D. and Roediger, M.B. Macroscopic simulation model for
freeway traffic with jams and stop-start waves. In: Proceedings of the
1991 Winter Simulation Conference, pp 762-770

For the interested (and German reading), I can provide more references.
I do not know, however, which research team was involved with the
traffic control system described above.

Torsten Ihle, Dipl. Inf., TU-Dresden [email protected]

------------------------------

Date: Wed, 16 Aug 1995 00:09:49 -0400
From: [email protected] (Martin Ewing)
Subject: Stale accounts and lifestreams (Frankowski, RISKS-17.26)

Dan Frankowski's account (RISKS-17.26) of problems with an old frequent
flyer account points up a new generic risk: Our electronic "shadows" accrete
all kinds of data over a lifetime. Apart from the problem of bad guys
getting access, it is rather difficult for us to retrieve our own data. In
addition to stale f.f. accounts, we may need to get tax records, Social
Security income data, house purchase and repair cost information, investment
cost, etc., sometimes back to day zero.

Dave Gelernter at Yale has developed a "lifestream" database model which
would capture and organize (by date, as I understand it) all your electronic
data, starting with your birth certificate. In addition to all your
financial transaction data, there would be all your e-mail, significant
images, school homework, all the versions of all the programs you ever
wrote, etc. We can imagine carrying this all around on an optical disk in
your wallet or on a super smart card. (How much of it should be accessible
to other parties like the IRS or to legal subpoena is an interesting
question. Encryption might be a good idea, if you can remember a key
throughout your whole life!)

I don't know if a comprehensive personal "lifestream" is going to be
available any time soon, but the technology is almost there. As a concept,
it may help to sharpen our ideas about electronic risks. It certainly
would help to find that old account number.

Martin Ewing, Yale Science & Engineering Computing Facility
<[email protected]> http://minerva.cis.yale.edu/~ewing

------------------------------

Date: Tue, 15 Aug 1995 23:54:09 -0700
From: [email protected] (Paul C. Kocher)
Subject: Re: Insisting on explanations for failures (Kamens, RISKS-17.26)

Dell specializes in selling inexpensive computers. Customers who want the
cheapest hardware are going to have to face some extra risks, such as the
chance of failing to be notified about a buggy BIOS.

Few software companies provide toll-free support, but I don't think this is
necessarily bad. I would often prefer paying $50 for a program with minimal
support over spending $100 for the same program with better support. Books,
third parties, toll- call support, etc. can provide support if I don't mind
paying slightly more.

There are risks everywhere, and we have to decide how much effort and money
to invest in avoiding them. In the case of the PC clone industry, there are
many suppliers and the market is extremely competitive, so consumers can
decide whether the risks associated with choosing a low-cost supplier are
worth taking.

Don't get me wrong; I'm not recommending that market forces set safety
standards, but I also don't think it's necessarily bad that companies cut
some corners in order to provide more competitive prices.

Paul Kocher [email protected] (formerly [email protected])

------------------------------

Date: Fri, 18 Aug 1995 08:34:28 -0700
From: [email protected]
Subject: The MSN is Hacker Heavan

[Below is an article, forwarded with the authors permission. The risks are
obvious. I wonder how the risks can be reduced. Andy Chesterton]

As most of us are aware, the commercial online services, such as AOL,
Compuserve and Prodigy, represent certain risk to the unsophisticated user.
Unfortunately, the Microsoft Network (MSN) raises the vulnerability of such
users to unprecedented heights.

Key to this vulnerability is the richness and complexity of the MSN/Windows
95 environment. What is most dangerous is the ability for the author of an
e-mail or (certain) BBS documents to embed "objects" in that document. These
objects can be readily disquised to appear totally benign to the casual user
and be nothing more than MSN navigational aids. Once double-clicked by the
recipient, these objects can readily infect the recipient's PC with a virus.
Worse, what this object could do is only limited by one's imagination. It
is worthwhile noting that MSN appears to be migrating to an open
architecture, with the MSN user connecting through the Internet. If this is
true, there is nothing which prevents an object, once activated, from
transmitting information stored on the user's PC to any other location on
the Internet.

In theory, embedded objects can be interrogated to ensure their validity.
Unfortunately, this interrogation process is not likely to be carried out by
the average user. Even if it is, the user is not likely to understand what
they are looking at. It is like warning automobile drivers to look under
the hood of their car before starting it to make sure there is not a bomb
inside. Most drivers would assume that the odds were with them. Those that
did check would have no idea what they were looking at. (At least that's my
feeling when I look under the hood of my car :-).

Microsoft's position appears to be that the MSN user is no more vulnerable
than one who uses a competing system. I would maintain that this position
is just not true. With system complexity comes excessive vulnerability.
MSN rates a 9 in complexity. The other services a 4.

The bottom line: Users of MSN are placing themselves at significant risk.
If one must use MSN, avoid at all cost activating (double-clicking) objects
in e-mail messages and BBS posts. Sophisticated users may think they know
what they are doing, but it probably won't be long before they are outwitted
by someone who figures out how to totally disguise an object's true purpose.

-Mike Wyman [email protected]

------------------------------

Date: Thu, 17 Aug 95 12:05:30
From: [email protected]
Subject: Windows 95 Registration Wizard confusion

It strikes me reading these articles on RISKS that someone has confused two
Microsoft products. Microsoft SMS (Systems Management Server) collects
information about the machines on a corporate network to aid administration.
In particular, it collects autoexec.bat and config.sys files, and identifies
"packages" installed on the machines (these packages and how they're
recognised is configured by the administrators).

I'd guess that someone's been reading too many press releases and blurred
the Windows 95 Registration Wizard with the SMS inventory. One of the risks
of having so much advertising material flying around...

Elliott

------------------------------

Date: Wed, 16 Aug 1995 13:16:41 +0200
From: Sergio Gelato <[email protected]>
Subject: Re: Air-traffic control power struggles continue

> radius of about 357 square miles,

Since when are radii measured in SQUARE miles?

[THANKS. I was thinking of making something out of ROUND miles
instead of SQUARE miles, and forgot to go around the square. PGN]

[Also noted by
"Michael J. Chinni, (AMSTA-AR-IMN)" <[email protected]>, and
John Pearson <[email protected]>. There may have been
others as well. Perhaps it was an inadvertent test to see who
is reading carefully... PGN]

------------------------------

Date: 1 Aug 95 21:27:59 GMT (Tue)
From: [email protected] (Peter da Silva)
Subject: What is reality anyway? Re: Which risks to fight first?

From: [email protected]
> The reason for the interest in the effects of the Internet and VR
> technology is simply that they are unknown. People are reporting problems
> with "Internet addiction", and as an old gamer I can see where there might
> be a problem with people preferring VR flight simulators to their real
> lives.

One thing that has been happening throughout history is that the sorts of
activities considered to comprise people's "real lives" have changed, over
and over again. How would a hunter-gatherer or a primary farmer or a medieval
villein or a monk view our "real lives" today?

Except for a minority we're pretty much out of touch with nature, with the
divine, even with our livelihood. We don't hunt, harvest, butcher, or otherwise
gather or process our own food. Hardly any of us engage in daily prayer. I
assume that most readers of this forum don't believe in the literal truth of
our scriptures the way people did only a few hundred years ago.

By the standards of most of history, we're hopeless technology addicts today.

We shouldn't be so quick to judge people who prefer VR to their "real lives".

How real is *your* life? I know when we've got a project in house my life six
days a week consists of work 9AM to 9PM, living in a reality of cables and
backups and little antique-white squares on a pleasant lilac background.

Peter da Silva Network Management Technology Incorporated
1601 Industrial Blvd. Sugar Land, TX 77478 USA +1 713 274 5180

------------------------------

Date: Tue, 1 Aug 95 21:51:21 EDT
From: [email protected] (Mark Brader)
Subject: Re: Ten years still too soon to tell (Turney, Risks-17.22)

> To see why, consider the history of nineteenth-century railroading.

And it was also apparent how to avoid a large part of the problem. Use
broader gauge tracks -- move the rails farther apart -- in relation to
width the cars. In Britain, the Great Western Railway was built with
tracks of 7' or 7'0.25" (2134-2140 mm) gauge, where others chose the
4'8.5" (1435 mm) that soon afterward became the standard. But the GWR's
passenger cars were almost the same width as their competitors'. When
involved in a derailment or collision, they almost always *stayed upright*
-- so unless the car was actually smashed, people would not likely be
trapped inside it.

Of course, there is no computer relevance whatever to this story of a
system that was technically superior in safety and other respects, but
which lost out to one that was more common and cheaper.

Mark Brader [email protected] SoftQuad Inc., Toronto
This article is in the public domain.

------------------------------

Date: 17 August 1995
From: [email protected]
Subject: Privacy Digests

Periodically I will remind you of TWO useful digests related to privacy, both
of which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in privacy
problems. RISKS will continue to carry general discussions in which risks to
privacy are a concern.

* The PRIVACY Forum is run by Lauren Weinstein. He manages it as a rather
selectively moderated digest, somewhat akin to RISKS; it spans the full
range of both technological and non-technological privacy-related issues
(with an emphasis on the former). For information regarding the PRIVACY
Forum, please send the exact line:

information privacy

as the first text in the BODY of a message to
"[email protected]";
you will receive a response from an automated listserv system. To submit
contributions, send to "[email protected]".

Information and materials relating to the PRIVACY Forum may also be
obtained via ftp to "ftp.vortex.com", gopher at "gopher.vortex.com",
and World Wide Web via: "http://www.vortex.com".

* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
run by Leonard P. Levine. It is gatewayed to the USENET newsgroup
comp.society.privacy. It is a relatively open (i.e., less tightly moderated)
forum, and was established to provide a forum for discussion on the
effect of technology on privacy. All too often technology is way ahead of
the law and society as it presents us with new devices and applications.
Technology can enhance and detract from privacy. Submissions should go to
[email protected] and administrative requests to
[email protected].

There is clearly much potential for overlap between the two digests, although
contributions tend not to appear in both places. If you are very short of time
and can scan only one, you might want to try the former. If you are interested
in ongoing detailed discussions, try the latter. Otherwise, it may well be
appropriate for you to read both, depending on the strength of your interests
and time available.
PGN

------------------------------

Date: 9 August 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>). UK subscribers please contact
<[email protected]>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
the newly automated <[email protected]>, with first text line
SUBSCRIBE or UNSUBSCRIBE
[with option of E-mail address if not the same as FROM: on the same line].
HELP
gives instructions on using the Majordomo listserver in other ways.

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html
(Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 17 is in that directory: "get risks-17.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password. Also ftp [email protected]. WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen. Use wisely.

------------------------------

End of RISKS-FORUM Digest 17.27
************************