phil@wubios.wustl.edu (J. Philip Miller) (09/12/90)
In article <12026@accuvax.nwu.edu> Dave Speed <dspeed@well.uucp> writes: >On a similar note, our local <Sacramento, CA> grocery chain has >installed pseudo ATM's for banking from the checkout line. Perhaps I'm >paranoid, but I don't see any advantage (to *me*) in giving the >merchant my bank number and PIN. Am I being silly ? Well, this gets a bit far from Telecom, but there are several potential advantages to the consumer from this type of arrangement: For certain types of checking accounts from some banks, this type of transaction may be free, while writing a check is not. Many retail stores (particularly grocery stores) require a special "check cashing card" from that store to write a check. Using your ATM card to make the purchase reduces the number of cards you need (and in many cases the number of PINs you need to recall). This is even more important if you are shopping outside of your normal area. I don't really see that the security implications are much different than giving a store your Visa card and they run it thru their card reader. Now to give it some Telecom relevance: The proliferation of ATM terminals and retail stores using ATM type cards seems to be particularly popular in urban areas, but seems to be much less popular in small town America. Now this may be because of attitude differences, but I have assumed that much of it is also due to the fact that connecting the terminal to necessary host equipment is also considerably more expensive and thus the amount of traffic for a particular location would need to be much higher for a rural location than an urban one. Can someone knowledgeable describe the typical type of connections utilized by ATM equipment (both stand alone and in conjunction with a point of sale terminal)? J. Philip Miller, Professor, Division of Biostatistics, Box 8067 Washington University Medical School, St. Louis MO 63110 phil@wubios.WUstl.edu - Internet (314) 362-3617 uunet!wuarchive!wubios!phil - UUCP (314)362-2693(FAX) C90562JM@WUVMD - bitnet
MCMAHON%GRIN1.BITNET@cunyvm.cuny.edu (McMahon,Brian D) (09/14/90)
J. Philip Miller <phil@wubios.wustl.edu> writes: >The proliferation of ATM terminals and retail stores using ATM type >cards seems to be particularly popular in urban areas, but seems to be >much less popular in small town America. Now this may be because of >attitude differences, but I have assumed that much of it is also due >to the fact that connecting the terminal to necessary host equipment >is also considerably more expensive and thus the amount of traffic for >a particular location would need to be much higher for a rural >location than an urban one. It may also be that the need for point-of-sale systems is less pressing in rural communities. It's much easier to cash a check in smaller towns. Take Grinnell (pop. 9000) as an example. Few of the local merchants require identification even for out-of-town checks. When I lived and worked in the Washington D.C. area, it was next to IMPOSSIBLE to cash a check without producing an I.D. *and* a major credit card. Now, I did notice a POS machine at Iowa Book & Supply a while ago, but that's in Iowa city. You know, the big city. :-) On the other hand, Farm Service is installing one of their Fuel-24 (or whatever it's called, the advertisment is at home) stations here, which are gas pump that take a special credit card. Open 24 hours, no need for an attendant. You just drive up, insert your card, and start pumping gas. This suggests that where the service meets local demand, it *is* feasible to set up POS in smaller communities... Brian McMahon <MCMAHON@GRIN1.BITNET> Grinnell College Computer Services Grinnell, Iowa 50112 USA Voice: +1 515 269 4901 / Fax: +1 515 269 4936
carroll@beaver.cs.washington.edu (Jeff Carroll) (09/18/90)
In article <12065@accuvax.nwu.edu> phil@wubios.wustl.edu (J. Philip Miller) writes: >In article <12026@accuvax.nwu.edu> Dave Speed <dspeed@well.uucp> >writes: >>On a similar note, our local <Sacramento, CA> grocery chain has >>installed pseudo ATM's for banking from the checkout line. Perhaps I'm >>paranoid, but I don't see any advantage (to *me*) in giving the >>merchant my bank number and PIN. Am I being silly? I asked myself the same question the other night when I bought gas at an Arco station in a fairly unsavory part of town (not far from my office :^) ). Since the POS terminal asks you whether you want a receipt, I pushed "yes" and walked into the station, as directed by the machine. The rather harried clerk looked at me, surmised since I was standing outside the turnstile that I was a POS customer waiting for a receipt, and then took a *long* piece of cash register tape into his hand. In addition to gas receipts from the POS terminal, this tape was printing receipts for every Pepsi and Hostess Twinkie passing through the cash register. After a few seconds of puzzling over the tape, the clerk asked me which pump I used, and more puzzling ensued until the printer started growling again. Clerk: "Oh, here it is.". He ripped the tape from the printer, removed the piece of the tape containing my receipt, and (presumably) threw the rest away. I checked the tape - it did not contain my PIN. I've concluded that if the PIN *does* find its way into Atlantic Richfield's network, it's not likely to do so in such a form as to become archived anywhere. What legal purpose could be served by such a database? >Well, this gets a bit far from Telecom, but there are several potential >advantages to the consumer from this type of arrangement: >For certain types of checking accounts from some banks, this type of >transaction may be free, while writing a check is not. Or, in this case, writing a check is impossible (would be free if the gas station accepted checks), and this type of transaction is not (Arco charges $0.10 transaction fee). To me the advantage is merely not having to stand in line behind a bunch of people buying cigarettes, pseudo-hot dogs, and Ho-Hos. (stuff excised) >The proliferation of ATM terminals and retail stores using ATM type >cards seems to be particularly popular in urban areas, but seems to be >much less popular in small town America. Now this may be because of >attitude differences, but I have assumed that much of it is also due >to the fact that connecting the terminal to necessary host equipment >is also considerably more expensive and thus the amount of traffic for >a particular location would need to be much higher for a rural >location than an urban one. Can someone knowledgeable describe the >typical type of connections utilized by ATM equipment (both stand >alone and in conjunction with a point of sale terminal)? I would assume that the functional differences between an ATM and a POS terminal would be embedded in the terminals themselves. Both use plain ole asynchronous modems (usually hidden where you can't see them, but sometimes where you can see them but can't get at them. The usual scheme (I believe) is that the ATM dials up a central site which multiplexes several signals and connects to the network's central mainframe (often via satellite link). It may not be cost effective to run ATMs in locations that are far removed from the central site of a bank/retailer which uses land lines, but even in remote localities it would be easy for large retailers who already have satellite networks in place (e.g., Safeway, which distributes its own background music via satellite to a downlink in each store, at least in this part of the country) to have ATMs and POS terminals. The parts of "small-town America" which I frequent are well populated with them. Jeff Carroll carroll@atc.boeing.com
friedl@mtndew.tustin.ca.us (Steve Friedl) (09/20/90)
In article <12318@accuvax.nwu.edu>, bcsaic!carroll@beaver.cs. washington.edu (Jeff Carroll) writes: > I've concluded that if the PIN *does* find its way into > Atlantic Richfield's network, it's not likely to do so in such a form > as to become archived anywhere. What legal purpose could be served by > such a database? ARCO does not keep this information at all. The in-store computers have no way of getting the information from the network, and the financial software that does the mini-market accounting does not use it at all either [runs on a 3B15]. The franchisees don't get the $.10 either, ARCO does and probably helps pay for the network. Stephen J. Friedl, KA8CMY / I speak for me only / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (09/20/90)
In article <12026@accuvax.nwu.edu> Dave Speed <dspeed@well.uucp> writes: >On a similar note, our local <Sacramento, CA> grocery chain has >installed pseudo ATM's for banking from the checkout line. Perhaps I'm >paranoid, but I don't see any advantage (to *me*) in giving the >merchant my bank number and PIN. Am I being silly ? You are not giving your PIN number to the merchant. The PIN is encrypted (mixed with your bank card number) in a ONE WAY algorithm by a chip that is in the PIN pad itself. The plaintext PIN never sees the light of day. Marc Kaufman (kaufman@Neon.stanford.edu)
king@uunet.uu.net (Steven King) (09/23/90)
In article <12439@accuvax.nwu.edu> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: >You are not giving your PIN number to the merchant. The PIN is >encrypted (mixed with your bank card number) in a ONE WAY algorithm by >a chip that is in the PIN pad itself. The plaintext PIN never sees >the light of day. A one way algorithm? Pray, how does the bank decode it to verify you? A gigantic lookup table? I really am curious about this, the sarcasm is just a side-effect. :-) Steve King, Motorola Cellular (...uunet!motcid!king)
Randal Schwartz <merlyn@iwarp.intel.com> (09/24/90)
In article <12469@accuvax.nwu.edu>, motcid!king@uunet (Steven King) writes: | >You are not giving your PIN number to the merchant. The PIN is | >encrypted (mixed with your bank card number) in a ONE WAY algorithm by | >a chip that is in the PIN pad itself. The plaintext PIN never sees | >the light of day. | A one way algorithm? Pray, how does the bank decode it to verify you? | A gigantic lookup table? | I really am curious about this, the sarcasm is just a side-effect. :-) One algorithm is a query-response ... Bank sends QUERY (a random number) to merchant box. Merchant box sends QUERY to keypad. You enter PIN into keypad. Chip in keypad computes oneway (QUERY,PIN) as RESPONSE, sends that to merchant box. Merchant box sends RESPONSE to bank. Bank computes oneway (QUERY,PIN), compares it with RESPONSE, and says yay or nay. See... the PIN is both at the bank, and in the keypad, but nowhere else. And recording the traffic for later replay won't help. (Yes, there are *other* ways.) Just another security weenie, Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn
David Lemson <FREE0612@uiucvmd> (09/24/90)
In a message of 23 Sep 90 16:49:02 GMT, Steven King <motcid!king@ uunet.uu.net> writes: >In article <12439@accuvax.nwu.edu> kaufman@Neon.Stanford.EDU (Marc T. >Kaufman) writes: >>You are not giving your PIN number to the merchant. The PIN is >>encrypted (mixed with your bank card number) in a ONE WAY algorithm by >>a chip that is in the PIN pad itself. The plaintext PIN never sees >>the light of day. >A one way algorithm? Pray, how does the bank decode it to verify you? >A gigantic lookup table? The bank doesn't need to "decode" it. The bank's computer knows what your PIN is supposed to be. So, it codes it with the same trap-door algorithm as the keypad did, and compares the two. FYI, this is the same way that the Unix operating system encrypts passwords with a one-way coding scheme, and stores them encoded. My guess is that your bank's computer stores your PIN encoded, so it simply compares the encoded incoming message with the encoded number stored in the machine. David Lemson d-lemson@uiuc.edu
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (09/24/90)
In article <12469@accuvax.nwu.edu> motcid!king@uunet.uu.net (Steven King) writes: >In article <12439@accuvax.nwu.edu> I write: ->You are not giving your PIN number to the merchant. The PIN is ->encrypted (mixed with your bank card number) in a ONE WAY algorithm by ->a chip that is in the PIN pad itself. The plaintext PIN never sees ->the light of day. >A one way algorithm? Pray, how does the bank decode it to verify you? >A gigantic lookup table? No, the bank stores the encrypted PIN and does a straight match. The technique was invented by John Atalla, one of the early Fairchild people. Most of the bank PIN pads I have seen have been made by Atalla Technovations. The chip performs a one-way (e.g. many-to-one) encryption of an arbitrary number of key presses. It is sufficiently slow (deliberately) so that even if you got one of them it would take a VERY long time to try to find a sequence that gives you a particular output word. Since you really don't have access to the data link side of the system, you can't spoof it there. The link between an ATM (or merchant system) and the bank is encrypted also, so picking up the pair outside the building won't work either. By far the easiest way to learn a person's PIN is to look over his shoulder while he is typing it in (or hold him up at gunpoint). Marc Kaufman (kaufman@Neon.stanford.edu)
jimb@silvlis.com (Jim Budler) (09/25/90)
In article <12509@accuvax.nwu.edu> FREE0612@uiucvmd (David Lemson) writes: >In a message of 23 Sep 90 16:49:02 GMT, Steven King <motcid!king@ >uunet.uu.net> writes: >>In article <12439@accuvax.nwu.edu> kaufman@Neon.Stanford.EDU (Marc T. >>Kaufman) writes: >>>You are not giving your PIN number to the merchant. The PIN is >>>encrypted (mixed with your bank card number) in a ONE WAY algorithm by >>>a chip that is in the PIN pad itself. The plaintext PIN never sees >>>the light of day. >>A one way algorithm? Pray, how does the bank decode it to verify you? >>A gigantic lookup table? > The bank doesn't need to "decode" it. The bank's computer knows >what your PIN is supposed to be. So, it codes it with the same >trap-door algorithm as the keypad did, and compares the two. FYI, >this is the same way that the Unix operating system encrypts passwords >with a one-way coding scheme, and stores them encoded. My guess is >that your bank's computer stores your PIN encoded, so it simply >compares the encoded incoming message with the encoded number stored >in the machine. I'm not even positive the bank always has your PIN in the first place. Last year I was one of the lucky people to receive a letter telling me that my Versateller card was being shut down, and that I would receive a new one in a few days. Concurrently my HomeBanking stopped also. This shutdown occurred because some people at one of the system providers broke their trust and obtained a significant block of records containing names, ATM numbers and PINs. By system providers I mean the companies like Plus System, or Star, who connect to the retail merchants and route request from the retail merchants to the bank ATM computer. The service providers are not necessarily banks, they are potentially just a wholesale transaction merchant. They do their thing for the $1 - $2 per transaction that they get paid for facilitating the transaction. So in the past some "merchant's employees", not a merchant, and actually not the retail merchant did exactly what was feared at the start of this thread. It took three seperate mailings to get my Versatel card back in action. 1. The notice of the action and its cause. 2. The new Versatel account number and card. 3. A form on which I selected a new PIN to replace my old one. My old PIN was time bombed so I was forced to select a new one. Now back to the encryption algorythm. There actually was a transposition pad on the form, so I encrypted my PIN, and sent the encrypted PIN, not the PIN itself back to the Bank. In addition, the PIN could now be variable length, and the length was not reflected in the encrypted PIN I sent back to the bank. So I'm not sure the bank ever has ny unencrypted PIN. Who knows, though? Only the bank, for sure. Jim Budler jimb@silvlis.com +1.408.991.6115 Silvar-Lisco, Inc. 703 E. Evelyn Ave. Sunnyvale, Ca. 94086
kevin@gatech.edu (Kevin P. Kleinfelter) (09/25/90)
motcid!king@uunet.uu.net (Steven King) writes: >In article <12439@accuvax.nwu.edu> kaufman@Neon.Stanford.EDU (Marc T. >Kaufman) writes: >>You are not giving your PIN number to the merchant. The PIN is >>encrypted (mixed with your bank card number) in a ONE WAY algorithm by >>a chip that is in the PIN pad itself. The plaintext PIN never sees >>the light of day. >A one way algorithm? Pray, how does the bank decode it to verify you? >A gigantic lookup table? One way encryption is very common. You store the encrypted PIN on the card. Then when the user enters his PIN, it is encrypted using the same algorithm. If the two encrypted PINs match, the original PINs were the same. Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347 {emory,gatech}!nanovx!msa3b!kevin
Ed_Greenberg@fin.3mail.3com.com (09/26/90)
Jim Budler <jimb@silvlis.com> writes: >Last year I was one of the lucky people to receive a letter telling me >that my Versateller card was being shut down, and that I would receive >a new one in a few days. Concurrently my HomeBanking stopped also. >This shutdown occurred because some people at one of the system >providers broke their trust and obtained a significant block of >records containing names, ATM numbers and PINs. By system providers I >mean the companies like Plus System, or Star, who connect to the John Higdon's gonna love this one... The Bank of America customer group that had their Versatel cards invalidated were that subset that had used an ATM in Safeway Supermarket. Safeway ATM's are provided by an organization called GTEL, a service of -- you guessed it -- GTE! The scope of the breach was not known, but everybody who had a GTEL transaction in a particular time period was uncerimoniously dumped from the Versatel system and then sent the mailings that Jim Budler described. Since Versatel numbers are used to log into Homebanking, that service was lost as well, even though Homebanking passcodes are not the same as the Versatel PIN. It was inconvenient, to say the least, although no money was ever stolen using the purloined information, and _the_bank_says_ that the perps were apprehended. edg
martin@bellcore.bellcore.com (Martin Harriss (ACP)) (09/27/90)
I thought that Digest readers may be interested in the following "hard evidence" about banks and ATM PINS. About six months ago I opened a new account at a nearby bank. I also requested an ATM card to go with the new account. The ATM card arrived a few days later and with it was a note saying I could stop by the bank to select a PIN and have the card activated. So I went to the bank, and they got out this machine, punched a PIN in while the bank employee wasn't looking, then she punched my account number in and then ran my card through the machine. Presto - a working ATM card. Now I, like many others, had always assumed that the machine encrypted some combination of the PIN and the account number and stored that on the card. I don't remember seeing any external connection on this machine, such as a data link to the bank's computer, but at the time I probably wasn't looking for one. As I remember, the card worked immediately - I went straight to the ATM after activation to check it out. In other words, I believed all the information needed to use the card was encoded on the card itself, and needed no information about the PIN at the central computer. I thought. Now it so happens that this bank was acquired by another bank, and with the takeover they sent me a new card. Fine, I thought; I really don't care who's logo is on the card as long as it works. With the new card was a note telling me that a new PIN would be sent to me in a few days. (It seems to be quite common that banks select a PIN for you and mail it in those envelopes with the carbon on the inside, so you can't see the PIN until you open it.) Well, I was a little upset about this because I rather liked the PIN that I had - I had been using it at this and another bank for some years; in an odd sort of way it was, in fact, telecom related. Anyway, my new PIN arrived yesterday. You guessed it - it was the same as the old one. I attribute this to one of three scenarios: 1. Coincidence. (not likely.) 2. They decoded my PIN. (also, I suspect, unlikely.) 3. They knew my PIN all along. I strongly suspect number 3. When I opened the envelope I was somewhat surprised, even shocked, that they knew it, but know it they do. Comments, anyone? Martin Harriss martin@cellar.bae.bellcore.com
mpd@anomaly.sbs.com (Michael P. Deignan) (09/27/90)
motcid!king@uunet.uu.net (Steven King) writes: >A one way algorithm? Pray, how does the bank decode it to verify you? >A gigantic lookup table? They don't decode it, they encode the PIN you provide and then compare the encrypted value of the PIN you entered against the encrypted PIN on the magstripe. Michael P. Deignan, President -- Small Business Systems, Inc. Domain: mpd@anomaly.sbs.com -- Box 17220, Esmond, RI 02917 UUCP: ...uunet!rayssd!anomaly!mpd -- Telebit: +1 401 455 0347 XENIX Archives: login: xxcp, password: xenix Index: ~/SOFTLIST
af@sei.ucl.ac.be (Alain FONTAINE (Postmaster - NAD)) (09/28/90)
A recent Digest article noted: >One way encryption is very common. You store the encrypted PIN on the >card. Then when the user enters his PIN, it is encrypted using the >same algorithm. If the two encrypted PINs match, the original PINs >were the same. Homework : with four digits PIN'S, how many milliseconds of Sparc time does one need to make an exhaustive search ? AF