andersa@kuling.UUCP (05/12/87)
In article <1060@aecom.YU.EDU> mkaplan@aecom.YU.EDU (Marc Kaplan) writes: > BTW, I assume that the ATMs will temporarily invalidate a card if >a few hundred bad attempts are made to remove money. At least, thats how >I would do it. If you make three (or maybe four) failing attempts in a row with the same card at a Swedish ATM, the machine will swallow the card and physically deface it (>burp!<), and you'll have to contact your bank to get a new one. -- Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden Phone: +46 18 183170 UUCP: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)
mkaplan@aecom.YU.EDU (Marc Kaplan) (05/18/87)
In article <294@kuling.UUCP>, andersa@kuling.UUCP (Anders Andersson) writes: > In article <1060@aecom.YU.EDU> mkaplan@aecom.YU.EDU (Marc Kaplan) writes: > > BTW, I assume that the ATMs will temporarily invalidate a card if > >a few hundred bad attempts are made to remove money. At least, thats how > >I would do it. > > If you make three (or maybe four) failing attempts in a row with the same > card at a Swedish ATM, the machine will swallow the card and physically > deface it (>burp!<), and you'll have to contact your bank to get a new one. While I admit a few hundred is too much, three or four is too little. Last week I made two mistakes before getting it right. With this method, if I came back the next morning and made *one* mistake, my card is history. For a 'bad guy', on the other hand, four attempts are not likely to net him the number. Four thousand is more like it. ...aecom!mkaplan Eric Safern
howellg@idec.UUCP (05/20/87)
In article <1071@aecom.YU.EDU> mkaplan@aecom.YU.EDU (Marc Kaplan) writes: >In article <294@kuling.UUCP>, andersa@kuling.UUCP (Anders Andersson) writes: >> In article <1060@aecom.YU.EDU> mkaplan@aecom.YU.EDU (Marc Kaplan) writes: >> > BTW, I assume that the ATMs will temporarily invalidate a card if >> >> If you make three (or maybe four) failing attempts in a row with the same > > While I admit a few hundred is too much, three or four is too little. In the UK it needs 3 successive bad attempts for the card to be invalidated. If you make 2 then get it right on the third you are OK. Usually the ATM card is also a cheque guarantee card so you do get the card back but the MS is erased and the card can only be used to guarantee cheques. Gareth.
andersa@kuling.UUCP (Anders Andersson) (05/22/87)
In article <1071@aecom.YU.EDU> mkaplan@aecom.YU.EDU (Marc Kaplan) writes: >In article <294@kuling.UUCP>, andersa@kuling.UUCP (Anders Andersson) writes: >> If you make three (or maybe four) failing attempts in a row with the same >> card at a Swedish ATM, the machine will swallow the card and physically >> deface it (>burp!<), and you'll have to contact your bank to get a new one. > > While I admit a few hundred is too much, three or four is too little. >Last week I made two mistakes before getting it right. With this method, if >I came back the next morning and made *one* mistake, my card is history. For >a 'bad guy', on the other hand, four attempts are not likely to net him the >number. Four thousand is more like it. Note, in a *row*. I believe all attempts has to be done during the same session at the ATM, and even if it kept the counter "alive" for your particular card over the night (which I don't think it does), your single intermediary successful attempt should be enough to reset it. If I were to make two failing attempts in a row I would probably step aside and let next customer do his business while my counter was reset, just to make sure, or I could take a walk to another ATM (it could be that the first just had a bad keypad). If that one goofed my card at first try, I would probably complain at the bank about stupid and user-hostile algorithms. The above scheme will at least cause some considerable delay for the impostor trying to find the code either randomly or systematically. He would have to step back, waiting for the ATM session to timeout, every two or three attempts. Trying 4,000 numbers would probably take him day and night (preferrably night) for a couple of weeks. This would give the owner of the card time to report it lost, or at least the computer might be able to catch the attention of some manager during working hours. There could be other limits implemented as well, like the one you first suggested, but I haven't heard about them. After all, security is relative. -- Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden Phone: +46 18 183170 UUCP: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)
shibumi@well.UUCP (Kenton Abbott Hoover) (05/24/87)
The determination on invalidation is done at the host. If the programmer wants to invalidate the card on three attempts, well, then the programmer has to put a flag on the data record for the card. An example: Bank Of America (who I used to work 4) simply sends a report to the branch where your account is and the branch personel decide whether to flag your card, or just call you and ask what the h**l is going on. Trivia: The Diabold and IBM ATMs (diabolds have CRTs with 4 unmarked buttons, IBMs say IBM on them, if not they have the cash sort of flop out of a slot and have an open/closed sign on them) are ...wait for it... 3270 devices! They] actually have PF keys and the whole nine yards built-in. Usual chain of activity in an ATM: 1) The interaction with the user, screens, etc. is done by some sort of controller, a Series/1-type (read: VERY STUPID) machine which controls a whole set of ATMs. The controller normally resides at some central location and communicates with the ATMs over leased lines. 2) When you do a transaction, the controller tries to queue up a set of transactions from its other ATMs. It will either succeed or timeout. In either case, the transactions are communicated to a 37X5 and from there to a mainframe which runs a batch job to do the transaction. 3) Most banks cannot update the account base in real-time, so the ATM processor (the mainframe doing the batch run, not the ATM itself) works from a database containing last nights data corrected with todays transactions. The transaction you actually do is simply made a memo posting and is entered into the actual accounts system as if it were a teller withdrawl/deposit with a note saying it was from an ATM. MORE TRIVIA: The PIN is not a timing issue (in most systems). Its just that the whole transaction is usually sent to the mainframe, and that is slow going. EVEN MORE TRIVIA: Have you ever been cheated out of money by an ATM? If you were it was most likely an IBM. Go to your branch and report it, and they (after you fill out the usual form) will credit your account. Save the ATM receipt, as they normally ask for it. The IBM machines steal like theives, and normally (like in socks in dryers) the money has simply vanished. Diabold ATMs miscount once in a blue moon, AND if you do a transaction that asks for more money than is the the ATM (they dont keep track in most cases), it will give you what it has and debit your account for only that much. STILL MORE TRIVIA: Dont deposit cash unless it is to a Diabold ATM. Diabold ATMs check the deposit envelope to see if there is anything in it. IBMs dont. The deposit box is opened by two branch officers, and they (normally) wont swipe cash from a Diabold, since it would be hard to claim an empty envelope. However, an IBM machine... (someone should really write a book on this subject)