How password recovery threatens online banking security

Even if the banks change their procedures to have the customer ringing up the bank (call centre who knows where) the customers are still vulnerable to either being connected to someone sinister in between or just plain overheard. The fraudster can easily ring the bank and use the same 'secrets' you used.

Some banks make it easier to have it go like this:

Target the person - lock them out of their account (best done trying to log in to their account using the wrong password via their own wifi), eavesdrop on their call to the bank to fix it (IMSI catch their call routing it through their own internet connection just to be mean and leave a confusinging 'audit trail'), and voila...wait until payday and clean them out.

As the supply of stolen account details and passwords currently exceeds demand, I'm not sure it is an immediate threat, but it is of note to the professional fraudster with a laptop and a spare $1500 who wants to do less to make more.

The banks are in a quandary without real risk assessment or reliable fault determination, until they find the probably simple solution. The honest customers shouldn't beand their solution is simple - they should switch banks if they aren't reimbursed - to one on the list with a better record of protecting their customer's money.

Perhaps publishing a comparison vulnerability list /customer reimbursement score is a way to educate consumers. It would be a book not a list.

Hi Dean,

I'm not sure how ``banks [changing] their procedures to have the customer ringing up the bank [...]" relates to this piece. In fact, it is a procedure change which I advise against in the full paper.

I agree that ``the banks are in a quandary" and some banks do indeed perform better than others. But, the option to ``switch banks if they aren't reimbursed" is unavailable to some customers, in particular, when large sums of money are concerned.

I believe that banks need to accept liability for financial losses arising from poorly designed systems and moreover, to make this possible, security researchers must publish such attacks so that courts can make informed decissions in legal cases. The industry regulators should also look to evaluate the systems available and levy fines where minimum standards have not been met.

Regards,

Ben

On your 'demo' (your website) it did seem incredibly Noddy to get a replacement password, but the last time I made an online payment via Natwest you needed the secure Card Reader to enter challenge/response data before a Payee could be set up.  I still don't like the idea of someone assuming my identity and accessing my account, but there are other safeguards too.  I also get emails when things change.

But possession has always been 9/10s of the law, so when you need them to admit deficiencies its always going to be an uphill battle.

Hi John,

As discussed in the report, the Royal Bank of Scotland Group (unlike the Lloyds Banking Group) have some protection mechanisms in place to prevent this kind of fraud. As you have observed ``the last time I made an online payment via Natwest you needed the secure Card Reader to enter challenge/response data before a Payee could be set up." This is true for setting up a payee; however, it is possible to make payments, without the secure card reader, to anyone you have paid in the past. Thus fraud is possible, but the scope of the fraud is limited. However, I speculate that bank employees can setup payees without such authentication; thus undetectable fraud by bank employees could be possible.

Regards,

Ben

A similar issue applies to resetting of 3D Secure (i.e. SecureCode/Verified by Visa) passwords for credit/debit purchases online. 

The password reset requirements are defined on a per-Issuer basis.  I have seen one Issuer who only requires your Date of Birth & credit limit to allow your password to be reset.  The first piece of information is publically available, and the second can easily be guessed (e.g. £5,000, £10,000 etc).

This obviously completely undermines the whole point of 3D Secure - to improve the security of online transactions.  It will be interesting to see how this develops, as cardholders have very few chargeback rights on 3D Secure transactions.  It is assumed that if 3D Secure is used, the cardholder was involved, or that they compromised their own security, and as such are responsible for the transaction.

John Clarke (www.worldnettps.com)

3DSecure and VbV work for me - because when I get those challenges I often give up and cancel out.  It seems to ask to fill in all the same data I already provided for the Credit Card payment part, a second time and kills the consumer experience dead.  Its yet another password to recall, and one which I don't use very often, so I hate to type in all my possible options guessing which one - who knows where that is cached. I won't use the same from one Bank to another and hence have many. 

IMHO, they should use the same authentication as logging in to your online banking - 3 random characters to sign the transaction, end of story.  That's a big (enough) combination and nothing new to remember.

Hi John Clarke,

Personally I have avoided such systems using the following technique when requested to sign-up: 1) complete the first page; 2) select cancel on the second page. (The details may vary slightly, but this is essential what I recall.) Maybe this is the method that John Dring was eluding to? I get an automated call from the fraud team every-so-often, but I tend to hang up.

In any case, Verified by Visa and MasterCard SecureCode should be considered broken (see also the research paper).


Regards,

Ben

2 comments I would offer :

Lloyds Bank : per the demographic data, there is no mechanism for any Bank to actually validate on-line the veracity of this data against 3rd Party Registers, so when I am prompted at Account Set up to provide any of this data such as Fathers First Name, Mothers First Name, my Place of Birth, Name of First School (or others such as Mothers Maiden Name, or Name of Dog [I've never owned a Dog]) - I actually provide totally fictitious values - just a character string (with hyphens) to minimise potential for a dictionary attack - but no-one could ever guess what the values are as held on file, and so I'm 'safe'.

RBS : as one of the other correspondents said, you can't set up a new Payee without using a Chip Card Reader; you also have to use the Chip Card Reader again if you want to change any of the details such as the Payee Bank Account. A recent enhancement was that the first time you then try to make a Payment to that Payee, you have to confirm the payment with the Chip Card Reader all over again. So its isn't enough to have opportunism to get hold of the details of the Card, you still need the Card itself.

Dear Keith,

Sorry for the delayed response, I somehow missed your comments. In response:

Comment one is a nice trick. But it does require maintaining a database of fictitious values, so it is probably impractical for the average user. (Given that you are knowledgeable about such techniques, I'll assume you have suitable controls on your database to ensure that it is 'safe'.)

Comment two highlights a new enhancement. I was unaware of this recent development; however, it doesn't seem to raise the bar that much, that is, the attack works for payees whom the customer has previously paid. So you still do not need the card in most cases.