Two-Factor Authentication Best Practices
7 min read
The SAP Customer Data Cloud platform provides customers with a powerful feature called Risk Based Authentication (RBA) which consists of different scales of security mechanisms around authentication. Risk Based Authentication is an added layer at the client-side account security that can help prevent malicious attacks and hacking attempts on your site. SAP Customer Data Cloud has different types of Risk Based Authentication methods, for example; email verification, captcha or account lockout. In this article we will concentrate on one of them: Two Factor Authentication.
Table of Contents
Two Factor Authentication Options
At every login, users are asked to enter their password, which is what we consider the first factor of authentication. Some websites require that the authentication be made even more secure with a second factor authentication. Most commonly, Two Factor Authentication is enabled on sites that store very sensitive user data and one of the following risks are identified:
- a user tries to login from a different device
- a user tries to login from a different country
If one of these risks are identified at login, we can enable one of four actions which can increase the security on the account:
- Email Authentication
- SMS Authentication
- Time Based Authentication
- Push Notifications
Let's discuss each one of these options in depth:
When email authentication is triggered, the user will be sent a code to their email address which they will need to enter in order to login. This is considered the least secured mechanism because if the user's email is compromised as well, the attacker could easily reset the account's password and easily get the code. This method however has the least impact on user experience since in order to set this up, the user would simply need to verify their email address at registration.
The SAP Customer Data Cloud platform does not send SMS messages on behalf of the site. You will need to have an active licence with a SMS provider (Twilio or LiveLink) in order to enable SMS Authentication.
Time Based Authentication
Time Based Authentication is much more common in an enterprise scenario where we use an authenticator application to complete the login. The user gets a code sent to an authenticator app (Google Authenticator or Microsoft Authenticator), and is then asked to enter the code on the screen at login. This option is considered more secure however, it is rarely used in the B2C world since it really impacts the user experience.
Push TFA is considered the most secure authentication option. In this scenario, we push a notification to a mobile app on a user's phone where we ask the user to approve the authentication with a 'yes' or 'no' answer. This requires however that the website implements a mobile application which is not always the case for all types of clients.
It is good practice to offer different types of two factor authentications to your users at registration. This will enable them to choose their preferred option.
Enabling Two Factor Authentication means maintaining an increased level of security while sacrificing some of the user experience. In order for Two Factor Authentication to be enabled, the user will need to secure their account at registration. In order to secure their account they might be asked to verify their phone number or install a time-based authentication app. The following diagram illustrates the registration flow for the two factor authentication methods available for web implementations. In order to enable two factor authentication, the user will need to go through some extra steps at registration in order to secure their account. See image below:
This will slows down the registration process and the site will most likely experience a drop off in registrations at that moment where the user requires to go through this process. This is one of the considerations to take into account while implementing Two Factor Authentication. We see a great value in enabling Two Factor Authentication on websites that deal with sensitive user data. For example, on a bank website or commerce website where the attacker could potentially make purchases on the user's behalf. In these cases, securing user data at the cost of user experience is encouraged.
Two Factor Authentication is enabled at the site group level. This means that all child sites belonging to the same site group will have two factor authentication enabled. Technically, child API keys can be excluded, however that creates a security risk as child API keys are no longer protected and all users' data can be attacked through this route. There is therefore a consideration to take into account where all child sites in a site group will have their user experience affected by two factor authentication if one site in the site group requires the extra security.
Credential stuffing attacks
Credential stuffing attacks are becoming an increasingly popular form of hacking attacks. In this form of attack, hackers use a list of valid credentials that have been released in the dark web, and proceed to try to login to random sites using those credentials. It could be quite a dangerous type of attack because these hackers are trying real password and email combinations. The only way to stop these credential stuffing attacks are by enabling TFA. If your site is prone to these types of attacks, we strongly suggest enabling two faction authentication to stop the attackers.
There will always be a push back between user experience and security. On one hand, sites want to ensure that the user can easily and quickly access their site to monetize the opportunity while on the other hand we need to make sure to maintain a certain level of security to build a trusting relationship with our users. In today's world where data security is getting so important to consumers, and hacking attacks are getting more and more dangerous, it is a good practice at a minimum to offer users the ability to enable two factor authentication themselves, in order to give the more security conscious users the choice to enable it at the cost of user experience.
For more information on implementing Risk Based Authentication methods, please review the SAP Customer Data Cloud Developers Guide.