The RISKS Digest
Volume 5 Issue 24

Thursday, 6th August 1987

Forum on Risks to the Public in Computers and Related Systems

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

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…


o Another animal story
Bill Pase
o Re: Security-induced RISK
Henry Spencer
o Re: Factory automation and risks to jobs — "apparently" not
Randall Davis
o Railway automation
Scott E. Preece
o Nuclear generated electrical power and RISKS
Dave Benson
o PIN money?
o Re: Another ATM story
Scott Nelson
o Computer `assumes' the worst in billing for hotel phone calls
Bruce Forstall
o Info on RISKS (comp.risks)

Another animal story

Bill Pase <>
Wed, 5 Aug 87 12:51:34 edt
I just got this out of the info-atari16 mail group.
It illustrates one of the more unusual risks I've seen :-)

  Date: 22 Jul 87 03:54:28 GMT
  From: mtune!akgua!rbk@RUTGERS.EDU  (R. Brad Kummer)
  Subject: ST keyboard parts needed

  Does anyone have a damaged ST keyboard that they could send me a piece of?
  I need one of the little rubber "nipples" that sits under each key.  If you
  remove all those tiny screws from the back of the keyboard, there is a
  little rubber cup with a small piece of carbon attached underneath each key.

  Why do I need it?  Don't ask...  My kids spilled a Coke on the keyboard, I
  took the keyboard apart to clean it (that part worked fine), but I dropped
  one of the little "nipples" on the floor and the [...] dog ate it!

  If you could help me out, I'd be eternally grateful.  (Would you consider
  trading it for a dog? :-)

  Thanks, R. Brad Kummer, AT&T Bell Labs, Atlanta, GA {ihnp4, akgua}!akguc!rbk 

                                        [(Very lightly edited.)  Doggone!  PGN]

Re: Security-induced RISK

Wed, 5 Aug 87 13:31:36 EDT
Those not in the Unix community may not be aware of the excellent security
paper that was published in the Bell Labs Technical Journal a few years ago.
Some parts of it are Unix-specific, but much of it is fairly generic.  The
most interesting parts are discussions of how supposed enhancements in
security actually make things *worse*; the paper is clearly the result of
practical experience, not just theoretical navel-contemplation.  For example,
the problem of logs of incorrect login/password combinations being a source
of useful information is worse than it seems:  even just logs of login names
alone can be informative, because people do accidentally type passwords in
response to the login-name prompt now and then.  For another example, aging
schemes that try to enforce frequent password changes have bad side effects:
"...the most incredibly silly passwords tend to be found on systems equipped
with password aging...".

The paper is "UNIX Operating System Security", by F.T. Grampp and R.H. Morris,
AT&T Bell Laboratories Technical Journal, Vol. 63, No. 8, Oct. 1984, pages
1649-1672.  Any good engineering library will probably have the B.L.T.J.
(formerly the Bell System T.J.), since it is/was one of the top technical
journals of the communications industry.  This particular issue, the second
special issue on Unix, can also be ordered from AT&T, although I don't have
ordering details handy.

Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry

    [While you are in that issue, you might just keep on reading.  The paper
    following Grampp and Morris' is also worth looking at:  "File Security
    and the UNIX Crypt Command", J.A. Reeds and P.J. Weinberger, pages
    1673-83: "crypt" was not very secure.  PGN]

Date: Wed, 5 Aug 1987  16:54 EDT
Subject: Factory automation and risks to jobs — "apparently" not

From Risks 5.23:  (Factory automation and risks to jobs — James Coombs)
    The BIX report {on the effect of robots} was based on the work of Randall
    Davis, a professor at the MIT Alfred P. Sloan School of Management and the
    MIT Artificial Intelligence Laboratory.  Apparently Microbytes Daily 
    interviewed Davis.

"Apparently" is the key word here.

First of all, the information about robots and their potential impact on human
employment is the work of Warren Seering (prof of mechanical engineering at
MIT and a member of the AI Lab).  An accessible (and quite entertaining)
reference is his article in "Technology Review", April 1985 (pp 58-67); the
impact and cost figures are on pp. 66-67.

All of which I would have been happy to tell BIX, had they asked.  They didn't.

One of the RISKs of giving talks in public is having magazines quote as if
from an interview (I don't recall an interview with BIX; I do use those
figures as one slide in a 3-day long course).  This curious procedure is
apparently routine; it has in any case happened to me previously.  The
practice is at best disingenuous, suggesting that they have conducted a
careful interview and summarized it, rather than picked a few entertaining
sentences out of several hours of lecture.

It also quite often results in misinformation, as in this case.  When you have
an hour to explain a subject you do it one way; when faced with a reporter who
is going to reduce everything to single sentence pithy quotes, you proceed
quite differently (and quite a bit more carefully).

Railway automation

Scott E. Preece <preece%mycroft@gswd-vms.Gould.COM>
Wed, 5 Aug 87 09:06:09 CDT
  > Stephen Colwill <mcvax!praxis!steve@seismo.CSS.GOV>:
  > Secondly I fail to see how people who propose automatic control of
  > nuclear power stations and ATC can presume to do this when the
  > conceptually far simpler problem of the control of trains on a closed
  > railway network has not yet been solved after years of trying.

I'm not sure I agree that controlling trains (actually operating them,
as opposed to telling a human engine driver where she is supposed to
go) is conceptually simpler than controlling a nuclear power station.
A nuclear plant has a lot of sensors and actuators, in well known
locations and required to be in well defined relationships to each other.

A train is a large object whose position is only approximately known at best,
whose speed is hard to change and is changed using systems whose performance 
is subject to wild fluctuations with age, maintenance, and track conditions,
and whose surroundings are totally unvisible to the controlling system.

I wouldn't argue that a power plant is easier to control or safer,
but I think I would rate them similarly far beyond the realm of things I
feel comfortable about yielding to fully automatic control.

scott preece, gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece

Nuclear generated electrical power and RISKS

Dave Benson <>
Wed, 5 Aug 87 13:32:19 PDT
Other fora ("forums" for those under forty) are perhaps suitable for
expressions of political position regarding the mix of electrical
generation methods, including conservation.  We must recognize that
substantial computer related RISK is attached to nuclear reactor
generated electrical power, and that little computer related RISK
is attached to other generation methods or to conservation.  I am
disappointed that so little commentary occurs in RISKS regarding
computers as realtime control devices of nuclear power plants.

My interest in seeing more such commentary should not be taken as a
political position regarding the appropriate mixture of electrical
generation methods.  We might indeed all learn something about
mishap and accident prevention methods by learning more about what
is done in the nuclear power industry.

It seems perfectly consistent for a professional in computer related
areas to on the one hand be interested in learning more about computer
RISKS in nuclear power plants and on the other hand to take any
position whatsoever regarding the desirability of such.

I remind RISKS readers of the issues of AAAS Science, and the articles on 
risks and risk perception therein, which I cited on RISKS a few months ago.

In conclusion, I hope we might continue to see in RISKS contributions
regarding computer risks in the nuclear power industry, without thereby
attributing to either our Dear Moderator or to the Contributor any particular 
stance on the desirability of nuclear generated electrical power.  I would 
prefer the politics to appear elsewhere.
                                            David B. Benson  

[Me too.  (By the way, now this issue of RISKS has both fora and fauna.)  PGN]

PIN money?

6 Aug 87 14:11 CST
My credit union uses a PIN system that is designed in such a way that no one
is supposed to be able to obtain the PIN once it has been sent to you.  The
PIN is generated "randomly" and pre-sealed envelopes are produced with the
PIN printed on the inside via carbon paper, and a serial number is printed
on the outside of the envelope.  When the PIN envelope is sent to a card
holder, the serial number of the envelope is entered into the computer and
the serial number is cross-referenced to the PIN which is then stored in
that card's record.  If you forget your PIN number, a new envelope with a
new PIN is sent to you, because no one can access the actual PIN, only the
computer knows what it is.

Of course, that is the theory, but I'm sure that someone somewhere can
get to them given enough time.

  [MILNET TAC access cards are generated the same way from a dedicated non-
  net-accessible system managed by the Network Information Center at SRI.  PGN]

Re: Another ATM story

Scott Nelson <esunix!>
Wed, 5 Aug 87 13:23:29 mdt
In RISKS 5.22:  mogul@decwrl.DEC.COM (Jeffrey Mogul) says:
> A friend of mine tried to withdraw money from a Versateller (Bank of
> America; she's a BofA customer).  After asking her to re-enter her PIN
> several times, it told her to give up...

This happened to me when I needed cash for the weekend (on a Saturday morning).
From talking to the "ATM expert" at the credit union, I found out that the ATM
asks you three times to re-enter your PIN, then determines that you should
not be allowed any further transactions for the rest of the day.  In my case
it had a blank line where my name normally is when it first says "hello".

The solution, according to the ATM expert is to immediately hit cancel when
the machine asks for your PIN a second time, clean the magnetic strip on the
card, and try again.  This method has worked since then.  I don't understand
why the ATM can't figure out that something is wrong when it reads the card.
Don't they use checksums?

Assuming an ATM will work properly when you need it leads to the
risk of being without any cash over a 3-day weekend.  Now I only
use them to avoid a long line inside during business hours.

Scott R. Nelson, Evans & Sutherland Computer Corporation

UUCP Address:  {decvax,ucbvax,ihnp4,allegra}!decwrl!esunix!nelson
Alternates:    {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!nelson

``Computer `assumes' the worst in billing for hotel phone calls''

Bruce Forstall <>
Thu, 6 Aug 87 09:25:59 PDT
Seattle Times, Wed. 8/5/87 (used without permission):

    We knew it would happen eventually.  Computers do this, computers do
that.  Now, we're told, computers *assume*.  M.G., a Bellevue consumer,
learned this when he tried to phone home from the Red Lion Inn at Portland's
Lloyd Center.  He phoned several times and no one answered, but he was
charged for making long-distance calls.  When he inquired about the charges,
he was told the hotel computer ``assumed'' he had made a connection and
talked with someone at the number he dialed.  When M.G. explained to a live
desk clerk at the hotel that no one had answered his phone calls, the
charges were removed from his bill.  M.G. suspects that many travelers pay
such phone charges without realizing they've paid to hear a brrr-ring, not
to speak with a real person.

    Is this practice sanctioned by the Washington state Utilities and
Transportation Commision?  M.G. asked.  Hotel and motel phone systems are
private telecommunications systems, and are specifically exempt from
regulation by state law, according to Susan E. Sumner, public-information
officer for the commision.  Sumner checked with Red Lion headquarters and
was told the hotel's computer equipment cannot determine whether a call that
has been placed actually has been answered.  ``Consequently, in the first 45
seconds after a call has been placed, the computer `assumes' the call has
been answered,'' Sumner said.

    The hotel's policy is to adjust the bills of guests who have been
charged for calls that were not completed.  Red Lion's management has
indicated that printed notices will be placed by phones in rooms so guests
will know how they are being charged for these calls.  It would be wise for
consumers to ask about this policy when checking into any hotel.  Some
hotels and motels charge an access fee even when consumers use their own
credit cards to make long-distance calls.
                Shelby Gilje, Times staff columnist

--Bruce Forstall   ...!uw-beaver!uw-larry!forstall

                       [Old-time RISKS readers who are still with us after 
                       two years may remember earlier discussions of this 
                       problem, or by now might have forgotten...  PGN]

Please report problems with the web pages to the maintainer