Mobile Authentication in FinTech
We first start with what is the definition of Authentication. Refer to https://en.wikipedia.org/wiki/Authentication, Authentication (from Greek: αὐθεντικός authentikos, “real, genuine”, from αὐθέντης authentes, “author”) is the act of confirming the truth of an attribute of a single piece of data claimed true by an entity. From my perspective, an Entity can be a real user, a device or application that have to “show” the “server” “something they have” before system access allowed.
In short, users must securely protect the “authentication data/attribute” or else when someone steals the data or reproduce the same credential, they can easily access the system with the same piece of data. This especially is important when the system only enforced password authentication (Single Layer Security). In general a complex password rule is not a good choice especially for a consumer-facing application, users will easily forget the password if it is not daily used application. This caused most of the mobile APP only go for the minimum password rule in order to maintain good user experience.
This short article mainly explains from a product design perspective, “What is the mobile application security design in term of authentication?” We will try to understand from the context of “Mobile Authentication” and what exactly it should look like?
• Is that securely authenticated the user/identity from application to authentication server only?
• Is that means mobile app/devices authentication from the devices to authentication server while identity verification remains the same method?
• Or combined both methods to achieve multi-layer security from mobile to server?
The main difference between web-based application versus mobile app is mobile app is natively designed as a Rich-Client (Access the device info, geo-location and etc) while Web Browser unable to access local resource due to the Operating System security design. Some argue that possible to perform the same with “web browser plug-in” or “endpoint client software”, however from my perspective, this is not natively available as you need to maintain the tasks like OS update, JAVA component update and etc.
With this mobile App offer more “authentication options” like
• Live Biometric gesture like “SHAKE” the handphone and system will know this pattern will match your registration profile.
• Face/Iris Recognition
• Fingerprint authentication as most smartphone come with this feature.
High-level authentication options available as follows,
• Password with well-defined rules
• Digital certificates that bind an identity to a public/private key pair.
• Hardware tokens/Soft Token/SMS Token
• Biometrics fingerprints, voiceprints, iris scans, handwritten signatures,
• Proximity-based authentication
• Keys-based authentication
Before going further, we also have a quick overview of the technology buzzword available today
Adaptive authentication
– Depends on risk profile defined, users required to authenticated based on the user access environment and all contextual attributed collected (GeoLocation, Browser Information, device information and etc)
Seamless authentication
is a method where the user is authenticated towards an entity without the burden of credential requests.
Behavioral Authentication
continuous user access authentication security monitoring and scoring, For example, speed of typing, application time usage, mouse movement, transaction information are some of the samples.
The concept covered above generally shares the same objective, “Minimize user intervention (Offer best user experience) while providing the highest security whenever needed”.
Many time customers wanted to deploy the One-Size-Fit-All authentication solution, but the reality was the more security you add, the cost of investment will go higher. Since Fintech app do not have strict regulated policies and procedure to comply like PCI DSS(Based on my best knowledge), they will go with the minimum requirements that fit their business requirements needs.
I tested a few eWallet mobile apps in Malaysia and quick fact-finding as below.
1. Some eWallet app enforces user MUST complete the user authentication successfully before proceeding to the service page while some other not?
From my point of view, this is the product manager to design it out. For example, if you offer wealth management app, do you required the user to complete the signed-up and log in again before showing your offer?
If I am the users of food delivery app, I would expect the app can quickly show me the food delivery services before I did my registration
2. Mobile application to log out the users if user login from other devices?
This is minimum control that I think it should deploy especially eWallet that deal with monetary transaction. This can effectively notify the “Owner” immediately if someone takes over your account remotely. TNG ewallet that notify users via the app when you pass over the toll is a good example, real time with almost zero cost.
3. User can log in with Mobile No/Email and PIN
When you access the app with either password or PIN, the strength of the authentication is almost the same. While shorter PIN Is weaker if the app does not apply any “key based authentication” or “Device Binding” mechanism. Attacks like phishing, fake-app download, and others attack can easily sniff the PIN easily.
According to the Verizon Data Breach Investigations Report, 30% of phishing messages get opened by targeted users and 12% of those users click on the malicious attachment or link.
4. What is the best way for “forget password” implementation?
eWallet apps have a different way of design when coming to user account binding. How the user identification flow work and the system will know each user is “unique”? Common options available as below
• Mobile No
• Email
• User Name
• Social Identity (Facebook/ Google)
• Combination of above
Example of Lazada Wallet, Wallet account is built based on the unique combination of an email address and phone number as below
https://www.lazada.com.my/helpcenter/miscellaneous-my.html?spm=a2o4k.helpcenter-topic.articles-list.5.46c34bd6OR8CeS
Some mobile App does not function as eWallet from day one. The mobile no & social identity seems the first choice to complete the registration as fast as possible. We must take into consideration like if users top up their money into the wallet, how they claim back the ownership if mobile no changed?
For instance I remember an eWallet player in Indonesia setup a services counter in shopping mall, besides reset the password, change the mobile no and top up the wallet credit as well. This can effectively perform the face-to-face and personal detail verification as well.
The minimum control that I think should be apply is the OTP for password reset MUST send to user email or via SMS. A wallet implemented both to ensure the user account security is worth to highlight from security point of view. When you use social identity like linked-in, google or facebook, by default it has built in good user verification capability.
Also tested with log in the app from different devices with the same credential like Mobile No + PIN/Password, I will be surprised that some of the apps didn’t require 2 factor SMS session verification for a new device that never used before.
eWallet is a TRUST business, NO SECURITY = NO TRUST = NO USERS.
I suggest FinTech App should take more effort and consideration into the “Security vs User Experience” design.
“Trust takes years to build, seconds to break, and forever to repair” “Unknown”
