What are the shortcomings of the following bank transaction authentication scheme?

Question

Here in Germany, authentication of transactions in online banking (beyond the basic log-in password which is and has always been needed as well) has evolved from a list of one-time passwords which are distributed in advance on paper (so-called "TAN" codes, or transaction authentication numbers) to the use of one-time passwords sent on demand to a mobile phone or similar device, in a message which also contains details of the transfer to authenticate the message. I have been wondering whether it is possible to achieve a similar level of security while still using the older method of distributing a paper list in advance, and in fact came up with a scheme which seems workable to me. Since I am aware of the general quality of security schemes devised by amateurs (and I am an amateur) I would be interested to hear comment on the shortcomings of my scheme from readers of this site.

The basic idea of the scheme is that a paper list of numbered entries would be distributed to the customer in advance by the bank. Instead of containing simple passwords though, the list would contain simple numeric tasks, such as:

1. Enter the sum of figure one and figure four of the account number, followed by the number eight, followed by sixty minus figure three of the bank sort code.

2. Enter figure three of the account number, followed by figure two and figure seven of the bank sort code, followed by figure two and figure one of the amount to be transfered (ignoring cents).

3. ...

When the customer has to authenticate a transaction, they will be given the number of one of the tasks and asked to enter the solution, using the transaction details. It seems to me that this scheme fulfils the requirements that the one-time password generation should be initiated by the bank at the time of the transaction, that it is tied to the transaction, that it is non-trivial to work back from the password to the method used to generated and that it involves a second, separated communication channel. In addition I would hope that it would be manageable for customers (except that it might need a large-ish piece of paper to hold the tasks!), and would actually encourage them to check the transaction details.

I realise that there would need to be requirements on the tasks to keep them usable but still secure, and that they would have to be expressible and parametrisable in a way that the bank's computers can deal with (though new types could be introduced at any time). Beyond that I would be interested to hear what major holes there are in this scheme that I have missed.

Answer 1

Some thoughts in no particular order.

1. It requires good math, reading, and reasoning skills; although it would be great if everyone could perform these tasks we can't (nor should we) expect that everyone with a bank account will be able to do this. This will result in false failed logins, decreased usage, and increased support calls.
2. It requires standardization about how to write the questions. Ideally these questions should be able to be algorithmically generated, not written by a human, and verifiably correct and free of ambiguity.

3. The scheme requires the ability to read the language the questions are written in. A scheme that just has a token card or passcode list does not have this limitation. Bank accounts are mostly numerals which are cross-linguistic.

4. Given the required standardization above, now we must be able to verify that it is indeed not trivial to work backward from password to the generating algorithm. It's not clear from your description that this is provably true.

5. The resulting number has to be both long enough to provide sufficient entropy and short enough to make the calculation step feasible. E.g. a 10 digit number might have sufficient entropy depending on the calculation scheme and the rest of the security; but 10 digits might be too long to expect someone to follow all your steps.

6. What problem are you trying to address that you feel current schemes fall short at?

Answer 2

This has two shortcoming, one of which is likely devastating (in my view).

1. The usability sucks. A significant fraction of customers are going to have a hard time using this. The error rate is going to go way up. Some customers will just get unhappy with the bank, and that's not good for business. Others are going to call the phone support line for help, and that's terrible for business: I've heard estimates that suggest that it costs $20-40 per call to the help desk. Thus, if introducing your proposal increases help desk calls by 10%, that's a huge cost to your scheme, which renders it dead in the water. I think this is a showstopper.

2. It does not have any clear security benefit over alternative schemes, like sending details of the transaction and a confirmation code to the customer's cellphone.