Within the European Union, since 2007, banks are regulated by the Payment Services Directive. This directive sets out which types of institutions can offer payment services, and what rules they must follow. Importantly for customers, these rules include in what circumstances a fraud victim is entitled to a refund. In 2015 the European Parliament adopted a substantial revision to the directive, the Payment Services Directive 2 (PSD2), and it will soon be implemented by EU member states. One of the major changes in PSD2 is the requirement for banks to implement Strong Customer Authentication (SCA) for transactions, more commonly known as two-factor authentication – authentication codes based on two or more elements selected from something only the user knows, something only the user possesses, and something the user is. Moreover, the authentication codes must be linked to the recipient and amount of the transaction, which the customer must be made aware of.
The PSD2 does not detail the requirements of Strong Customer Authentication, nor the permitted exemptions to this rule. Instead, these decisions are to be made by the European Banking Authority (EBA) through Regulatory Technical Standards (RTS). As part of the development of these technical standards the EBA opened an initial discussion, to which we submitted a response based on our research on the security usability of banking authentication. Based on the discussion, the EBA produced a consultation paper incorporating a set of draft technical standards. In our response to this consultation paper, included below, we detailed how research both on security usability and banking authentication more broadly should guide the assessment of Strong Customer Authentication. Specifically we point out that there is an incorrect assumption of an inherent tradeoff between security and usability, that for a system to be secure it must be usable, and that evaluation of Strong Customer Authentication systems should be independent, transparent, and follow principles developed from latest research.
False trade-off between security and usability
In the reasoning presented in the consultation paper there is an assumption that a trade-off must be made between security and usability, e.g. paragraph 6 “Finally, the objective of ensuring a high degree of security and safety would suggest that the [European Banking Authority’s] Technical Standards should be onerous in terms of authentication, whereas the objective of user-friendliness would suggest that the [Regulatory Technical Standards] should rather promote the competing aim of customer convenience, such as one-click payments.”
This security/usability trade-off is not inherent to Strong Customer Authentication (SCA), and in fact the opposite is more commonly true: in order for SCA to be secure it must also be usable “because if the security is usable, users will do the security tasks, rather than ignore or circumvent them”. Also, SCA that is usable will make it more likely that customers will detect fraud because they will not have to expend their limited attention on just performing the actions required to make the SCA work. A small subset (10–15%) of participants in some studies reasoned that the fact that a security mechanism required a lot of effort from them meant it was secure. But that is a misconception that must not be used as an excuse for effortful authentication procedures.
In addition, the concept of convenience/user-friendliness should not be conflated with usability. Designing a system to be convenient/user-friendly is in the interest of the Payment System Provider (PSP) because it will encourage usage and reduce support costs. However, just because a system is convenient does not mean that it is usable. To be usable SCA must allow customers to perform transactions while properly understanding the risks of doing so and being able to mitigate these risks. Convenience must not be used as an excuse for suppressing information and functionality from being made available to customers, which they legitimately should have access to, even if that might harm convenience and so reduce usage or increase support costs.
Security of authentication elements
Articles 3, 4 and 5 of the draft RTS deal with technical requirements related to individual authentication elements, which may affect security, but are not sufficient for security. The security of SCA is dependent on the interaction between components of the system including the authentication elements, the mechanisms for performing authentication, and the processes surrounding the authentication system. We agree that in order to facilitate innovation a “principle-based” approach is appropriate, but principles should focus on system-level properties rather than of individual elements.
In particular, a threat that is not addressed by the draft RTS is of customers not performing the authentication procedures as they were designed, because they are insufficiently usable and/or a criminal has deceived the customer into believing that the authentication procedures are different to those intended by the PSP. The RTS criteria should therefore require that SCA be usable, taking into account the context in which the SCA is used (e.g. where a customer deals with multiple PSPs, including some only infrequently), and be resistant to deception.
Our research has shown that requirements set by UK banks on knowledge customer authentication elements (specifically PINs) are confusing and not feasible to comply with, taking into account human memory capabilities and payments usage patterns. Customers must therefore develop coping mechanisms and we find that due to this poor usability, hazardous practices are common.
Customer awareness activities and liability
We note that the EBA does not plan to implement customer awareness as part of this RTS but may do so under a different scheme (paragraph 58). Our research has shown that most customers interpret the awareness material provided by banks incorrectly, or are not able to follow the proscribed behaviour. They are most certainly not aware that this means they may be held responsible in case of fraud.
Customer awareness activities must not allow a PSP that has implemented SCA with poor usability to shift liability to customers. “Usable security does not mean ‘getting people to do what we want.’ It means creating security that works, given (or despite) what people do.” Reliance on customer awareness should be minimised, but any material that is developed must be validated by research that demonstrates the guidance will result in significant security improvement without interfering with ordinary life.
Because the use of SCA implies the assignment of liability under the PSD2, the design of the RTS governing SCA should be guided by assigning liability to the party in a position to improve system security: “To improve security, responsibilities should be assigned to parties that could effectively discharge them, and could afford to do so. Consumers typically have the least capacity to mitigate risks, while service providers can improve security through system design and implementation, and by taking careful account of real-world use of their products. In most cases this means liability regimes should protect consumers, and prevent system operators from shifting liability to individuals where it is not reasonable to do”.
On Article 3 of the draft RTS specifically, security features of knowledge elements includes “length, complexity, expiration time…”. Research has demonstrated that length/complexity requirements and password expiration are counter-productive as security criteria. Instead, technical defences such as account-lockout, throttling and protective monitoring should be adopted to allow simpler passwords to be used securely.
Exemptions to Strong Customer Authentication
We agree that there should be explicit listing of permitted exemptions for SCA, rather than permitting PSPs to make a risk-based decision. Even if customers will be refunded for unauthorised transactions, there are further economic and social externalities that result from fraud and it is in the interest of society to reduce fraud, over and above the need to assign liability to the party in the position to prevent fraud.
As noted above, not only is there no contradiction between security and usability, but security requires usability. Therefore, it is desirable for SCA to be used for as many transactions as possible. This would add to consistency, which is a powerful usability design principle, resulting in the reinforcement of the practice of performing a transaction and so increasing the likelihood of the customer detecting a fraudulent transaction.
Auditing Strong Customer Authentication procedures
Articles 16 (and similarly, Article 7) of the draft RTS specify that SCA procedures and security measures be subject to audit by internal or external evaluators. As discussed above, this evaluation should include the security usability of the system as a core part of the security criteria. The evaluation should consider the system in realistic contexts, taking into account that the customer may perform SCA infrequently and have relationships with multiple PSPs (therefore subject to forgetting and interference effects). For example, an SCA should only be considered that a customer is “made aware” of information under Article 2 of the draft RTS if every customer is able to reliably identify whether a transaction is fraudulent and what action should be taken in response, in a normal usage context and while subject to attempts by criminals to deceive the customer. Procedures for user studies to assess such security should be informed by research on how to perform robust experiments.
Because the use of a compliant SCA allows the PSP to shift liability to a customer, it is concerning that internal audits are considered acceptable. The use of internal audits creates a clear externality: a poorly performed or inexpert audit by the PSP will result in liability for fraud being shifted to customers. A robust certification scheme for SCA should require rigorous external audits by experts, with strong procedures in place to avoid conflicts of interest.
Furthermore, the draft RTS only requires that the audit report to be made available to “competent authorities”. In the case of disputes, whether through a court or the PSD2 alternative dispute resolution procedures, this decision puts the customer in a weak situation by not being able to effectively defend themselves against an PSP’s accusation that the use of SCA implies that the customer either acted fraudulently or with gross negligence. To protect customers, audit reports should be available to customers disputing transactions, and the evaluation performed by auditors should be sufficiently detailed to allow an expert witness to repeat the analysis.
To allow the PSP to discharge their responsibility under Article 72 of the PSD2, to demonstrate that SCA was performed, the RTS should require that SCA not only perform secure authentication, but also produce evidence that authentication systems are working securely. Our research has developed principles that allow robust evidence to be produced from authentication systems. SCA should also be designed such they will remain secure even if information on how they function is disclosed, including as part of evidence or in an audit report. This requirement is compatible both with established security principles and modern banking procedures.
is there any negative impact if we use the system?