Five Ways Modern Multi Factor Authentication Secures and Protects Fintechs

Five Ways Modern Multi Factor Authentication Secures and Protects Fintechs

By Jacob Ideskog, CTO, Curity 

Five Ways Modern Multi Factor Authentication Secures and Protects Fintechs 2

Jacob Ideskog, CTO, Curity 

The financial industry has undergone a lot of change in the last two decades. From simple steps such as Online Banking to Open Banking and Finance, it is arguably one of the most disrupted industries. 

As technology has evolved, so too has the level of threat to personal data held by businesses for consumers. Those wanting to illegally access data have become much more sophisticated and businesses have needed to up their game when it comes to protecting their customers. Security methods from ten, even five, years ago no longer suffice as information sharing continues to dominate the digital landscape. 

Financial institutions hold some of the most valuable data, meaning hackers and bad actors are willing to go to extreme lengths to try and gain access. This means authentication methods like Multi Factor Authentication (MFA) are more important than ever. There are three key areas to remember when concentrating on data protection and security: knowledge (what someone knows), possession (what someone has), and inherence (what someone uniquely is). 

This article will discuss the five new techniques that have evolved and been adopted for MFA. Financial institutions should look to these techniques when it comes to data protection and ease of access. 

Always On and Opt In 

Always On is consistent with its name – MFA is always on and is always a user requirement. At every log-in opportunity, users will be prompted to use two or more identifying factors in order to access the account in question. While this method is the most rigorous in terms of security, it is the least user-friendly. The continuous demands for re-authentication can become tiresome to users, particularly if they accidentally close a webpage and need to quickly re-access the information as is common with accessing financial information. It is also important to note that not all information requires the same level of protection. For example, an online-banking interface requires a higher level of security than an online credit platform such as Klarna, where users might be logging on just to check the date of their next payment. While this rigid approach works for many applications, there are different approaches that offer more flexible MFA that are better suited for others. 

Opt In MFA is one example of a more flexible solution for financial institutions. It strikes an important balance between helping users to protect their data and offering more flexibility depending on the sensitivity of the data. Opt-in MFA means customers are prompted to set up additional authentication factors, but can decide for themselves whether to do so. 

Step-up Authentication 

As briefly mentioned with Opt In, some data does not require a rigorous authentication process and a single log-in is the only authentication necessary. 

However, if a user needs to access more sensitive information, they will receive a series of authentication questions, “stepping up” from one form of authentication to multiple. Step Up is initiated by an OpenID authentication request with a higher privilege scope, particularly prevalent in the financial industry. Here, the initial log-in process may be to just check a bank balance or when a credit card bill is due, but if a customer then chooses to make a payment or update their personal information, the additional authentication process will prompt them to answer a security question, or use a secondary authenticator such as a biometric. If users were prompted to use MFA from the start, they may be less inclined to log-in for simple tasks such as balance checks, or to confirm a transaction was successful, meaning Step-up Authentication can offer a good balance between user experience and security. 

Time Sensitive Re-Verification 

This approach is becoming more common, particularly with access to email or cloud-based document accounts such as Google Drive, or Microsoft 365. With this approach, users are required to log-in using MFA the first time they access their account, however if a user continues to access their account regularly, and via the same browser they are rarely prompted to re-enter their verification information. This process requires fine-tuning of the Time To Live (TTL) for different authentication factors, so the trusted device can be established at the initial log-in. The TTL for the different authentication factors is set for different time periods, meaning the password expires before the coding of the verification, so that while users will need to change their password for security reasons on a semi-regular basis, they will not need to continuously enter the password to access their information. However, if a user changes the device they access the account from, or their browser (ie. from Google Chrome to Microsoft Edge) they will need to go through the MFA process. 

This approach gives cyber security professionals the option of flexibility, allowing them to set the TTL to the time period that works best for their business model in order to optimise user experience while protecting the necessary data. 

New Country vs Changed Country 

It is also possible to use geolocation to support the MFA process which is particularly useful for remote workers or those who travel frequently. While geolocation cannot exactly pinpoint a user’s location to the exact house number or to identify them as an individual, it can determine the country where the user request pings from. 

New Country as an action can be as simple as businesses need. It only requires a Bucket to store and a boolean subject attribute that will be related to the geolocation. If this attribute is not set, the boolean value will change to True and it will be considered a new geolocation, requiring additional log-in and authentication. However, once the user continues to log-on from this geolocation, the boolean value will be set to False, and they will no longer need to go through the MFA process. 

The Changed Country functionality offers similar simplicity. It also requires a Bucket to store data and an attribute name for a boolean subject attribute. In this instance however, the boolean value will be set to True every time the user logs on from a different country, meaning that previous geolocations will be forgotten and if the country is different from the previous, they will be required to re-authenticate. 

These two actions are useful tools to support the MFA. While the actions are similar, the crucial difference lies in the Changed Country “forgetting” geolocations once they change, while New Country will only change the boolean value to True if the location is brand new and not been used before as an access point. 

The Impossible Journey Authentication Action 

Slightly different to the previously mentioned MFA approaches, the Impossible Journey serves instead as an authentication action, or prompt, and adds additional authentication layers where necessary. 

The Impossible Journey action is also fairly straightforward to use. As with the New Country vs Changed Country, a data source is needed to store the geolocation, along with an attribute name, with the Boolean subject attribute set to True if an impossible journey has been identified. This identification process also includes speed as a determining factor. 

As previously mentioned, the geolocation is not enough to serve as an identifying factor, however the Impossible Journey will capture longitude and latitude which is then stored (Point A). When the same user authenticates again (Point B), the action verifies the speed it would take to move from Point A to Point B, and if the speed is slower than the configured speed, the Boolean value will be set to False. If the speed is faster it will be considered an Impossible Journey and the boolean value will be set to True and the user will be required to go through additional authentication. 

The ever-changing MFA landscape 

The end result of MFA is access tokens issued with scopes and claims. These tokens can be sent to APIs which will authenticate and authorize requests. MFA is also a crucial tool due to its customisable nature. Custom claims from authentication can be issued in access tokens, usually only associated with high privilege claims. This allows companies to tie authentication strength to data protection, thus offering them a stable solution that is tailored to them. 

It is clear that the security solutions that financial institutions have previously relied on no longer match the skills of sophisticated bad actors. While the data FIs hold for their users is precious, the reasons users need to access it continually differ, meaning they require a broad range of options when choosing the most appropriate MFA functionality. 

User experience and safety should be priorities for FIs, and the five new elements of MFA laid out in this article all support this idea. These solutions are hugely beneficial to FIs, as they support the notion of progressing security levels, improving the core security structure to make it less susceptible to attacks, therefore protecting valuable financial data, while streamlining platform functionality. If financial institutions take stock of their security solutions and look to implement new MFA, they can ensure the investments they make are improving the security of their platforms, while delivering on values that put user experience at the heart of their business model. 

Source link

Share This

Leave a Reply

Your email address will not be published.