Security theatre at Allied Irish Banks

In summary

A person of malicious intent could easily gain access to hundreds, possibly thousands, of accounts as well as completely overwhelm the branch network by locking an estimated several 100,000s of people out of their online banking.

Both AIB and the Irish Financial Services Ombudsman have refused to respond meaningfully to multiple communications each in which these concerns were raised privately.

AIB's online login protocol

An 8-decimal-digit registration number

A 5-decimal-digit personal access code

The web (though never the mobile) portal used to the have a third step in which a third semi-secret 4-decimal-digit code was also requested but this step was removed several months ago.

The dangers of AIB's online banking portal

Given the large number (estimated at several 100,000s) of extant accounts with such registration numbers, the following procedure can be expected to gain access to many hundreds of accounts (possibly thousands) at a rate of perhaps one account per hour without parallelism:

Pick a random birthdate DDMMYY for somebody aged 18 – 60 (say). Pick a random number NN between 0 and 99. Attempt to login using registration number DDMMYYNN. Pick three random digits between 0 and 9 and submit these for the requested digits of the personal access code. Repeat step 4 until either the account is locked or access is gained. Go to step 1.

As mentioned, in the event that somebody carried out the procedure above, a side-effect would be that within a few days an estimated hundreds of thousands of account holders would have to visit their branches to have their account unlocked. Such an event would completely overwhelm the branch network and even after the accounts were unlocked, the event could be repeated.

It is possible that the bank might start to block connections from IP addresses that appear to be performing an attack such as that described above but such a pseudo-defense could be easily circumvented either by leveraging legal cloud-computing facilities or renting an illegal botnet.

Apparently it is possible to rent 1,000 hosts for about $25 per hour. As well as completely circumventing potential IP blocking, this would allow parallelism that would speed up the attack by a factor of 1,000, meaning that potentially:

accounts could be compromised at a rate of about one every two seconds.

Unless the bank changes their login protocol to something genuinely secure, the best they could hope would be to slow down such an attack by making their site less performant. Even so, by then presumably many accounts would have been breached and many thousands would have been locked, and the attack would continue, and continue to succeed just a bit more slowly. Other partial defenses exist but nothing that is likely to stop a competent attacker.

Correspondence with AIB and Irish Financial Services Ombudsman

The sequence of communciations was:

Email to AIB. No response.

No response. Physical letter to AIB. Response failed to engage with substance; largely platitudes such as: "we take security seriously at AIB and aim to protect our customers against the threats associated with Internet fraud" .

Response failed to engage with substance; largely platitudes such as: . Follow-up email to AIB. Response prevaricated in similar manner: "AIB has a multi layered approach including many processed[sic] and systems" .

Response prevaricated in similar manner: . Email to FSO . Response asserted: "such expertise is beyond the remit of this Office" .

. Response asserted: . Follow-up email to FSO. Response suggested: "you may wish to approach the Data Protection Commissioner".

Perhaps follow-up with the Data Protection Commissioner's office in Portarlington might result in progress:

but I am not optimistic.

It is interesting to bear in mind Ross Anderson's quote (from this paper):

One of the observations that sparked interest in information security economics came from banking. In the USA, banks are generally liable for the costs of card fraud; when a customer disputes a transaction, the bank must either show she is trying to cheat it, or refund her money. In the UK, the banks had a much easier ride: they generally got away with claiming that their systems were ‘secure’, and telling customers who complained that they must be mistaken or lying. “Lucky bankers,” one might think; yet UK banks spent more on security and suffered more fraud. This may have been what economists call a moral-hazard effect: UK bank staff knew that customer complaints would not be taken seriously, so they became lazy and careless, leading to an epidemic of fraud.

Just how easy is it to execute such an attack?

The following repository on GitHub, quoted below, demonstrates that the basic mechanism can be implemented in about 20 lines of python: