The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 4 Issue 78

Sunday, 26 April 1987

Contents

o Re: Fidelity Mutual Funds Money Line feature
Martin Ewing
Brint Cooper
o Re: Forgery on Usenet
Matt Bishop
o Re: VCRs, Telephones, and Toasters
Mark Jackson
o References on computer-professional certification
John Shore
o CPSR/Boston presentation: "Reliability and Risk"
o Info on RISKS (comp.risks)

Re: Fidelity Mutual Funds Money Line feature

Martin Ewing <mse%Phobos.Caltech.Edu@DEImos.Caltech.Edu>
Thu, 23 Apr 87 23:09:11 PDT
I'm another user of Fidelity's Money Line, and am now just a tad more
nervous.  This last horror story confirms my latent suspicions. 

Fidelity EFTS transfers can be initiated automatically via their "FAST"
telephone system.  By calling an 800 number, and entering a sequence of some
20-30 digits, you can (1) get the status of your account (balance, last
investment, redemption, and dividend), (2) transfer between two existing
accounts, (3) transfer into a NEW account (in any of 60+ funds), and (4)
initiate an EFTS transfer from your bank account (if preauthorized).
Apparently all Fidelity accounts are born with FAST access.  All you (or
anyone else) need to commit fiscal mayhem are your Fidelity account number
and a security code which (are you ready for this?) consists of the last 4
digits of your Social Security Number.

All of Salander's troubles might have come from a malicious "friend" on the
telephone.  Even without slurping up funds from the bank, such a prankster
could create dozens of accounts for you in obscure funds. (Everything is
confirmed by mail, of course.) 

I had thought that the 24-hr human assistance line would have been
sufficient to correct any random computer errors.  Their attitude has been
good, in my experience.  However, one particularly chatty operator did let
on that, while she thought the FAST service was generally good, she
strongly recommended calling the assistance line for transactions.  "The
computer line has no backup," she said. 

I note that my discount brokerage is similarly lenient in telephone
transactions.  They don't have touchtone transactions, but they do take
orders over the phone with only my account number and no independent
verification.  There outta be a law.

And now my bank has installed "TeleService" with features similar to Fidelity. 


Re: Fidelity Mutual Funds Money Line feature

Brint Cooper <abc@BRL.ARPA>
Thu, 23 Apr 87 21:22:57 EDT
Thank you for sharing your story with us.  But why didn't you handle the
problem with the bank from the beginning?  Around here, I don't think a
bank can release funds except upon your authorization; and if you revoke
that authorization, they may no longer release funds.  

Then, upon occasion of the very first error, you simply close the bank account 
and withdraw all your money.  Fidelity is left "holding the bag," as it were.

I hope that, by sharing our experiences with the risks of computer systems, we
become more savvy at dealing with them.  We're users as well as developers.

   [I think we must all respond more forcefully when confronted with such
   human-caused and other computer horrors.  Perhaps a Ralph Nader-like
   group might be appropriate, but individual action can also have an
   effect, especially in quantity -- carefully worded nasty letters,
   withdrawals of accounts, threats of lawsuits, and so on.  PGN]


Re: Forgery on Usenet (Brad Templeton, RISKS DIGEST 4.77)

<mab@riacs.edu>
Fri, 24 Apr 87 07:32:12 -0800
Brad writes that there is no way to make USENET news secure, which is
perfectly correct (as has been pointed out.)  He goes on to say that "I
think lots of people have got secure uucp mail, at least within their
organization, these days."  Sorry, 'taint so.  First, on any BSD UNIX system
except 4.3, and probably on any other UNIX V7-based system, mail on any
machine can be trivially forged, because they all use the "getlogin()"
routine to determine the sender.  (4.3 does it right -- it uses
"getpwuid(getuid())".)  Look at that routine sometime -- it's one of the
easiest to spoof.

If you have an SMTP mailer, things get to be even more fun.  SMTP does not
do verification! Just connect to your SMTP mailer as would a foreign host,
and you're off.  (To test this, we forged a letter from Opus the Penguin at
WhiteHouse.ARPA -- this was before domaining -- asking someone for pickled
herring heads for lunch, but if none were handy, for anything but squid.
Confused the heck out of the recipient until he asked the local mail guru,
me, what happened.)

There is an effort by the Internet Advisory Board Task Force on Privacy to
do something about protecting mail privacy and allowing it to be
authenticated.  The task force proposal will be transparent, so it can be
dropped onto any SMTP implementation.  If you're interested in this, grab a
copy of RFC 989 from the NIC.

Matt Bishop


Re: VCRs, Telephones, and Toasters

<MJackson.Wbst@Xerox.COM>
24 Apr 87 11:04:11 EDT (Friday)
Perhaps this is all fallout from cost-effective technology in one area
far outstripping advances in others?  It is marvelously cheap to
implement functions in silicon, but actuators and displays are still
(relatively) expensive.

Thus one has the digital watch with 37 functions, each accessed by some
unique manipulation of only four buttons.  For the VCR, providing a
screen display requires a (fairly inexpensive?) character generator, but
what about for a (non-video) telephone?

From a human factors viewpoint the effective bandwidth of the interface
limits the number of truly useful functions.  But from a marketing viewpoint
the ability to advertise a maximum number of (technically useful) functions
is very attractive, and may carry the day.  I suspect, therefore, that this
is going to get worse before it gets better.
                                                         Mark


References on computer-professional certification

John Shore <epiwrl!shore@seismo.CSS.GOV>
24 Apr 87 10:00:54 EST (Fri)
I'm putting together a bibliography concerning the certification 
of computer professionals, and I would appreciate some help.  

I would like references to material about

    (a) pros and cons of certification 
    (b) efforts related to certification
    (c) certification methods
    (d) current practice in other fields
    (e) history of certification in other fields

Depending on the length of the resulting bibliography, I'll either 
post it to RISKS or post an announcement about it.  

Thanks in advance.  

John Shore      epiwrl!shore@seismo.css.gov        ...seismo!epiwrl!shore

              [We have noted previously the question of whether certification 
              might help reduce risks resulting from human foibles during
              development, maintenance, etc.  John's request is thus very
              relevant here.  I look forward to the results!  PGN]


Presentation on Star Wars Computing April 29, Chelmsford MA

Jon Reeves <reeves@decvax.dec.com>
Fri, 24 Apr 87 13:13:32 edt
"Reliability and Risk", a multiprojector presentation on the computational
aspects of the Strategic Defense Initiative, will be given on Wednesday,
April 29, 7:30p.m. at the Old Town Hall, in Chelmsford Center.  Please
forward this to anyone whom you feel would be interested.  Thank you.  --Joe

           RELIABILITY AND RISK:  COMPUTERS AND NUCLEAR WAR
                 A 34-minute slide/tape presentation

Reliability and Risk...
   ...investigates whether computer errors in key military systems--some of
   them unpreventable errors--could trigger an inadvertent nuclear war.

   ...features technical, political, and military experts discussing the role
   of computers at the heart of civilian and military systems, from the space
   shuttle to nuclear weapons to Star Wars;

   ...describes the ways in which all large, complex computer systems make
   mistakes--often unexpected and unpreventable mistakes:
     o The 46-cent computer chip failure that led to a high-priority
       military alert.
     o The software error that led to the destruction of the first Venus probe.
     o The design flaw that caused a missile early-warning computer to
       mistake the rising moon for a fleet of Soviet missiles.

   ...explores the growing reliance on computerized decision making and how a
   computer error could trigger a disaster, especially in a time of crisis.

   ...explains why we should not rely exclusively on computers to make
   critical, life-and-death decisions.

   ...uses straightforward language and graphics and is recommended for all
   audiences.  No technical knowledge is required.

   ...received a Gold Award in the Association for Multi Image New England
   competition in November, 1986--the largest multi-image competition in the
   country.

Speakers in Reliability and Risk include:

o Lt. General James A. Abrahamson, Director, Strategic Defense Initiative
  Organization (SDIO)
o Lt. Col. Robert Bowman, Ph.D., US Air Force (retired), Former Director,
  Advanced Space Programs Development
o Dr. Robert S. Cooper, Former Director, Defense Advanced Research Projects
  Agency (DARPA)
o Dr. Arthur Macy Cox, Advisor to President Carter, SALT II Negotiations, and
  Director, American Committee on U.S.-Soviet Relations
o Admiral Noel Gaylor (retired), former Commander-in-Chief of the Pacific Fleet
o Dr. James Ionson, Director, SDIO Office of Innovative Science and Technology
o Severo Ornstein, Computer Scientist (retired) and Founder, Computer
  Professionals for Social Responsibility
o Professor David Parnas, Computer Scientist, Resigned from SDIO Panel on
  Computing in Support of Battle Management
o Dr. John Pike, Associate Director, Federation of American Scientists
o Dr. William Ury, Director, Harvard Nuclear Negotiation Project
o Actress Lee Grant as narrator
and many others

Reliability and Risk was produced by Interlock Media Associates and CPSR/Boston

Please report problems with the web pages to the maintainer

Top