ATM fraud

[MOORE%MIDD.BITNET at mitvma.mit.edu]

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 at CSL.SRI.COM, with relevant, substantive "Subject:" line
(otherwise they may be ignored).  REQUESTS to RISKS-Request at 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 at 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 at 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 at MIDD
Internet: 91erm at cc.williams.edu (A former life which forwards mail)