home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky sci.crypt:3152 alt.security:4300 comp.security.misc:1199
- Newsgroups: sci.crypt,alt.security,comp.security.misc,local.crypto
- Path: sparky!uunet!spool.mu.edu!think.com!paperboy.osf.org!osf.org!karger
- From: karger@osf.org (Paul A. Karger)
- Subject: Re: ATM fraud
- Message-ID: <1992Sep8.164652.1780@osf.org>
- Sender: news@osf.org (USENET News System)
- Organization: Open Software Foundation
- References: <1992Sep8.115050.8694@cl.cam.ac.uk>
- Date: Tue, 8 Sep 1992 16:46:52 GMT
- Lines: 21
-
- In article <1992Sep8.115050.8694@cl.cam.ac.uk>, rja14@cl.cam.ac.uk (Ross Anderson) writes:
-
- |> This sort of `false terminal attack' was first reported in the USA in
- |> about 1988. You'd think the banks would warn people about it, but
- |> instead they seem determined to introduce PIN pads in retail outlets
- |> here. The idiots seem to believe that this will cut fraud from the
- |> current \pounds 200 million plus, but in practice it means that every
- |> bent merchant in the country will be able to collect card and PIN data.
-
- This type of attack has been going on for a lot longer than that, and it
- doesn't require a fraudulent merchant to perpetrate. There were a couple of
- cases in the late 70s/early 80s of someone building a bogus ATM machine and
- placing it directly in front of a real bank ATM machine. I believe one case
- was in New York and the other in Italy, but my memory may be flakey on this
- point.
-
- This points up the need for one of the B2 and up security measures from
- the orange book - namely trusted path. There must be a way for the user
- to authenticate to the system, but there must also be a way for the system
- to authenticate itself to the user, so that user knows that this is the
- real bank ATM or terminal or workstation or whatever...
-