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" (Sasse 2016). 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 (e.g. Krol 2016a) 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.
We will discuss the consequences of these aspects in more detail in answers to Questions 3, 4 and 6.
(Sasse 2016) M. Angela Sasse, Matthew Smith. The Security–Usability Tradeoff Myth, IEEE Security & Privacy, September/October 2016: IEEE.
(Krol 2016a) Kat Krol, Simon Parkin, M. Angela Sasse. Better the Devil You Know: A User Study of Two CAPTCHAs and a Possible Replacement Technology, USEC ’16, February 2016: Internet Society."
Articles 3, 4 and 5 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 Regulatory Technical Standards (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 (Murdoch 2016).
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 (Becker 2016).
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." (Schneier 2016). 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 Payment Services Directive 2 (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 so" (RS 2016).
On Article 3 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 (CESG 2016).
(Murdoch 2016) Steven J. Murdoch, Ingolf Becker, Ruba Abu-Salma, Ross Anderson, Nicholas Bohm, Alice Hutchings, M. Angela Sasse, Gianluca Stringhini. Are Payment Card Contracts Unfair? Financial Cryptography and Data Security, February 2016: Springer.
(Becker 2016) Ingolf Becker, Alice Hutchings, Ruba Abu-Salma, Ross Anderson, Nicholas Bohm, Steven J. Murdoch, M. Angela Sasse, Gianluca Stringhini. International Comparison of Bank Fraud Reimbursement: Customer Perceptions and Contractual Terms, Workshop on the Economics of Information Security, June 2016.
(Schneier 2016). Bruce Schneier. Security Design: Stop Trying to Fix the User, IEEE Security & Privacy, September/October 2016: IEEE.
(RS 2016). Progress and research in cybersecurity, Royal Society, 2016. (available from https://royalsociety.org/topics-policy/projects/cybersecurity-research/)
(CESG 2016) Password Guidance: Simplifying Your Approach, 2016. CESG (available from https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach)"
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 (Murdoch 2015).
As noted in our answer to Question 1, 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.
(Murdoch 2015). Steven J. Murdoch. What are the social costs of contactless fraud? Bentham's Gaze, September 2015 (available from https://www.benthamsgaze.org/2015/09/10/what-are-the-social-costs-of-contactless-fraud/)
Articles 16 (and similarly, Article 7) specify that SCA procedures and security measures be subject to audit by internal or external evaluators. As discussed in answers to previous questions, 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 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 (Krol 2016b).
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 (Murdoch 2012).
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 negligent. To protect customers, audit reports should be available to customers disputing transactions (Murdoch 2009), 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 59 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 they are working securely. Our research has developed principles that allow robust evidence to be produced from authentication systems (Murdoch 2014). 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 (Kerckhoffs 1883) and modern banking procedures (APACS 2004).
(Krol 2016b) Kat Krol, Jonathan M. Spring, Simon Parkin and M. Angela Sasse. Towards robust experimental design for user studies in security and privacy, Learning from Authoritative Security Experiment Results, May 2016: IEEE
(Murdoch 2012) Steven J. Murdoch, Mike Bond, Ross Anderson. How Certification Systems Fail: Lessons from the Ware Report, IEEE Security & Privacy, November/December 2012: IEEE.
(Murdoch 2009) Steven J. Murdoch. Reliability of Chip & PIN evidence in banking disputes, Digital Evidence and Electronic Signature Law Review, 2009.
(Murdoch 2014) Steven J. Murdoch, Ross Anderson. Security Protocols and Evidence: Where Many Payment Systems Fail, Financial Cryptography and Data Security, March 2014: Springer.
(Kerckhoffs 1883) Auguste Kerckhoffs. La cryptographie militaire, Journal des sciences militaires, January 1883.
(APACS 2004) APACS PIN Administration Policy, January 2004."