MOORE%MIDD.BITNET@mitvma.mit.edu (12/17/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>risks-i.j ... (OR TRY cd stripe:<risks> / 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" <unido!ztivax!ref@uunet.UU.NET>
------------------------------------------------------------------------------
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)chris@mimsy.UUCP (Chris Torek) (12/17/88)
(I was hoping not to have to post this on a comp.unix group, but things are not getting any quieter, so:) Real Facts about ATMs: > Each system is different. One cannot even count on the machines from a specific manufacturer (e.g., IBM or Diebold) all to act the same, as many (if not all) of these systems can be configured by the purchasing bank. Therefore: > Every blanket statement about ATMs is wrong (including this one). > Some common systems do put PINs on cards; some common systems do not. > Some systems allow `local' operation of an ATM station when the net is down; some do not. (Local operation may be used to overrun daily limits.) > Some systems use DES encryption (in just what ways I am not sure). Of those that do, they may not do it in a `secure' manner. (You will find it very hard to pull this particular bit of information out of your local bank, particularly if they know it is insecure.) > Some systems `batch' the PIN verification with the first operation (so that a wrong PIN is not noticed until after a deposit, etc.). Others check the PIN immediately, even if it requires a network transaction. Thus you cannot conclude anything about where the PIN is stored based on when the machine rejects an invalid PIN. > Many systems that allow more than four digits for a PIN in fact only use the first four. > Some systems count PIN errors globally; some count it per-ATM; some use a mix (count locally iff net is down). Many set a `keep the card' threshold at 3 errors. Typically the count is reset once a day. Now can we stop with ATM security messages on comp.unix.questions? (And why do I ask such a silly question? :-) ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris