On 13 May 1993, the computer system used by the Palo Alto Library's six branches began to make a few small errors in processing requests. The staff considered the errors not too serious at that time. However, by 22 May, the problems had escalated seriously, and the service folks were called in. The system is an eight-year-old Ultimate System from Honeywell. Only used or reconditioned replacement parts are available. Unfortunately, the replacement parts turned out to be lemons, which further aggravated the situation. As a backup, the staff resorted to a read-only file that tells only what books the library owns, but not what is supposedly on the shelves. Consequently, all book-borrowing transactions had to be done by hand, while no returned books could be reshelved. A power surge on 25 May did further damage to the system, and on the 26th, the system was shut down completely for another week. Finally, the system was available again on 2 June, although considerable effort had to be devoted to processing the accumulation of returned books before operations returned to normal. [Source: an article by Rufus Jeffris in the Palo Alto Weekly, 9 June 1993, p. 11]
On 6th of June several Spanish cities and towns had too high number of people that could not vote because their name were not in the right list. In Spain, Instituto Nacional de Estadistica (INE) is responsible for computing and updating the polling lists. As the election was nation wide, these mistakes did not change any parliament member. However, next election will be a local one, and it seems that INE will not perform better, it will be much more difficult to explain to the people why they will not have the chance to change their majors. Miguel A. Gallardo Ortiz, PX86 Engineer UNIX&C freelance working on RSA crypto P.O. Box 17083 - E-28080 Madrid (Spain) Tel: (341) 474 38 09 - FAX: 473 81 97 firstname.lastname@example.org President of APEDANICA (Spanish Legal Computer Crime Research Association) ASOCIACION PARA LA PREVENCION Y ESTUDIO DE DELITOS ABUSOS Y NEGIGENCIAS EN INFORMATICA Y COMUNICACIONES AVANZADAS
I found this little piece buried in the NYTimes, 11 June 1993. No real mention is made of what the "hackers" (I suppose the word will never be rescued) did. Is anyone on RISK familiar with the details? And you have to wonder, given the size of notebook computers, and the ease of purchasing and storing them secretly, how the last clause mentioned could possibly be enforced. COMPUTER HACKERS ARE GIVEN FINES AND 5 YEARS' PROBATION SEATTLE, June 10 (Reuters) -- Two hackers who illegally infiltrated the computer systems last fall at the Boeing Company and the United States District Court here were each sentenced to five years of probation and 250 hours of community service, a clerk at the court said Wednesday. Magistrate David Wilson also ordered the two Seattle residents, Charles Anderson and Costa George Katsaniotis to pay a combined $30,000 in restitution. Boeing, which said at the time that none of its systems or data had been damaged by the unauthorized access, will get $28,000 of the fine and the court $2000 to defray costs of changing security and checking files. "As part of the probation they're not allowed to own a computer or computer accounts without the permission of the probation officer," the clerk added. 73 de Dave Weingart KB2CWF email@example.com firstname.lastname@example.org
I would like to address this subject; I am an Air Traffic Controller with 13 years experience in most control functions, including Radar and Oceanic Non-Radar. Most communications with pilots over or near land take place under VHF or UHF A/G radio. If, for example, I want to descend a flight to FL 240 (24,000 feet) I say "Flight No., descend and maintain flight level two four zero." The pilot will acknowledge by repeating his flight number and the assigned altitude, then begin a descent. (Well, lots of times they will question the altitude but let's not get into that <g>). At the same time I'm speaking, I will punch the flight id and altitude into my computer, and the assigned altitude will be displayed on the scope. But that bears no relation to what I've said, or the pilot heard or said back to me. I might be thinking 240, punch 240 into the computer, but say 220. I should catch the error when the pilot reads back the clearance, but I might not. I might say 240, but the pilot hears 220, and I don't catch the error on read-back. He might read back 240, but put 220 into his flight director. Each of these errors happens from time to time, and can cause problems. Using Mode S, I would enter the flight id and altitude and that would be sent to the cockpit, where the pilot would acknowledge by pressing a button. My display would indicate the acknowledgement. The pilot could still question the clearance via voice radio. Mode S would not eliminate errors; I might for example punch in the wrong flight id or altitude. But it should reduce greatly incidents in which the pilot is doing something other than what is shown on my display. Since I am continually scanning that display for potential conflicts, it is vital that it accurately reflect the intentions of the pilots. There will, I think, always be a pilot (though perhaps someday only one) but the pilot in command already leaves many tasks to the computer. A commercial airliner is on auto-pilot most of the time after take-off, and can begin a landing approach. The most advanced systems can make a landing in zero visibility conditions, which a human pilot cannot. Timothy Buchanan
"Across the Computer Divide, The Nerds face the Dummies" (Sunday NY Times, 6 June, p. 1) talked about "DOS for Dummies", and the lack of training. This has to do with productivity (computers with out training and expertise don't improve productivity). Marty Leisner email@example.com firstname.lastname@example.org
A little while ago someone at tis.com announced (on alt.security, among other places) that a reference PEM implementation was "freely" [sic] available for ftp in the US and Canada. Just for kicks, I tried it from here (the evil CH empire): % ftp ftp.tis.com Connected to AZALEA.TIS.COM. 530 Only DNS registered hosts in the US/Canada can use this server. I haven't extensively played with their system, but I'd suspect they are reverse-resolving the IP address to a fully-qualified domain name, and seeing if the top-most domain is an old three-letter type (or possibly ".us" or ".ca"), or an international two-letter (e.g, ".uk" or ".ch"). I'm sure we can all evaluate the security of this method. > I don't see anything to stop (for example) groups from outside the US > lobbying this email service by pretending to be "the people" from "this > country." Well, the system for the USA's House of Representatives requires that any would-be e-mail sender first send a (real) postcard to their rep, listing their actual address and their e-mail address. This would provide a link from any e-mail message to a real location in the rep's district. All replies are via real mail, anyway, presumably to the address on the postcard. BTW, ftpmail to ftp.tis.com works ;-) Frederick G. M. Roeber | CERN -- European Center for Nuclear Research CERN/PPE, 1211 Geneva 23, Switzerland email@example.com +41 22 767 31 80 [Postcard scheme also noted by firstname.lastname@example.org (John Bruner). REAL SECURITY, eh? PGN]
It is possible that some whitehouse mail that is "correctly" addressed is being rejected because the recipient addresses contain mail metacharacters. This is a draconian mechanism to prevent folks from routing mail so it appears to have originated from whitehouse.gov, by talking to the SMTP port, I.e.: sol-> telnet whitehouse.gov 25 Trying 188.8.131.52 ... Connected to whitehouse.gov. Escape character is '^]'. 220 whitehouse.gov SMTP/smap Ready. helo whitehouse.gov 250 (whitehouse.gov) pleased to meet you. mail From: clinton 250 clinton... Sender Ok rcpt To: email@example.com 550 Recipient must be in form of: user, firstname.lastname@example.org, or email@example.com This has the unfortunate side effect that mailers that generate cruft like INfirstname.lastname@example.org will run afoul of the destination check.
I also heard the NPR report cited in 14.72 by Shyamal Jajodia <SHYAM@mitvmc.mit.edu>. NPR described more than the preparation of lobbying letters for targeted mailing lists to send on to their representatives. The new Astroturf (r) lobbying techniques also include the following horror: The consulting outfit contracts with a lobbyist to generate not mail, but PHONE CALLS, to congressional offices. They then telephone "grass roots" citizens and, having given them a sketch of the issue, say "If you agree with us that this issue is important, we can connect you with Congressman Wintergreen right now, so that you can express your opinion to him." Then they "patch" the callee through to the congressperson's office, get off the line, and it's on to the next call. In this way they can generate a constant flux of phone calls, seemingly spontaneous, from private citizens, in support of any issue. The more sophisticated congressional staffs have already learned to detect this kind of lobbying; they ask a few detailed questions about the issues and find that the caller completely lacks any substantive background information. The RISK is that it becomes increasingly difficult for the congressional staff to winnow the wheat (sincere opinion from concerned citizens) from the Astroturf chaff, and that modern information technology is what enables the consulting firm to provide this "service." Max.Stern@TorreyPinesCA.ncr.com
This [risk] has been routinely dealt with in the process control industry for decades. About 15 years ago, I was working on systems for the potato chip (US)/crisp (UK) manufacturing industry which handled hundreds of tons of sliced potato per hour being run through a fryer containing 3 tons of corn oil. As long as the oil level/oil pump/heater thermostat interlocks didn't fail spectacularly, there was no problem. Admittedly, we had a rotating orange light and a *loud* siren on top of the control panel that was the "if all else fails, run away" warning. And I won't mention the time a supervisor dropped a clipboard onto the fryer input belt (which ran at several hundred feet a minute.) Cheese & onion clipboard, anyone? Huge.email@example.com Rank Xerox Technical Centre, WGC, UK.
}... I've never made two transactions in a row on a Citibank ATM, so I }can't be sure that the language question is routinely presented again ... It isn't. Language is chosen at start of session. The only way to arrive at the situation you found is for someone to dip their card, then change their mind and walk away. Further, if you check I think you'll find the ATM asks for the PIN _after_ language selection (so the PIN entry screen will be in the correct language). Thus, what you saw was much less of a security risk than it seemed. Jerry Hollombe, aka: firstname.lastname@example.org Head Robot Wrangler at Citicorp Usual disclaimers [not Citicorp policy or official Citicorp anything]
Generally speaking (at least, among the many ATM's I've used in the NYMet area), if an ATM sits idle for a period of time (and this period seems to be less than one minute, admittedly a fairly long period of time), it will prompt you for your PIN again before allowing you to make a withdrawal, presumably as a protection against just such opportunistic attacks on your account. This protection is lessened if you aren't carful about shielding your PIN as you punch it in to the extremely large and easy-to-read display. What's interesting to note about the Citibank ATM's (if not a RISK associated with them), is the braille strips around the slots. Since it's a touch screen, with no physical keypad, someone who's blind (ooops, pardon me..."optically challenged") can't use it anyway! 73 de Dave Weingart KB2CWF email@example.com firstname.lastname@example.org
To start with, I am a programmer and I do work at Citibank, but I don't know any more about the design of the ATMs than the average person. Nonetheless, I use them all the time. Anyway, the ATMs, at least the ones in most of the Manhattan locations, ask "What language to you want to speak?" before asking for the PIN. Since the ATMs support languages that don't use the Roman alphabet (like Chinese and Japanese, although I don't know either so I can't tell which is which from the buttons) , the numbers on the PIN keypad would have to be different for those languages. And even though the ATMs don't "eat the card," they ask for the PIN frequently. At the very least, they appear to ask before every "Get Cash" transaction, and I think they ask before money transfers as well. However, I don't know the exact algorithm, so I wonder if they also ask before one tries to see someone else's account balances or transaction history. greg [Disclaimers...] [Similar comments from Mark Eckenwiler email@example.com ...!cmcl2!panix!eck]
If Jerry is trying to claim that cryptography is born classified, like nuclear technology, then I believe he is wrong. The NSA tried to push this concept back in the late 1970's and it was tossed out, as I recall. As a result, I am allowed to publish anything about cryptography in any international journal or speak at a conference giving details of my work without getting approval of any government agency. The NSA, in the late 1970's, tried to make it otherwise: that a citizen had to get permission to publish or speak on cryptography and couldn't speak to any foreigners.
On June 9, 1993, Congressman Edward Markey, Chairman of the House Subcommittee on Telecommunications and Finance held an oversight hearing on encryption and telecommunications network security. Panelists were Whitfield Diffie of Sun Microsystems, Dr. Dorothy Denning, Steven Bryen of Secure Communications, Marc Rotenberg of the CPSR Washington Office and E.R. Kerkeslager of AT&T. Congressman Markey, after hearing the testimony presented, noted that the Clipper proposal had raised an *arched eyebrow among the whole committee* and that the committee viewed the proposal skeptically. This statement was the latest indication that the Clipper proposal has not been well received by policy makers. Last Friday, the Computer Systems Security and Privacy Advisory Board of NIST issued two resolutions critical of the encryption plan, suggesting that further study was required and that implementation of the plan should be delayed until the review is completed. At the Third CPSR Cryptography and Privacy Conference on Monday, June 7, the Acting Director of NIST, Raymond Kammer, announced that the implementation of the proposal will be delayed and that a more comprehensive review will be undertaken. The review is due in the fall. Kammer told the Washington Post that maybe we won't continue in the direction we started out. The full text is available by anonymous ftp from cpsr.org /cpsr/crypto/clipper
The unit should have been mG (milligauss). The text had been "corrected" by a typist. I think that we corrected the error in the galleys. The book is _Phantom Risk_ (Foster,Bernstein, Huber, eds), MIT Press 1993. Strictly speaking, the correct unit should be Tesla; in discussions of health effects of magnetic fields the unit Gauss is usually used. For nonmagnetic materials it is appropriate as well. Kenneth R. Foster
Please forgive me if any of what follows seems uncharitable; I truly don't mean it to be a personal attack, nor to I wish to appear non-humble. Two corrections were posted in RISKS-14.72, pointing out errors in the RISKS-14.71 directions for getting to a conference by Metro (the DC subway system) from National Airport. There was indeed an error in the original directions. I posted one set of corrections; that set is, to the best of my knowledge, reliable. I stand by my correction, and I'm more humble than you are! :-) The other correction was posted by one of our esteemed colleagues, and in correcting the (one) error in the original directions, he regrettably introduced two new errors. (Perhaps we should stop before we're even farther behind?) 1. The yellow train to take from National Airport is labeled "Mt. Vernon Sq." It "does not--and never has--" gone to U Street/Cardozo. (He's thinking of the green train, which is irrelevant to our intent; when the end-of-track was extended from Gallery Place to U Street for the new green line, the yellow train's terminus was extended up the new track beyond Gallery Place, too--but only to Mt. Vernon Square.) 2. The blue train through Metro center (both of which are ideally irrelevant to our discussion) says "Addison Road," not "New Carrolton." The New Carrolton train is the orange line, which is--suffice it to say, you don't want to hear about it. :-) BTW, if you're at the National Airport station and see a blue train labeled "Addison Road," ignore it: it's a lot slower than the yellow train. TRUST ME :-) --here are the correct directions, again: Take the yellow train labeled "Mt. Verson Sq." to Gallery Place; there, transfer to a red train labeled "Shady Grove." Your destination is the Twinbrook station. Piece of cake. Unfortunately, the real tragedy of all this confusion is that it will probably put off lots of people who would otherwise have taken the subway, which really is an easy and enjoyable way to travel from National Airport to the hotel. It's also one of the cheapest. Buses cost more and probably take longer. And the less you have to deal with taxis in this area, the happier you'll be: the correct fare is a lot, and hacks here are notorious for overcharging (not all cabs here use meters). Take the subway; you'll be glad you did. You have my word on it. :-)
I don't find botched Metro directions at all surprising. For example, the Blue line train actually goes to, and is labelled, "Addison Road". It's the Orange Line that runs to New Carrolton, which theoretically does not run from the Airport.
There is a hidden assumption that the use of cash is free to the supermarket. Whilst cash can be a moderately convenient means of exchange for the small sums in which individuals deal, or indeed for disguising huge transactions from the tax man, it is tremendously expensive to move it from place to place, and to protect it against both pervasive `evaporation' from the surface of the organisation, and from occasional shotgun-inspired haemorrhages. I plead relevance to RISKS, because it sometimes seems that things get sent (t)here because they mention technology -- risky or not -- and we do seem to assume that the absence of technology must at worst not be a bad thing.
Dollars, that's what! Dave Kristol posted asking if supermarket "price clubs" were used for building "buying profiles" detailed everything that you bought using that card. I have no way of knowing if this happens in other geographic areas, but in the Albany, NY area, the Price Chopper chain does exactly that. But wait; there's more (to shamelessly steal Popeil's ad line) the card for that "price club" is one and the same with the stores check cashing card. If you don't feel like having a business make a buck selling your personal information, you have to stand in line at the "courtesy" desk to get a check approved - amount of purchase only. Friends and I have each tried to get a card for the sole purpose of check cashing (I don't get their specials and they don't sell my information; sounds fair?) No way, Jose. So I have another solution - I won't shop there. Whenever my sad little Grand Union doesn't have some essential ingredient I must have, I go to Price Chopper and take the opportunity to complain about their policy (while pointing out that I spent c.$100 at Grand Union and $10 there.) The risk? that in an increasingly automated age, as checks become obsolete (very soon by all reports), they won't even need this extra card as the electronic hook to tie your purchase info to your demographic info. If you have to use a card to pay (whether credit or debit) they'll have the hook. Now is the time to get legislation passed to outlaw use of private information for purposes unrelated to a transaction that are not expressly approved. That principle has been advocated by the Privacy Commission and countless privacy experts for the past 25-30 years. Are we ready? Dave Carroll, NYS Div. of the Budget firstname.lastname@example.org
Dr. Mike Stonebraker here at Berkeley consults for a bunch of big retailers on database management (Stonebraker started the Ingres project, which he subsequently commercialized, in the early '70's). I've heard him give a talk on exactly this topic. Here's the gist of his story: Supermarkets will offer "frequent buyer discount" cards. If you use the card, they will automatically apply any manufacturer discount coupons that apply to your purchases. You don't need the paper coupons. The benefit to the consumer is that his grocery bill is lower. The store is able to track purchases by individual customers, which is good for the store in two ways. First, it can break down purchasing habits by whatever demographic information they can find, which may help them advertise and stock their shelves. Second, it can sell the names of all Coke purchasers to Pepsi, so that Pepsi can clutter up your mailbox with advertisements. This way, the store makes some extra money. The benefit to the manufacturer is that it finds out about your buying habits and can develop ad campaigns directed at you. The RISK, of course, is that previously anonymous transactions will be recorded, and details sold to people you don't know. If that bothers you, you should pay cash and not use any kind of discount card. Stonebraker's talk on the future use of database systems by retailers is pretty interesting. Big retailers like K-mart and Walmart in the US capture every single item sold at every cash register they own. The data are loaded into an enormous central database, where they're used in "data mining" applications to plan future purchases by the store. The main problem the retailers have right now is storage space and techniques for digesting the volume of data they have. If they could do it, they'd keep all purchase data forever, and issue queries like "When will knee-length powder-blue dresses come back into style?" Mike Olson, UC Berkeley (mao@cs.Berkeley.EDU)
To protect my job, I have to put the disclaimer first. As you can see from my X.400 address and sig, I work for MasterCard International. I've read a lot on the subject in company newsletters, etc., but the following remarks should be interpreted as cocktail-party conversation, not official statements from MasterCard International, Inc. Yes, the credit card companies are offering lower fees to grocers (also to movie theaters and fast food restaurants, as I recall). But there are fees, and as you say, grocers tend to have slender margins. So what's in it for them? Two things: (1) customers like having more payment options and some of them will pick a grocer who takes MasterCard over one who doesn't, and (2) people who are paying with plastic instead of "real money" run up higher bills. So customer traffic goes up and profit per customer transaction goes up. THAT's why MasterCard has been so successful in getting grocery stores to accept MasterCard. If any grocer who accepts MasterCard (or Cirrus ATM cards, or Maestro debit cards) is tracking purchases vs. card number, I haven't heard of it. On, the other hand, unless you're buying huge amounts of booze or something, the total RISK of such a database (it seems to me) would be a bit more junk mail, which hardly seems like a big deal when offset against the benefit of not having to carry cash or wait while a check is approved. And actually, since I don't think that grocers subscribe to the service that lets you look up address against card number, it probably couldn't even be used for that. (I know I've been doing all of my grocery shopping with my BankMate ATM/Maestro debit card for two years now; I love it.) If anybody wants to try and get an official statment on the subject out of MasterCard, they could try the following people in our Public Relations department: mc!Marianne_Fulgenzi@mhs.attmail.com, mc!Richard_Woods@mhs.attmail.com, or mc!Jana_Weatherbee@mhs.attmail.com. (X.400: c=us, admd=attmail, prmd=mastercard, and fill in sn= and gn= from the above list.) [Peter, you're "the press," why don't you try?] J. Brad Hicks Internet: mc!Brad_Hicks@mhs.attmail.com X.400: c=US admd=ATTMail prmd=MasterCard sn=Hicks gn=Brad
Please report problems with the web pages to the maintainer