Linking payments to the user: using authentication codes
Both article 4 and article 5 of the RTS uses the term “authentication codes” quite a lot. While it is not explicit in the regulation what an authentication code is, it is likely that most people will associate it with a TAN, a “Transaction Authentication Number”, which is a variant of a One Time PIN (OTP).
Transaction Authentication Number
A TAN is usually generated by a small dongle, that the user has to get a seemingly random number from to authenticate transactions. In practice a TAN is a simple indication of possession, as discussed in the 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, the knowledge.
The challenge from the PSD2 comes with all the other requirements 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 requirements on not just securely transferring an authentication code from a dongle to the bank, but to link it with both the identity and the amount. Clearly, 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 amount 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 which can listen to SMS messages and intercept these kinds of authentication codes probably numbers in the hundreds, if not thousands.
Authentication with Okay
How do we help protect against this type of threat?
With Okay we drop having the user enter a OTP, and instead use a unique security mechanism: With Okay, 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 generation on the server, to being executed, then 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 triggers a potential invalidation of the transaction or authentication.
Our goal for the Okay service is to create a software-only solution which 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.