Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Hardware-based credential or device
Software-based credential
Historically, corporations and government entities had a small number of users who required strong authentication and when they looked for a solution the most popular options were hardware-based two-factor technologies (e.g., one-time password (OTP) tokens; smartcards; USB drives; etc.). Each of these items represented something that the user had along with something they knew (their password or PIN). These technologies are still used in many organizations; however, there are several inherent problems with these types of credentials, especially when considering to deploy them to consumers and citizens:
1. Convenience – they are cumbersome to handle and use by end users. These technologies cause a change in user experience, which can be frustrating and inconvenient, and may result in poor adoption.
2. Cost – these technologies are expensive to purchase, configure, and distribute. In addition, the tokens must be replaced frequently when the batteries run out, or if they are lost, stolen, or broken. Finally, using hardware-based credentials can also result in significantly higher operational costs due to frustrated users calling the service desk to troubleshoot authentication issues.
3. Security – new forms of attacks, such as man-in-the-middle, can effectively negate the advantage of these types of credentials by capturing the OTP after it was typed into the browser. In addition, the RSA breach also showed how easily the OTP seed values can be stolen by determined cyber criminals.
Fortunately, the development of software-based tokens dealt with many of the limitations of hardware-based technologies while still providing two-factor security. Initial software tokens were just a file that resided on the user’s computer and the combination of the password (something you know) and the software token (something you have) represented the two factors. There were some security concerns with this method because if a hacker got a hold of that file on the user’s device they could initiate a brute force attack and derive the password, and if the hacker could get the password and the software file they could use that same combination from another device to gain access. So while software tokens did a great job eliminating many of the problems with hardware tokens (i.e., lower initial purchase price; quicker and less expensive distribution; simpler administration; automated self-service; and easier replacement process), they still had some limitations of their own (e.g., potential portability issue (transferability to another device) and exposure to dictionary/brute force attacks).
In summary, with regards to consumer payments the optimal approach to using a “possession” element is a software-based credential as it is more convenient to the end user and cost-effective. This credential must be transferable across multiple device, such as PC/laptop, mobile phone, tablet, etc., and it must also be capable of being embedded within a mobile app that is involved in payment or account activities covered by the EBA guidelines. In addition, the credential should be encrypted on the device in order to prevent dictionary/brute force attacks. Furthermore, it is highly suggested that intelligent risk-based analysis also be implemented with any form of two-factor credential to provide a layered, defense-in-depth security approach.
One final note, some may consider that a mobile device is, in and of itself, a possession element, and that by sending an OTP to the device is enough to satisfy a “second” factor. We do not agree. We believe that over time, a device could become trusted as a second factor through fingerprinting and history of usage by the user – for example, Mary has authenticate from the same device for ten (10) times in a row; therefore, when someone presents Mary’s login credentials from this device we have a higher confidence that it is Mary, especially if all other contextual factors also are within Mary’s normal historic usage patterns. However, because devices can be easily stolen or lost, we do not feel that they should automatically be given “second factor” status.
User behavior is a strong indicator of an individual’s identity. Intelligent, contextual authentication can detect and protect against high-risk login attempts or other sensitive actions (e.g., funds transfers, payments, etc.) by analyzing a wide set of factors, including user behavior, device characteristics, geolocation and velocity data, without requiring any direct input from the end user (this is very convenient to the end user). And when deemed too risky, the solution can automatically prompt the user to submit additional credentials or information to further prove their identity (e.g., biometrics, out-of-band OTP, etc.).
While the device fingerprinting, geolocation, and velocity checks are important in the overall risk analysis, it is the user behavior profiling that is the critical differentiator and most effective detector of many threats and fraud attacks. Not only must the attacker understand and mimic the true user’s behavior, they also must constrain themselves to performing activities that the user normally performs. In addition, it also provides the following benefits:
Applicable across many channels. User behavior profiling is already used by card issuers as part of Card Not Present (CNP) transactions to provide a frictionless user experience. It can also be equally applied to browser, mobile, and ATM channels. In addition, within a single enterprise, risk analysis results could be shared across all channels.
No training required. Most behavioral models can be deployed in production without collecting prior history, and they require no training for the end user; they work transparently in the background.
Quick time to value. Most models can begin yielding results on the second observation. Since User Behavior Profiling calculates normalcy, the assessment of even the second transaction is relevant.
Automatically adjusts over time. There is no ongoing customer analysis of good/bad transactions. As the user’s behavior changes, the model automatically learns the new patterns.
Intuitive user experience. Users are not surprised if they are required to (re)authenticate when they do something that may be deemed unusual and see this as good security practice.
Difficult to reverse engineer. The combination of multiple assessment dimensions makes it extremely difficult to reverse engineer because behavior is complex and accumulated over time.
We would recommend that risk analysis and user behavior profiling be incorporated and applied to user logins and used prior to conducting any high risk financial or payment transactions.
The issues raised with regards to dynamic linking are not very different from an online credit card payment, where the card issuer must authenticate and authorize a payment where the card is not present. To address the security of CNP transactions, card issuers created the 3D Secure protocol. In addition, they have also increasingly been using contextual risk analysis and user behavior profiling to create a more frictionless user experience.
For dynamic linking, you could say that these are User Not Present (UNP) transactions. The user has previously authorized an automatic payment to a specific third-party vendor, and perhaps strong authentication was applied in order for this to be setup these payments (e.g., within an online banking application), but thereafter these transactions are processed automatically on demand without any user interaction (i.e., UNP). The security of these transactions can be significantly improved by implementing the same risk technologies that are used with CNP transactions.
A risk-based authentication technology can be used to monitor any actor – human or non-human. All things that “act” establish a behavior. In the case of a payment request that is initiated by dynamic linking, there will be “usage patterns” – for example, the payment request will be probably be submitted from the same servers, the same geolocation, at the same interval rate, and probably within the same time period. Some of these may also be for the same or approximately same monetary value. These behaviors can be modeled and evaluated for each subsequent request. When a request conforms to its normal patterns, it can be allowed to continue without any interruption, but when it deviates from its normal behavior, the transaction can be halted and the end user can be contacted via email, text, voice, or push notification to authorize the transaction. This gives the end user the ability to validate that this request is legitimate and should be paid. The solution could also generate an alert to the appropriate department or group within the bank about the irregularity, so that if this is a new attack, the bank can look for other fraudulent payment requests from the same locations or devices.
NOTE: At present, many risk technologies that utilize user behavior profiling have built these models to accommodate humans. When these models are applied to services, such as those involved within dynamic linking, some new parameters may be needed, such as average Euro/Dollar value per request; maximum Euro/Dollar value allowed (on per customer basis); typical day range for a request (if request is scheduled for 15th of every month, what is allowable range to accommodate weekends); etc. These rules and/or model changes would not be significant, but may be necessary to minimize false positives.
Coverage – the eIDs will not cover all EU citizens, nor will it cover non-EU citizens who are engaging in payment service activities within the member states; therefore, this means that the enterprises would still need to issue their own credentials to cover any user who does not have an eID.
Complexity – if each enterprise needs to support multiple personalized security credentials, issued from different entities, then how much additional cost and complexity does this add to their PSD2 burden? In addition, does this additional cost and complexity create a barrier for entry for new payment service providers?
Adoption – if users are given the choice between using an eID vs. a credential issued by their payment service provider, which one will they choose? Many users may view using an eID as a means by the governments to track their financial transactions. If so, the adoption rate for using an eID would be low.
Flexibility – the enterprises can quickly adapt to emerging technologies, and when needed, could more rapidly adopt and deploy a new, more secure authentication credential. It might take the governments much longer to issue a new form of eID when, and if, it becomes obsolete or insecure.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
There are essentially two types of possession elements that can be used in the context of strong authentication: Hardware-based credential or device
Software-based credential
Historically, corporations and government entities had a small number of users who required strong authentication and when they looked for a solution the most popular options were hardware-based two-factor technologies (e.g., one-time password (OTP) tokens; smartcards; USB drives; etc.). Each of these items represented something that the user had along with something they knew (their password or PIN). These technologies are still used in many organizations; however, there are several inherent problems with these types of credentials, especially when considering to deploy them to consumers and citizens:
1. Convenience – they are cumbersome to handle and use by end users. These technologies cause a change in user experience, which can be frustrating and inconvenient, and may result in poor adoption.
2. Cost – these technologies are expensive to purchase, configure, and distribute. In addition, the tokens must be replaced frequently when the batteries run out, or if they are lost, stolen, or broken. Finally, using hardware-based credentials can also result in significantly higher operational costs due to frustrated users calling the service desk to troubleshoot authentication issues.
3. Security – new forms of attacks, such as man-in-the-middle, can effectively negate the advantage of these types of credentials by capturing the OTP after it was typed into the browser. In addition, the RSA breach also showed how easily the OTP seed values can be stolen by determined cyber criminals.
Fortunately, the development of software-based tokens dealt with many of the limitations of hardware-based technologies while still providing two-factor security. Initial software tokens were just a file that resided on the user’s computer and the combination of the password (something you know) and the software token (something you have) represented the two factors. There were some security concerns with this method because if a hacker got a hold of that file on the user’s device they could initiate a brute force attack and derive the password, and if the hacker could get the password and the software file they could use that same combination from another device to gain access. So while software tokens did a great job eliminating many of the problems with hardware tokens (i.e., lower initial purchase price; quicker and less expensive distribution; simpler administration; automated self-service; and easier replacement process), they still had some limitations of their own (e.g., potential portability issue (transferability to another device) and exposure to dictionary/brute force attacks).
In summary, with regards to consumer payments the optimal approach to using a “possession” element is a software-based credential as it is more convenient to the end user and cost-effective. This credential must be transferable across multiple device, such as PC/laptop, mobile phone, tablet, etc., and it must also be capable of being embedded within a mobile app that is involved in payment or account activities covered by the EBA guidelines. In addition, the credential should be encrypted on the device in order to prevent dictionary/brute force attacks. Furthermore, it is highly suggested that intelligent risk-based analysis also be implemented with any form of two-factor credential to provide a layered, defense-in-depth security approach.
One final note, some may consider that a mobile device is, in and of itself, a possession element, and that by sending an OTP to the device is enough to satisfy a “second” factor. We do not agree. We believe that over time, a device could become trusted as a second factor through fingerprinting and history of usage by the user – for example, Mary has authenticate from the same device for ten (10) times in a row; therefore, when someone presents Mary’s login credentials from this device we have a higher confidence that it is Mary, especially if all other contextual factors also are within Mary’s normal historic usage patterns. However, because devices can be easily stolen or lost, we do not feel that they should automatically be given “second factor” status.
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
Yes. In the context of “inherence” elements, we do believe that behavior-based characteristics are appropriate in the context of strong authentication. In fact, we would argue that they are essential to bridging the balance between user convenience and security.User behavior is a strong indicator of an individual’s identity. Intelligent, contextual authentication can detect and protect against high-risk login attempts or other sensitive actions (e.g., funds transfers, payments, etc.) by analyzing a wide set of factors, including user behavior, device characteristics, geolocation and velocity data, without requiring any direct input from the end user (this is very convenient to the end user). And when deemed too risky, the solution can automatically prompt the user to submit additional credentials or information to further prove their identity (e.g., biometrics, out-of-band OTP, etc.).
While the device fingerprinting, geolocation, and velocity checks are important in the overall risk analysis, it is the user behavior profiling that is the critical differentiator and most effective detector of many threats and fraud attacks. Not only must the attacker understand and mimic the true user’s behavior, they also must constrain themselves to performing activities that the user normally performs. In addition, it also provides the following benefits:
Applicable across many channels. User behavior profiling is already used by card issuers as part of Card Not Present (CNP) transactions to provide a frictionless user experience. It can also be equally applied to browser, mobile, and ATM channels. In addition, within a single enterprise, risk analysis results could be shared across all channels.
No training required. Most behavioral models can be deployed in production without collecting prior history, and they require no training for the end user; they work transparently in the background.
Quick time to value. Most models can begin yielding results on the second observation. Since User Behavior Profiling calculates normalcy, the assessment of even the second transaction is relevant.
Automatically adjusts over time. There is no ongoing customer analysis of good/bad transactions. As the user’s behavior changes, the model automatically learns the new patterns.
Intuitive user experience. Users are not surprised if they are required to (re)authenticate when they do something that may be deemed unusual and see this as good security practice.
Difficult to reverse engineer. The combination of multiple assessment dimensions makes it extremely difficult to reverse engineer because behavior is complex and accumulated over time.
We would recommend that risk analysis and user behavior profiling be incorporated and applied to user logins and used prior to conducting any high risk financial or payment transactions.
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
A software-based two-factor credential can accommodate multiple device types, including mobile devices – both for browsers running on the device, or embedded into mobile apps. In addition, the combination of a two-factor credential with risk analysis and user behavior profiling can provide a powerful, layered security approach that can significantly reduce the risk of inappropriate access and identity fraud.5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
We believe that the technology already exists to fulfill the objectives of strong customer authentication for dynamic linking; however, some enhancements and/or customizations to existing products may be needed to fully address this issue.The issues raised with regards to dynamic linking are not very different from an online credit card payment, where the card issuer must authenticate and authorize a payment where the card is not present. To address the security of CNP transactions, card issuers created the 3D Secure protocol. In addition, they have also increasingly been using contextual risk analysis and user behavior profiling to create a more frictionless user experience.
For dynamic linking, you could say that these are User Not Present (UNP) transactions. The user has previously authorized an automatic payment to a specific third-party vendor, and perhaps strong authentication was applied in order for this to be setup these payments (e.g., within an online banking application), but thereafter these transactions are processed automatically on demand without any user interaction (i.e., UNP). The security of these transactions can be significantly improved by implementing the same risk technologies that are used with CNP transactions.
A risk-based authentication technology can be used to monitor any actor – human or non-human. All things that “act” establish a behavior. In the case of a payment request that is initiated by dynamic linking, there will be “usage patterns” – for example, the payment request will be probably be submitted from the same servers, the same geolocation, at the same interval rate, and probably within the same time period. Some of these may also be for the same or approximately same monetary value. These behaviors can be modeled and evaluated for each subsequent request. When a request conforms to its normal patterns, it can be allowed to continue without any interruption, but when it deviates from its normal behavior, the transaction can be halted and the end user can be contacted via email, text, voice, or push notification to authorize the transaction. This gives the end user the ability to validate that this request is legitimate and should be paid. The solution could also generate an alert to the appropriate department or group within the bank about the irregularity, so that if this is a new attack, the bank can look for other fraudulent payment requests from the same locations or devices.
NOTE: At present, many risk technologies that utilize user behavior profiling have built these models to accommodate humans. When these models are applied to services, such as those involved within dynamic linking, some new parameters may be needed, such as average Euro/Dollar value per request; maximum Euro/Dollar value allowed (on per customer basis); typical day range for a request (if request is scheduled for 15th of every month, what is allowable range to accommodate weekends); etc. These rules and/or model changes would not be significant, but may be necessary to minimize false positives.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
Yes. We believe that risk authentication represents the best approach for mobile devices to fulfill the objective of independence and dynamic linking. First, the independence of mobile devices. An intelligent, contextual authentication technology can fingerprint any device and track the usage of these devices across all users and transactions. In addition, most technologies provide Software Developer Kits (SDKs) that enable risk data collectors to be embedded within mobile applications; therefore, this type of fingerprinting can be done equally well regardless if user accesses from browser running on device or a mobile app. In addition, when a device is identified to be the source of illegitimate or fraudulent behavior, it can be added to a black list and denied access for any user. This is also true if this device is identified by mobile, browser, or CNP channel. Second, we believe that the current contextual risk technologies are fully capable of handling and improving the security for the dynamic linking/UNP transactions.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Yes8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
Yes. The EBA states that “the security measures should be compatible with the level of risk involved in the payment service” and that exemptions for low value payments may be exempt from the technical standards. However, the EBA also observes that the reliability of risk analysis in related to the availability of sufficient payment and transaction history. Therefore, it might be recommended that all transactions – both low value and high value, be analyzed from a risk perspective in order to build up a sufficient volume of transactions for the payee.9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
Yes. Within each risk analysis technology, there exists the ability to identify locations and/or devices that are sources of fraudulent transactions. In many cases, the enterprise has the ability to put this data onto a “black” list, so that they are immediately flagged if the hacker attempts to use the location/device with other accounts. It is highly recommended that some exploration be given to how this data can be shared across the payment communities (e.g., perhaps a fraud network or some ability for one payment servicing entity to request risk data from another payment entity).10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Yes11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
The protection of users’ personalized security credentials throughout the payment chain is critical, and it appears that most of points where this data is most at risk have been properly identified; however, one should assume that any credential can and will be compromised. Therefore, it is also recommended that enterprises implement technologies, such as contextual risk analysis and user behavioral profiling, to further help identify a legitimate user. If you assume that a fraudster can and will steal a legitimate user’s personalized credential, then a layered security approach may be able to minimize the damage that the fraudster can do with the stolen credential.12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
The most ideal method of enrolment is in person, where the enterprise can conduct adequate and sufficient identity proofing before issuing a credential to the user. In addition, the enterprise can also establish a preferred method to identify the user in case the credential gets lost, stolen, forgotten, etc.13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
No. At the moment, these seem to be the most efficient methods for validating that a data center has implemented adequate security controls – certifications and independent security testing (e.g., PEN testing, white hacks, etc.).14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
Unfortunately, the weakest link will always be the users. There are any number of attacks that can be used to steal a user’s personalized security credentials. The second biggest risk would be backend user repositories that are storing password files (encrypted or hashed – both can be easily cracked).15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
Yes. One thought for consideration is for the EBA to provide a sample set of interoperability use cases that could be used by ASPSPs and AIS/PIS providers to test and certify that their interfaces are common and open. The US Government does this for specific identity federation vendors to certify that their solutions can address specific eGov use cases. This approach does cost money and resources, as the EBA would need to fund the creation of these use cases, and staff a lab to conduct the certification testing.19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
Yes. eIDAS could be one the possible solutions for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials. However, there are some concerns that should be raised, including: Coverage – the eIDs will not cover all EU citizens, nor will it cover non-EU citizens who are engaging in payment service activities within the member states; therefore, this means that the enterprises would still need to issue their own credentials to cover any user who does not have an eID.
Complexity – if each enterprise needs to support multiple personalized security credentials, issued from different entities, then how much additional cost and complexity does this add to their PSD2 burden? In addition, does this additional cost and complexity create a barrier for entry for new payment service providers?
Adoption – if users are given the choice between using an eID vs. a credential issued by their payment service provider, which one will they choose? Many users may view using an eID as a means by the governments to track their financial transactions. If so, the adoption rate for using an eID would be low.
Flexibility – the enterprises can quickly adapt to emerging technologies, and when needed, could more rapidly adopt and deploy a new, more secure authentication credential. It might take the governments much longer to issue a new form of eID when, and if, it becomes obsolete or insecure.