Mobile Application as MFA Factor
This document proposes an approach on how to use the mobile application as a multi factor authentication (MFA) factor.
Reference Documents
| Reference | Document Location |
|---|---|
| REQ | Requirements document |
| DIA | Diagrams |
| VER | Verify MFA sequence diagrams |
Problem Description
To improve security in many sensitive user initiated operations we are currently using SMS or TOTP based MFA flows. Those flows have several drawbacks, the main ones are cost and security for SMS and poor user experience for TOTP. With the mobile application we have the opportunity to add a new mobile based factor that will reduce costs, improve security and provide a better user experience to our users.
Background
Relying only on user names and passwords for authentication and authorization is not enough. People having their credentials stolen by phishing or other types of attacks is a big risk that we need to mitigate, also regulations require us to enforce stronger authentication and authorization mechanisms.
MFA is a key mitigation for the risk of a user getting impersonated by a malicious actor. It reduces the risk because to confirm their identities users need to provide multiple proofs, which can be something that they know (for example a password), something that they have (a device) or something that they are (biometrics).
Our current MFA implementation allows the following factors on top of the traditional password: - SMS (Short Message Service): Our systems allow using a one time use code sent to the user’s registered phone number as MFA factor. The main disadvantage of this method is that delivery of the messages is not reliable. It's common for the messages to get delayed or never delivered. Another big con of this MFA factor is that each MFA SMS that is sent to an user’s phone number incurs a cost, which depending on the country of destination can be high. With the amount of MFA checks we perform each month the cost adds up to a considerable amount. - TOTP (Time Based One Time Password): This method is based on time based codes that are generated locally in the user’s device (usually a mobile phone) from a seed that is generated by the backend and then stored in the device. This method is safer than SMS but it also depends on how the users choose to manage their seeds. The cost is really low since we don’t incur any fee for each MFA check performed. The main issue with this method is that the user experience is poor, because the codes are generated by a separate application, that the user needs to switch to each time a MFA check needs to be done. Also since these codes are time based the flow may fail if the code is submitted near the end of its validity window.
MFA checks are enforced by the backend for the following operations: - Login: when an user that is configured to use MFA logs into the public API or EBO. - Payment submission: when a payment that contains non-trusted beneficiaries is created a MFA check is triggered. There are regulatory requirement which involves including details (payment amount, beneficiaries...) about the transaction being verified and ensuring the MFA token can only be used to authorize a single transaction. These requirements rule out using TOTP for payments.
In Ebury the service responsible for managing the MFA flows is Verify. It fully handles the TOTP flow, while for SMS MFA flow it relies on the third party service Twilio Verify.
Solution
The mobile application based MFA flow will be added as an additional MFA method. In this flow, when an MFA check needs to be performed users will be informed in their mobile device, by a push notification and by a prompt inside Ebury’s app. Then depending on the project phase the user will get a code to enter into the interface of the service (EBO for example) that needs to complete the MFA check or a dialog with yes/no option to complete the MFA flow without the need of additional interactions.
Prerequisites
The mobile MFA is based on the capacity of the backend to send notifications to the app, push notifications to the devices, and track which users are active users of it. Those capabilities fall outside the responsibilities of the MFA service and are part of the Messaging Services, Device-Binding service, Mobile API service and Tracking service. Not all prerequisites are mandatory at the beginning of the project.
Push Notifications
This is an optional feature because users can choose to opt-out of push notifications in their device configuration. If push notifications are available the user will receive a notification when a mobile MFA check needs to be completed.
Tracking Active Users and Devices
In order to manage the eligibility of a user for mobile MFA our systems need to track how users interact with them: - If there is a mobile app available to the user. - If the user uses the mobile app actively. - If the user is currently logged in. - If the user uses quick log in.
Tracking active users and eligibility is a complex task that will require gathering information from multiple services. A new service with its own RFC will be designed for it.
Application Downtime Tracking
During incidents or maintenance periods the mobile application might not be available. The Mobile API backend service keeps the availability status of the application. This service will inform the MFA Service of any status changes for the app, for example when it enters or exits maintenance mode. The MFA Service will fall back to SMS when the mobile application is unavailable.
Mobile MFA Flows
Since our existing authentication functionality and MFA services have some limitations, plus the ongoing effort to replace them with an open source IAM solution, the implementation of mobile based MFA will be split into two separate flows. A first one that is going to be code based, mimicking the existing SMS flow but using app notifications to deliver the codes, this method keeps a very similar user experience and it's easier to integrate with the existing authentication flows keeping technical debt to a minimum. The code based flow will also be integrated with the new IAM. A second flow, named pass back, based on a challenge that needs to be solved by the device. It will be added after the transition of the channels to the new IAM solution. In this flow when an operation needs MFA the user will be presented with a popup in the mobile app that will ask for user approval, when the user taps the approve button the mobile app will solve a challenge provided by the backend that will complete the MFA check.
Code Based
The mobile based MFA will mimic the existing SMS flow and reside inside Verify. The following diagram represents a high level sequence for the code based MFA flow:
When a mobile MFA flow is triggered Verify will generate a six digit code, and store in its persistence the user/device, message, code hash, creation date, expiration date and a counter of the verification attempts. It will then send a notification with the code and the message through the Messaging Services. The notification will include an expiration date so it doesn’t get delivered after the code expiration date.
The Messaging Services will make the notification available to the device until the MFA flow expires or is completed. When the device retrieves the notification it will show a pop-up to the user with information about what the user is authorising and the code. If a push notification was sent and the user taps it will bring up the application with the pop-up visible. The user can choose to hide the notification, int this case it will be accessible in the notifications inbox until it expires.
The user needs to type in the code in the service that needs to complete the MFA flow. The service will then ask Verify to validate the operation. Verify will check that the code is not expired, that it's correct and inform the calling service of the result. If the code is incorrect Verify will increase the failed attempts counter and upon reaching the maximum number the code will no longer be valid.
Pass Back - Challenge
The pass back flow will improve the user experience by getting rid of the codes, allowing the user to complete the MFA check by tapping a button. The following diagram represents a high level sequence for the code flow:
When a mobile MFA flow is triggered Verify will generate a device challenge, and store in its persistence the MFA check id, user/device, message, device challenge, creation date, expiration date and a counter of the verification attempts. It will then send a notification with the device challenge and the message through the Messaging Services. The notification will include an expiration date so it doesn’t get delivered after the MFA check expiration date.
The Messaging Services will make the notification available to the device until the MFA flow expires or is completed. When the device retrieves the notification it will show a pop-up to the user with information about what the user is authorising and an accept and deny buttons. If a push notification was sent and the user taps it will bring up the application with the pop-up visible. The user can choose to hide the notification, it will be accessible in the notifications inbox until it expires. If the user taps the accept button the device will solve the challenge by hashing its device id concatenated with the challenge. Then it will submit the challenge response to Verify. Verify will check that the MFA check is not expired and if the response to the challenge is correct, it will publish a Kafka event indicating that the MFA check was completed. If the response is incorrect Verify will increase the failed attempts counter and upon reaching the maximum number the challenge will no longer be valid.
The service that requires the MFA check can consume the Kafka event from Verify to trigger the completion of the operation.
PSD2 Compliance
The new mobile MFA methods need to be compliant with PSD2. In order to do so, when authorizing transactions, each triggered MFA flow will be linked with a single transaction by using Verify action tokens. The Mobile App will also show information of the transaction being authorized, the same way we do currently with SMS.
Solution Diagram
The following diagram contains the services that will be involved in mobile MFA before the new IAM solution is deployed.
Project Phases
Phase 1
The first phase will provide the first implementation of the code based mobile MFA. Verify will generate the code and send it to the mobile app which will show a popup with the six digit code. The code will have an expiration date and time that will be handled by Verify. Verify will also be able to fallback to SMS when the mobile application is in maintenance mode. Verify will generate metrics and monitoring panels and alerts will be put in place. For auditing purposes the MFA flows will be persisted in a database and logs will be generated.
The mobile application will get the capability of querying the Messaging Services to retrieve the pending MFA notifications and displaying them to the users.
Customers will have to manually switch from SMS to mobile MFA using a setting that will be located in EBO.
For this phase the Messaging Services and The Mobile API prerequisites are needed.
Phase 2
In this phase Verify will implement improved tracking of the state of the MFA request, and will also gain the capability to include information in the notification for the user regarding what the MFA request is for. On top of that the first iteration of reinitiation will be included which consists on allowing the MFA flow to be re-requested and having the service only taking into account the latest flow.
Monitoring will be enhanced with new metrics and panels.
Phase 3
This phase will put in place the rate limits for MFA requests, improve the audit entries and enhance monitoring.
Phase 4
Phase four will be focused in allowing the users to revert to SMS by themselves. When a mobile MFA check is initiated there will be an option in the user interface to request an SMS instead.
Phase 5
This phase will add the capability of sending push notifications to the mobile device. They will be sent through the Messaging Services. The mobile application will gain the capability to register into the Messaging Services for push notifications, listen to them and show them to the user.
Phase 6
This phase will improve tracking of failed or declined MFA flows, allowing us to set limits to them, triggering alerts and even blocking accounts.
Phase 7
During this phase the challenge based MFA flow will be added (pass back). Verify will gain the capability to generate, send and verify challenge based MFA requests, while the mobile app will get the capability of retrieving the notifications for the new flow, show the proper dialog, solve and submit the challenge.
For this phase the new IAM service is needed.
Phase 8
Until this phase the users had to be manually switched to the mobile MFA flows, either by themselves using EBO or by our backoffice teams. In this phase we add the capability to the system to properly identify if an user is eligible to use the mobile flows, allowing us to automatically switch them to the best flow for them and Ebury.
This phase requires the eligibility tracker.
Service Ownership
| New Service | Service Name | Service Owner |
|---|---|---|
| No | API Gateway | MOB Team |
| No | API WebApp Proxy | MOB Team |
| No | Device-Binding | MOB Team |
| No | EBO | ONL Team |
| Yes | Eligibility Tracking | MOB Team |
| No | Messaging Services | MOB Team |
| No | Mobile API | MOB Team |
| No | Verify | MOB Team |
Alternatives
There are products like Twilio Verify Push and Duo that provide mobile MFA flows, they even offer their own app to complete the flows. The main cons of using them are cost (for example Twilio cost is $0.05 per MFA check) and that if we choose to use their app we need to instruct our users to download and configure it, and then direct them to the third party app to complete the checks.
Caveats
The proposed solution is a bit complex, but the split in phases allow us to reduce its relative complexity.
When the new IAM system is in place Verify may need some tweaking. The main tweaks are: - API changes to make Verify easier to integrate with the IAM. - Some of Verify's responsibilities could be moved to the IAM. - MFA flow initiation: services that need to perform MFA checks could need to use the IAM instead of Verify. - MFA user settings: Verify will need to retrieve and update them in the IAM when needed.
Operation
The only new service is the Eligibility Tracking service which will have its own RFC.
Security Impact
A new MFA flow will be added to Verify which has a security impact.
Performance Impact
The changes proposed in this RFC should not have a performance impact on any of the backoffice services. It will add new events and topics that increase the load of the Kafka clusters. Last, the new functionality provided by the service may increase slightly the amount of requests that our public API receives.
Developer Impact
We don't expect any immediate developer impact. When the service is complete developers will be able to use a new MFA flow with Verify.
Data Contracts
Verify API will be extended in a backwards compatible way to allow consumers to trigger the new MFA flow.
Data Sources
New data sources: - Device-Binding, Mobile-API and Messaging Services to track the eligibility of the users to the new MFA flow. - Mobile-API to track the status of the mobile app.
New output data: - Logs recording system operation. - Database records storing the MFA processes and their details. - Kafka events with eligibility information and MFA process results.
Deployment
Any new service will be deployed using the standard pipelines and procedures already in place.
Dependencies
Mobile MFA depends on: - Messaging Services - Mobile API
Based on RFC Template Version 1.1