Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!uflorida!haven!adm!xadmx!MOORE%MIDD.BITNET@mitvma.mit.edu From: MOORE%MIDD.BITNET@mitvma.mit.edu Newsgroups: comp.unix.questions Subject: ATM fraud Message-ID: <17853@adm.BRL.MIL> Date: 16 Dec 88 20:34:01 GMT Sender: news@adm.BRL.MIL Lines: 88 The following article recently appeared in the RISKS list. I think it's pretty telling on the state of ATM security and where things get stored. (This is not the whole issue of this digest, I'm just clipping the relevant article.) --------------------------------------------------------------------------- RISKS-LIST: RISKS-FORUM Digest Tuesday 6 December 1988 Volume 7 : Issue 88 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. FOR VOL i ISSUE j / ftp kl.sri.com / login anonymous (ANY NONNULL PASSWORD) / get stripe:risks-i.j ... (OR TRY cd stripe: / get risks-i.j ... Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85),(6,95). ---------------------------------------------------------------------- Date: Tue, 6 Dec 88 14:15:19 -0100 From: ref@ztivax.siemens.com (Dr Robert Frederking) Subject: Re: Automated teller theft (Risks 7.85) Organization: Siemens AG in Munich, W-Germany I wouldn't be too sure that there really was a "passkey" card; that may have been a story cooked up to explain the loss to the public without revealing how vulnerable the system actually is. I don't know what technology is currently being used, but about 10 years ago a friend and I were looking at some used computer equipment we were thinking of buying, in someone's garage. After we had chatted for a bit, and he apparently decided we were trustworthy, he told us that these computers were part of a banking machine system that he had bought, lock, stock, and barrel, and asked us if we would like to see the parts he wouldn't sell, for risk of being a party to a crime. Among other things, there was a bank card reader that would display the account and *PIN number* of a bank card you ran through it. It could also *write* these cards. There was a set of sixteen thumbwheels inside the machine to set parameters to the encoding algorithm, which no one at the bank thought to shuffle, and so were still set to the bank's choice! He pointed out that once a set of positions was chosen, a bank would never change them again, as this would require recalling all the cards in circulation for recoding. It isn't clear to me that this could have been used in this case (unless the PIN number is algorithmically related to the account number, or the thieves had access to a list of PIN numbers), but this fellow could have caused a fair amount of trouble if he had been dishonest. As for the daily limit, a friend of mine figured out once that you could easily exceed the daily limit. First ask for a balance. If the machine says it can't give you a balance at the moment, it means the line to the central database is down. You then withdraw the maximum daily amount. You do this on as many different machines as you can find. If the net is down, this is the total number of machines you can physically get to before the net comes back up. "Robert Frederking" ------------------------------------------------------------------------------ Personally, I think having the PIN recorded on the card is the silliest idea since holla-hoops. It should only be in the bank's main database. ATM machines could cache this information for periods to cut down on the traffic to the main machine. When an entered PIN didn't match a value in the cache, or wasn't in the cache at all, a lookup would be requested from the main database machine. In no case should an ATM ever disburse funds if it cannot maintain a good conection to the central mainframes. Of course, if the PIN was ever changed (which is an option I believe should be made availible, with the rule that PINs must be 4 or more digits, not all the same, etc. ...), a message would have to be sent to all ATMs to invalidate that cache entry. All in all, I don't see why a rather large ATM network could not be handled by ATMs with intelligence of your average PC and a central database machine along the lines of a small or medium sized mini (and maybe less). With this hardware, it should be straight forward enough to write properly functioning and secure code which is reasonably efficient. The interesting twist has to do with the national ATM nets. Anyone no what protocols they use, and what sort of authentication they provide ? Evan R. Moore Academic Computing Services Middlebury College BITNET: MOORE@MIDD Internet: 91erm@cc.williams.edu (A former life which forwards mail)