UK ATM System Could Have Ruined Economy

seanyboy writes "The Register is running the story of how the UK banking system could have collapsed in the early 1990s, how easy it was at the time to withdraw against other people's accounts and the worrying case of a Bank's rogue IT Department." From the article: "What quickly became clear was that the law needed a system to provide proof that events had happened so that legal cases could be made. You might say that 'the computer debited the account', but to a barrister (and more importantly, a judge) that's not enough. Did the computer do it at random? In that case it's like a tree branch falling - an accident. Or did a person program it to do so? In which case the person must be able to testify about the precise circumstances when a debit could happen. Sounds daft, but the law rests on proving each step of an argument irrefutably."

Comments

Not just 1990's bank machines

[Anonymous Coward]

Avoid any online payment systems based on "epay". No transaction begin/commit statements, no journal, few authorization checks, cleartext password table, one big table syndrome. It's clear the authors had little knowlege of accounting or database design beyond LAMP for blog/forum sites.

Re:How much should you believe this?

[geckofiend]

You're reading it like he was talking about one group of people. He was referring to several problems/crimes performed by many different groups. Bank insiders put the PIN hack in, common street criminals shoulder surfed etc.

Why Cryptosystems Fail

[sharp-bang]

If you liked this article and are interested in some technical background, you might also like Ross Anderson's essay: Why Cryptosystems Fail, which discusses some of the poor engineering that contributed to this situation.

Re:How much should you believe this?

[MyGirlFriendsBroken]

First, only 3 PINs being generated by the card issuing system. I can see this is possible if you hack the application code itself but the HSMs (hardware security modules) that actually do the cryptographic operations wouldn't do this using Visa, IBM or Diebold PIN offset generation calls. It's possible, but it would be an insider job in one bank NOT the whole banking system.

This is what the article indicates, it was the people working with the PIN production system rigged it to do this

Second, the description of the scam is that one PIN offset on track 2 can be used with multiple account numbers. Again, all the standard PIN methods explicitly prevent this - the account number (PAN) is part of the input data to the PIN verification call.

The account number did not feature in this case, thus simply changing the account number on the card was sufficent, the original PIN would still work

Third, the description has the crook shoulder surfing for PINs. Why does he need to do this if any known PIN can be used with any account?

This is what the guy used to do originally, then he discovered the account number rewriting trick

The article is not that well writen, it took me 2 1/2 reads of the article to actually establish all of the above. what I want to know is, who is "rogue Bank" and are they the same one I bank with

It's slightly different in the States

[Anonymous Coward]

Here, most banks have "bounce protection," which basically means that the ATM will happily let you withdraw $50 when you only have $49.99 in the bank, and then charge you a $30-$50 "fee" for the privelege.

Personally, I'd rather have the ATM tell me to bugger off.

OK, Somewhat less flame-y

[temojen]

For a bank, you have 3 main tables:

accounts describes all the accounts

create table accounts (
id serial not null primary key,
owner int references customer,
type int references accounttype,
ballance numeric(18,2)
);

JournalEntries shows the date, time, type, who, etc of each transaction

create table JournalEntries (
id serial not null primary key,
when timestamp not null default now(),
ttype int not null references transactiontypes,
whodid int not null references users
);
revoke update, delete from public;

JournalLines shows part of each transaction

create table JournalLines (
trans int references JournalEntries,
acct int references accounts,
change numeric(18,2),
primary key (trans,acct)
);
revoke update, delete from public;

After All transactions, the sum of JournalLines(change) must be zero, and all account ballances must equal the sum of the changes to that account. No changing or deleting of past transactions is allowed, only compensating transactions if an error is found.

An ATM withdrawl would be:

subtract from owners account
add to withdrawls

subtract from cash in machine X
add to withdrawls from machine X

This would normally be done by a stored procedure that also checks the PIN, etc. The DB user that machines, etc connect as would only have access to run stored procedures, not change the journal directly.

Re:What happened to me...

[ldspartan]

I believe you experienced the failsafe: ATM keeps card, no one gives it back. Similiar thing happens if you enter your PIN incorrectly x times at some ATMs. The ATM keeps the card, and unless the bank has proof of signature for you, they then shred it after they empty the ATM. The bank reissues your card.

What if the electricity had gone out for much longer? And, upon boot, the machine cleared the cardreader by spitting your ATM card into the street? That'd be worse, methinks.

--
Phil

That's not how the Nat West Cheat worked

[TAZ6416]

Used it myself a few times when I worked in London in the 80's.

First of all, it would only work with a Nat West Deposit Account, if you did it with a current account you were screwed as you would get charged.

Lets say you had a big weekend coming up, you had £100 in your pocket and £100 in the bank. You would go to the bank and deposit £100 in the branch so you had £200 in Nat West. This would flag up on the ATM as you had £200 to withdraw, so you could go and withdraw £200 from the ATM, but for some reason (I assume the ATM's did a processing job every couple of days to a mainframe) the transaction didn't register on the branches computers for about 3 days and you could walk into the same branch 5 minutes later and withdraw another £200, so you had £400 now for the weekend. 3 days later however, the bank will have caught up and you are overdrawn by £200.

OK, now you are thinking about "hey you are going to get big charges for that", but the beauty was that it was meant to be impossible for you to go overdrawn on a deposit account so there was no charging procedures in place (the old computers are infallible thing that was mentioned in the original article), I did get called in to the bank once or twice to explain my actions but I just shrugged my shoulders and said "Well, I thought I had that much money in my account, sorry I buggered up, but why did you let me take that extra money out when I didn't have it, why didn't your computers stop me?" So I got away with it every time.

It was never a way to get free money, it was just a way to tide you over if you were a little short before your next pay day.

Jonathan

Oscar The Grouch Does America - http://www.mccormackj.fsnet.co.uk/oscarthegrouch/

Re:EFT vulnerability

[Anonymous Coward]

It is quite disturbing - the only security you have is to keep your account number (or at least the account/routing number pair) as private as you do your SSN. If anyone gets hold of this pair of numbers, you're done for (as your example shows).

Re:EFT vulnerability

[TykeClone]

Currently, assuming consumers look at their statements, the only losers will be banks. Reg E gives consumers a great number of rights for their money back if an unauthorized transaction is reported within 60 days of it showing up on a statement. But it is up to the consumer to look at their statements and to report bad transactions.

Online services are not banks (unless they are banks, but that's different). If I'm at some website and want to pay via "e-check", the company doesn't have incentive to validate the account before initiating the transaction. Validating accounts require at least 1 business day to complete and require the consumer to come back before finishing the e-check transaction.

I agree that something should be done - but I think that law enforcement should take small frauds seriously and that the punishment should be harsh. Large frauds are made up of a great number of small frauds.

My mom got her credit card number nicked a few years ago. The card is from the (small) bank I work at. We reported this to law enforcement. Their answer is "that the credit card companies are the ones who are hurt, so it's no big deal." Total fraud was small, but when law enforcement has that attitude there is no chance that anyone would get caught and ultimately punished.

Re:U.S. Banks

[lgw]

Using demand drafts, someone could take money from your account without your written authorization. Here's a nice description of the problem: http://www.ftc.gov/speeches/other/ddraft.htm

However, this info is 10 years old. Does anyone know what's happened to banking law in the meantime?

Re:Yeah, but which bank was it?

[DemonSlayer]

using binoculars are too low tech.
Some criminals are using card readers and hidden cameras.

http://www.snopes.com/crime/warnings/atmcamera.asp

http://bizpartner.com.my/article/23

In Malaysia, a gang even created a fake ATM machine that "collected" the users cards and pin numbers.

By the time the user get the new ATM card and the bank statement. Thousands of dollars would have disappear from their account.