6-Aug-87 22:42:53-PDT,15367;000000000000 Return-Path: Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Thu 6 Aug 87 22:37:52-PDT Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16) id AA02693 for RISKS-LIST@f4.csl.sri.com; Thu, 6 Aug 87 22:39:30 PDT Message-Id: <8708070539.AA02693@csl.csl.sri.com> Date: Thu 6 Aug 87 22:35:31-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 5.24 Sender: NEUMANN@csl.sri.com To: RISKS-LIST@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday, 6 August 1987 Volume 5 : Issue 24 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Another animal story (Bill Pase) Re: Security-induced RISK (Henry Spencer) Re: Factory automation and risks to jobs -- "apparently" not (Randall Davis) Railway automation (Scott E. Preece) Nuclear generated electrical power and RISKS (Dave Benson) PIN money? (BJORNDKG) Re: Another ATM story (Scott Nelson) Computer `assumes' the worst in billing for hotel phone calls (Bruce Forstall) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. FTP back issues Vol i Issue j from F4.CSL.SRI.COM:RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97). ---------------------------------------------------------------------- Date: Wed, 5 Aug 87 12:51:34 edt From: bill@ipsa.arpa (Bill Pase) To: risks@csl.sri.com Subject: Another animal story 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 To: info-atari16@score.stanford.edu 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] ------------------------------ Date: Wed, 5 Aug 87 13:31:36 EDT From: mnetor!utzoo!henry@uunet.UU.NET To: RISKS@csl.sri.com Subject: Re: Security-induced RISK 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 From: DAVIS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: Risks@csl.sri.com 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). ------------------------------ Date: Wed, 5 Aug 87 09:06:09 CDT From: preece%mycroft@gswd-vms.Gould.COM (Scott E. Preece) To: RISKS@csl.sri.com Subject: Railway automation > Stephen Colwill : > 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 ------------------------------ Date: Wed, 5 Aug 87 13:32:19 PDT From: Dave Benson To: risks%csl.sri.com@RELAY.CS.NET Subject: Nuclear generated electrical power and RISKS 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] ------------------------------ Date: 6 Aug 87 14:11 CST From: BJORNDKG%UREGINA1.bitnet@csl.sri.com To: RISKS@csl.sri.com Subject: PIN money? 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] ------------------------------ Date: Wed, 5 Aug 87 13:23:29 mdt From: esunix!nelson@decwrl.dec.com (Scott Nelson) To: decwrl!risks@csl.sri.com Subject: Re: Another ATM story 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 seismo!usna!esunix!nelson ------------------------------ Date: Thu, 6 Aug 87 09:25:59 PDT From: forstall@larry.cs.washington.edu (Bruce Forstall) To: RISKS@csl.sri.com Subject: ``Computer `assumes' the worst in billing for hotel phone calls'' 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] ------------------------------ End of RISKS-FORUM Digest ************************ -------