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.

  • 2
    It sounds fun to me, if a little like hard work for your average customer. The main downside though is that this is an already solved problem - tokens and card-readers, SMS messages, callbacks etc exist already and the implementation procedures are well understood.
    – Rory Alsop
    Mar 21, 2012 at 13:53

2 Answers 2


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?
  • 3
    +1, and I would add to that a BIG hit on usability. And we all know of AviD's Maxim of Usability: "Security at the expense of usability, comes at the expense of security."
    – AviD
    Mar 22, 2012 at 9:59
  • 1
    Thanks for your answer. I will try to address some of your points in no particular order (as there will be some overlap). 1. Current schemes also have shortcomings, including the requirement to own a mobile phone (mTAN), a known attack (mTAN) unsuitability for epileptics (opticalTAN) and expense, including regular redeployment of token cards. In addition they also require a certain technical literacy, and I think that some people might cope better with my scheme than with the current ones (and vice-versa of course). So as an all-out replacement: no. As an additional option - (very) maybe.
    – michaeljt
    Mar 23, 2012 at 5:46
  • 1
    To your point 2. - that was intended to be clear in the original formulation. Point 3. - I have some sympathy here, having once lived in a country with nearly 50% illiteracy. Can be improved on by supporting a number of languages (see your point 2. as well). Point 5. - TANs here are currently six digits, which should be manageable.
    – michaeljt
    Mar 23, 2012 at 5:55
  • 1
    Point 4. - well, this is the elephant, so I left it until last. If it can be solved then I would imagine that the freedom one has in varying the algorithm - both using different variants for different positions on a single list, without having to explicitly state which one one was used, and the freedom to introduce new algorithms with new lists - would play a part. The question would be whether algorithms can be found which are secure enough while still being usable enough. (And that is not something I can hope to answer just now of course!)
    – michaeljt
    Mar 23, 2012 at 5:59

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.

  • Good point about the support costs, though I also wonder what they are for mTAN and opticalTAN (especially the second, which I could imagine also giving non-technical customers a hard time).
    – michaeljt
    Mar 26, 2012 at 19:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .