.jpg)
Hackers most often choose applications that have weak security or (horror!) no security at all. What's worse, 77% of application hacks are caused by the use of stolen credentials, and 21% are by brute force (usually easily guessable passwords)[1]. Institutions supervising financial markets note that poor security is a source of significant risks, both for customers and companies providing services in the financial sector. Hence, they recommend using strong (at least two-factor) customer authentication[2].
In this article we will check:
- Why is authentication an essential element of financial applications?
- Is it profitable to build your own authentication system or is it better to use ready-made solutions?
- Which authentication system will work for on-premise solutions?
- What should you pay particular attention to when deciding to implement an external authentication application into a financial application?
Why is authentication an essential element of financial applications?
Strong authentication is an important element of a financial application because it aims to ensure the security of financial funds and protect the confidentiality of user data. It also protects the financial institution from liability for unauthorized payments, because the regulator has transferred the burden of proving that the transaction was authorized correctly to the service provider.
Did you know...
the penalty for not complying with PSD 2 is a fine of up to EUR 20.000.000 or 4% of annual revenue (whichever is greater).
However, it is important to emphasize that in financial applications, authentication must be strong. In practice, this means using at least two elements that fall into the category:
- knowledge - something only the user knows (e.g. PIN),
- possession - something that only the user has (e.g. a payment card or token),
- customer features – something that is unique to the user (e.g. fingerprint).
This contributed to the spread of the required standard of two-factor authentication (2FA). Additionally, IT solution providers build applications based on proven authentication protocols (OAuth2/OIDC) and mechanisms that enable convenient management of password and security "policies".
Of course, not all financial apps are related to payment services. Some of them only support aggregated data used when creating mandatory reports. However, the authentication function is a standard in the electronic financial services market, defined by various legal acts: PSD2, DORA, GDPR, etc.
Authentication applications are an effective tool for securing access to IT systems, but their use must comply with regulations, including GDPR.
The regulation in Art. 24 and 32 imposes a number of obligations on Controllers in the field of personal data protection - the key is to minimize and transparent data processing and respect the rights of data subjects, i.e. users (Articles 12-23 of the GDPR).
Our development team is aware of these requirements, understands and is familiar with the provisions of the GDPR, and discusses any concerns with the Data Protection Officer, so I am confident that by following the principle of privacy by design (Article 25 of the GDPR), at FINGO - already at the solution design stage - we consider important scenarios and carefully select tools supporting security.
While maintaining transparency, we provide customers with the necessary information regarding the data processing process, our procedures and the security measures used.
An important element of maintaining compliance is regular audits, both of the security of our applications and compliance with normative acts, including GDPR. Thanks to cyclical inspections, we can be sure that security processes and measures are up-to-date and effective, and we can also detect and remove potential vulnerabilities and threats more quickly. - says Kinga Brzozowska, Information Compliance Officer at FINGO
Is it profitable to build your own authentication system or is it better to use ready-made solutions?
There are ready-made authentication and authorization solutions available on the market, operating both in the cloud and on local infrastructure (on-premise). These tools can be natively integrated with a variety of products and services, including security tools, making access management simple.
Authentication may be implemented by built-in mechanisms in products or services, or provided as separate software, hardware or cloud services. This flexible approach allows companies to tailor technologies to their specific needs, effectively securing resources, regardless of the scale and location of the IT infrastructure.
The unquestionable advantage of ready-made authentication solutions is incomparably faster implementation and compatibility with other systems indicated by the provider. However, there are situations when the customer, unaware of the complexity of a project, wants to create a dedicated solution.
Some time ago we worked on a classic Proof of Concept for a financial application. The project was intended to present the possibilities of a certain algorithm to potential business customers.
In our opinion, at this stage of application development, it would be enough to implement a trial version of some authentication solution that is already available on the market. We tried to convince the customer to do this as well. Unfortunately, to no avail.
Despite our team’s enormous skills and experience, we encountered many exceptions that unfortunately increased the workload. Ultimately, we delivered the authentication application, but its development took much longer than originally expected.
It should be emphasized that to ensure an appropriate level of security, the authentication application requires constant updates, development and regular testing. - says Kamil Matuszewski, Project Manager at FINGO.
In projects where business requirements overlap with the functions of a commercially available authentication application, it makes more sense to implement such a ready-made solution. This will allow you to avoid many embarrassing situations resulting from underestimating the scope of work.
The issue of subsequent maintenance will also be solved, i.e. constant updating of the tool, which ensures the appropriate level of application security. Not to mention work such as maintaining the database, making backups and providing good hosting.
What's more, new malware is created regularly and you need to be able to defend yourself against it, which requires expert knowledge. An example is the Xenomorph malware detected in 2022, which "specializes" in intercepting authentication data in banking applications.
Costs are also a reason to implement a third-party authentication application. When we look at the details of the service providers' offers and compare them with the number of users of our application, it turns out that the cost of a third-party application is relatively low.
Example of Google Identity Platform prices as of May 21, 2024.
Pricing for the Identity Platform is divided into different tiers based on the authentication method used.
Tier 1 providers - Email, Phone, Anonymous, Social
Monthly Active Users (MAU) 0 - 49,999 >>> Price per MAU ($) 0
Monthly Active Users (MAU) 50,000 - 99,999 >>> Price per MAU ($) 0.0055
Tier 2 providers - OpenID Connect (OIDC), Security Assertion Markup Language (SAML)
Monthly Active Users (MAU) 0 - 49 >>> Price per MAU ($) 0
Monthly Active Users (MAU) 50+ >>> Price per MAU ($) 0.015
For phone authentication and multi-factor authentication
Prices for each SMS sent using phone and multi-factor authentication are different to countries. The first ten SMS you send per day are free. Eg.
- Poland - $0.03
- Germany, Switzerland - $0.09
- Czechia, United Kingdom, Spain - $0.06
- France - $0.08
- Finland, Ireland - $0.07
Ready-made authentication applications enable easier scalability, i.e. flexible expansion and reduction of the number of supported users. As well as simpler integration with other solutions, e.g. mobile applications, or configuring applications with other servers and databases. All you need is proper technical documentation and some programmer's man hours.
Which authentication system will work for on-premise solutions?
Keycloak is a free, open-source identity and access management solution used in on-premises financial applications. It has many important functions, such as:
- access management,
- multi-component authentication,
- catalogue integration,
- Identity management APIs.
Moreover, it supports widely known security protocols, such as: OpenID Connect, OAuth 2.0 and SAML 2.0.
We once created a group of applications that ran in the internal IT infrastructure of a financial institution. Besides two-factor authentication, one of the additional requirements was integration with the institution's Active Directory.
Therefore, we needed an IAM platform that would meet rigorous security standards and at the same time provide "ready-made" mechanisms enabling integration with external systems related to the authentication process.
We were looking for an intensively developing system with an active and stable community behind it. Moreover, due to the unusual permissions model, we needed an open-source solution with an architecture that would support the expansion of the system with our own plugins, providers, etc.
The choice fell on Keycloak, an IAM used in many financial institutions where security is a key aspect. In addition, Keycloak (like most of our applications) is written in Java. And in case of problems, we could always "look at the code" or turn to the large community supporting this open-source solution. - says Paweł Śnieżek, Senior Software Engineer
What should you pay particular attention to when deciding to implement an external authentication application into a financial application?
When implementing an external authentication application for a financial application, it is worth paying attention to several key aspects that will ensure security, compliance with regulations and user convenience. Here they are:
Safety
- Encryption. Ensure that the authentication system uses strong encryption algorithms (e.g. AES-256) for both data at rest and in transit.
- Authentication protocol. Choose a system that supports secure protocols such as OAuth 2.0, OpenID Connect or SAML.
- Protection against attacks. The system should have mechanisms for protection against brute force attacks, phishing, man-in-the-middle (MITM) attacks and other threats.
Compliance with regulations
- Industry regulation. Ensure that the authentication system complies with relevant regulations and industry standards, such as PSD2 (Payment Services Directive 2), GDPR (General Data Protection Regulation) and PCI DSS (Payment Card Industry Data Security Standard).
- Auditability. The system should offer full login and the ability to audit user authentication operations.
Access control and identity management
- Roles and powers. The system should enable the definition and management of user roles and authorizations in a precise and flexible manner.
- Integration with other systems. Make sure the authentication system can integrate with other identity management systems such as Active Directory, LDAP, or access management (IAM) systems.
Multi-factor authentication (MFA)
- Support for MFA. The system should support multi-factor authentication to meet regulatory requirements.
Usability and user experience (UX)
- Ease of use. The authentication process should be intuitive and easy for users to perform to minimize frustration and errors.
- Personalisation. Ability to customize the login interface to match the appearance of your financial application, improving visual consistency and user comfort.
Performance and scalability
- Scalability. The system should be able to handle the growing number of users and transactions without any loss of performance.
- Reliability. Select a system that offers high availability (HA) and redundancy to ensure continuous availability of the authentication service.
Technical support and documentation
- Support. Make sure the authentication system provider offers solid technical support and quick responses to reported issues.
- Documentation A well-documented system makes integration, configuration and subsequent management easier.
No less important are experienced developers who can implement their knowledge in practice.
We commissioned FINGO to design and develop a new authentication system based on OAuth 2.0. This system was crucial for Penneo's integration with external systems and facilitates the sale of our product to customers who attach importance to safety. We are pleased with the collaboration and appreciate FINGO engineers' technological knowledge and their ability to apply it in practice. - said Joy Lazari, Engineering Manager Penneo API & Integrations.
[1] 2024 Data Breach Investigations Report
