Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
An article in the Boston Globe yesterday (23 December) covers similar
issues, but raises a few additional points which make me think that (as
usual) the computer is only an unwitting accomplice and not the source
of the trouble at all.
Date: Mon, 21 Dec 87 21:48:36 EST
From: hal@gvax.cs.cornell.edu (Hal Perkins)
[...]
Promotions [of portfolio insurance] worked: By October, between $70
billion and $90 billion was invested in funds using some form of the
insurance....
The Globe article points out that when portfolio insurance was first
"invented" it was dismissed in an article in Fortune (ca. 1980) as a
"carnival act". Its inventors pursued its promotion however, and the
"invention" of index futures allowed them to make the concept more
palatable to fund managers (since they were no longer required to change
the makeup of their portfolio to participate). Shortly to follow was
the "invention" of index arbitrage, which provided a ready appetite for
the portfolio insurers' future trading.
My inference is that what legitmized the "carnival act" was not any
understanding of its mechanism, but simply a track record.
Unfortunately there are a large number of investors who believe that
history is an accurate predictor.
[...]
"The problem was that everyone is working from roughly the same
theories," said Peter U. Vinella, a partner at Berkeley Investment
Technologies in Berkeley, Calif., which writes many complex trading
programs. "They all get the same feedbacks. And that leads everyone
to take the same action."
Here is the nub. My inference is that as long as insurance and
arbitrage were *unusual* investment policies, they actually "worked" by
trading on discrepancies arising from imperfect information. Of course
their success led to popularity, and eventually to the situation Vinella
describes: all sellers and no buyers, the downfall of any Ponzi scheme.
A Fear of Defying the Computer
[...]
"People get lulled into thinking, `My program says this will work,'"
said Robert H. Mundheim, the dean of the University of Pennsylvania law
school.... "And you don't have time to think through the assumptions
that went into the programs — if you understood them in the first
place."
The Globe points out that the inventors and primary promoters of
portfolio insurance (LOR Corp.) actually did "sanity check" what their
computers told them to do and held off making the massive futures sales
the program directed. (I believe they realized, if only intuitively,
that their algorithm was operating out of its useful range, because they
had not forseen the discrepancies it was now receiving as inputs.)
However, several of their licensees did exactly as the program directed,
having been lulled into beliving in its infallibility, only to find
there were no buyers. As the sell orders mounted, depressing the price,
the algorithms, lacking any sanity checks, simply directed more sales.
It's interesting to speculate whether the limited automation of the
exchanges exacerbated the situation or acted as a governor to slow
things down enough for conventional investors to react to the
bargain-basement prices and finally put a floor under the madness.
About two years ago I was working on a project that required coding in PL/I. I
had a problem with running out of memory while exectuting my code. After many
hours of frustration I discovered the problem was that I had two procedures
'put_message' and 'put_page' (which called 'put_message') truncated to the
same name. This was due to PL/I's truncation scheme of taking the FIRST four
letters and the LAST three of a procedure. Thus, both procedures were
identified as 'put_age' and I ended up running out of memory because of
unintentional recursive procedure calls.
Doug RUDOFF TRW Inc, Redondo Beach, CA {cit-vax,trwrb,uunet}!wiley!doug
H: (213) 318-9218 W: (213) 812-2768 wiley!doug@csvax.caltech.edu
[Recursively Call a spade a spade a spade ... but don't expect it to
return. (If it weren't Christmas time, and it hadn't been pouring in
LA, I probably would have refrained from annotating this message from
RUDOFF THE RED{ONDO} KNOWS RAINGEAR.) Happy holidays to all. PGN]
<>The prank seems to be benign, and therefore beneficial.
My contribution was relevant to the above passage: the fact that it was
on the front page of a major metropolitan newspaper (The San Fransisco
Examiner, Sunday 12/20/87) with a more or less in-depth article spread
the implicit warning farther (sociologically) than the virus itself
spread. (Granted, this metropolitan newspaper serves one of the most
computer-literate parts of the country...)
Opinions expressed above do not necessarily — Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
[I think the major point about Trojan horses, viruses, and similar
problems is that they are relatively easy to perpetrate, but potentially
devastating on many systems. The cases we have seen to date are all
rather benign (except for denials of service) or localized in effect (PC
graphics ARF-ARF!). The lesson is that these vulnerabilities exist.
However, the rather benign cases suggest that deeper concern is
warranted. PGN]
I am interested in making a list of the most common passwords chosen by
users. I'd like to see if anyone knows of any studies that have been done (I
vaguely recall hearing of at least one such study). We are writing a program
to check for poor passwords on our systems. Please send replies to:
Doug Mansur -or- (Mansur@dockmaster.arpa)
L-308, Lawrence Livermore National Lab., P.O. Box 808, Livermore, CA 94550P
[At one time "Susan" was reputed to be the most popular American choice.
I recall a British clipping citing dogs' names as popular passwords.
However, since many prudent system managers now insist on randomly
generated pronounceable passwords, your study might be dated.
Furthermore, I hope no one is stupid enough to tell you what their
password is. But past studies (e.g., Morris and Thompson, UNIX Password
Security: A Case History, CACM 22 11 November 1979) have encrypted
initials, dictionaries, etc., with great effect. If your system permits
access to unencrypted passwords, your study might focus on that instead.
PGN]
Ross Patterson wrote (in RISKS 5.80): >(5) Is the Internet similarly vulnerable ? <>Not to this one. It plays on several things that the Internet doesn't have: <>1) A large number of IBM VM/CMS systems. ... <>2) A suitable file transfer system. FTP doesn't apply. ... <>3) A good method of determining targets. The CMS NAMES and NETLOG files ... The quasi-equivalent of this problem in UNIX systems (and most of the Internet, because of the large number of UNIX systems it contains) is the ubiquitous shar file, an ASCII packaging machanism used to transfer code and other ASCII files via mail and/or Usenet news transfer. The problem lies in the way users unpack shar files: they execute them. Needless to say, inspection of shar files before execution/extraction is highly recommended. There's nothing to prevent me from writing a shar file that purports to be a Christmas card. Execution of it might display the card, check out the contents of various mail-related files, (like ~/.mailrc and ~/mbox) looking for likely candidates to send the shar file, then recursively send it. In fact, the same scheme would work for most operating systems with a command language that could be executed from a file. UNIX systems are especially vulnerable, however, because of their large numbers. Skip (montanaro@ge-crd.arpa, uunet!steinmetz!sprite!montanaro)
The following "SAFE-ALERT" form was distributed at Goddard Space Flight Center (NASA - Greenbelt, MD) about cleaning PC's. The date was 7/29/87, alert number X7-S-87-01. "Recently an employee of this installation was cleaning his personal computer screen with a glass cleaner when the screen caught on fire. The computer had been in use for some time and had built up a static charge. When the employee went to wipe off the glass cleaner with a tissue, his finger hit the screen. This action discharged the static charge causing a spark which ignited the alcohol in the window cleaner. A total of 8 personal computers were checked, with only 1 other catching on fire." The installation mentioned above was the Naval Weapons Center in China Lake, CA. The action taken was to inform the employees about what could happen, and ask them to use a non-flammable cleaner. If there was a need for a flammable cleaner, then employees were advised to discharge the computer before spraying. John McMahon DFTNIC::FASTEDDY (Span) FASTEDDY@IAFBIT (Bitnet)
A while back, I posted an article on ATM card security, promising to tell more as soon as I get the official security guide. Well, now I have the guide, and here are some findings, given somewhat verbatim since this document was distributed as "confidential": In Finland, there are two methods of off-line verification of PIN's. Both are DES-based, so they can be considered pretty secure (unless there are hidden trapdoors in DES - has the analysis behind its design been made public yet ?) The PIN verification is done by the "verification unit", which consists of a keypad for PIN entry, the magnetic stripe reader unit and the main electronics unit, which communicates with the local cash register unit. The document also specifies which "security modules" may be used in these verification units: Intel 8751H, Intel 8752H and AMD 9761H. Can someone who knows better tell what these units actually are ? DES-chips ? The first method of PIN verification is the same that is used in VISA- cards internationally: the card number, the PVV-version number (off the card's magnetic stripe) and the PIN number the customer has entered from the keypad are all munged through DES, using certain highly secret keys which are distributed by the banks. The resulting number is then compared with the PVV-number from the card's magnetic stripe, and if it is same, the given PIN was correct. The second method used is local to Finland, I guess. In this, the card number is encrypted with several highly controlled keys, resulting in the actual PIN that the client should have given. There are very strict rules on key control, for example the master key is divided into three parts and given to three people who each load their part to the verification unit ala bank safe keys. This document also specifies the encryptation that MUST be used for all message transmissions to/from the verification unit. This would seem to remove problems with faked messages etc. The only problem that would seem to arise is key security - if the keys become widely known, there goes the security. Generally, it would seem that this type of security is an overkill in practise. A local supermart is a good example: they are on-line to the bank so they can send payment transactions immediately to the bank computer, they use magnetic stripe readers to read credit card / bank card stripes, but they still use signatures for verification. The only reason I can think for this is that it's simpler for them. Hooray for minimizing of risks! A note on ATM's swallowing cards up: my girlfriend lost her card to another bank's ATM a couple of days ago, since she couldn't remember the new card's PIN right. She didn't want them to send the card by mail, since it would take a few days, so she called the bank the next morning and told them to keep the card, she'll come and pick it up. Then she just went there during her lunch break, showed ID, and they gave her card back to her, since the card was not "wanted" or anything. Banks over here seem much more cooperative then the american ones I've been to. A safe Christmas, Otto J. Makela, U of Jyvaskyla Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland Phone: +358 41 613 847 BBS: +358 41 211 562 (V.22bis/V.22/Bell 212A/V.21) BitNet: MAKELA_OTTO_@FINJYU.bitnet
I have been reading RISKS for a number of months and have noticed that
the contributors seem to take it for granted that social security numbers
cannot be required except in situations involving income.
I would like to know what the basis for this common knowledge is.
Is it a statute? A court case? Can you give me a name or a citation
so I can look it up in our local law library?
The reason I am looking for it is that my health insurance plan is demanding
my children's social security numbers. I seek to keep their social security
numbers private whenever possible in order to reduce the problems they will
encounter if a Big Brother society should come about. (I give mine out
without a second thought — it is already in so many places that I would
have no privacy anyway.) To be able to cite legal chapter and verse would
significantly strengthen my case; the insurers are presently intransigent.
Roger Alan Pick - QA & Information Systems Department, University of Cincinnati
VOICE: (513) 475-7166
UUCP: {decuac,psuvax1!gatech!mit-eddie,philabs!phri,pyramid}!uccba!ucqais!rpick
POST: QAIS - Lindner Hall, Univ. Cincinnati, Cincinnati, Ohio 45221-0130 USA
[This question is like the Yes Virginia, there is a Santa Claus letter in
the International Herald Tribune. Discussion goes back to early RISKS. PGN
]
Please report problems with the web pages to the maintainer