A TAN is usually generated by a small dongle that provides the user with a seemingly random number to authenticate transactions. In practice, a TAN is a simple indication of possession, as discussed in our previous post. A TAN generating dongle is something that is really hard to copy, but by itself, it does not protect the user from fraud. When used together with a password, the requirement of two factors is met, as the password represents another type of factor (knowledge).

The challenge from PSD2 comes with all the other requirements, as listed in article 5:

“The authentication code generated is specific to the amount of the payment transaction and the payee […] corresponds to the original identity […] any change of the amount or the payee results in the invalidation [...] payment service providers shall adopt security measures which ensure the confidentiality, authenticity and integrity of each of the following:

(a)the amount of the transaction and the payee throughout all of the phases of the authentication;

(b) the information displayed to the payer throughout all of the phases of the authentication including the generation, transmission and use of the authentication code.”

This makes not just transferring an authentication code from a dongle to the bank securely a requirement, but also how to link it with both the identity and the amount. This puts greater requirements on the security mechanisms than what can be provided using just a simple dongle.

For decades there have been a large number of attacks on authentication codes. Originally social engineering was the most common approach, where someone would call from “your bank” and ask for your TAN code. In one case they would even send a bicycle messenger to your apartment to pick up the card for your “hacked account”.

Later it became common to use SMS messages for authentication codes, where the user had to re-enter an authentication code sent by SMS in a web browser. The number of mobile malware suites that can listen to SMS messages and intercept these kinds of authentication codes probably numbers in the hundreds, if not thousands.

With Okay, we drop having the user enter an OTP, and instead use a unique security mechanism. The transaction details and user identity are deeply embedded in unique obfuscated code blocks which are transferred just-in-time from the server.

The integrity and authenticity of the code blocks are monitored from when they are generated on the server, until they are being executed and viewed by the user, before the result is transferred back to the server-side. Any changes to either the code blocks or to what is viewed by the user trigger a potential invalidation of the transaction or authentication.

Our goal for the Okay service is to create a software-only solution that enables single-device security, with potential stronger security than you get with a dongle. The fundamental goal is to protect transactions not to simply be sure of the identity of the payer.