colonel@sunybcs.UUCP (05/15/87)
> ... He put in a non-participating bank's card and the > machine cycled him through the whole validation sequence before > spitting out the card with the message "invalid card" or something like > that. So it looks like the ATM makes up a whole package of info before > firing it off to the mainframe. I can just imagine the Cobol code, yuk! It's a standard security practice--good policy. Under other conditions, though, it can be silly. Example from my wife: 1. Insert card. 2. Type i.d. number, with an error. 3. Select transaction. 4. Transaction fails--wrong i.d. number. 5. Go to 3 (!). I won't embarrass her by telling how long it took her to get out of the loop, but you get the idea. == "We Spies, or Us Spies - for we call ourselves both - ..." --S. Leacock -- Col. G. L. Sicherman UU: ...{rocksvax|decvax}!sunybcs!colonel CS: colonel@buffalo-cs BI: colonel@sunybcs, csdsiche@ubvms
eugene@pioneer.UUCP (05/20/87)
During the mid-1970s, I had a job designing thin film circuitry for
Information Magnetics in Goleta (Santa Barbara). About this time I
picked up my student VISA card. We were designed two development
systems: a 50,000 BPI tape drive and the first mag stripe readers.
We were given fake bank cards to run thru the readers (210 BPI), but
one day I was sitting there, and I had this card of mine, and I ran it
thru, I could read it. No the PIN is not kept on the card (obvious
security problems). At the time
only the account numbers were placed on cards. The PIN is determined by
the account numbers (or some other algorithm the manufacturer decides).
From the Rock of Ages Home for Retired Hackers:
--eugene miya
NASA Ames Research Center
eugene@ames-aurora.ARPA
"You trust the `reply' command with all those different mailers out there?"
"Send mail, avoid follow-ups. If enough, I'll summarize."
{hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene