MOBILE BANKING THREATS

Threats observed during user authentication
An adversary can download the client on a laptop/desktop and use its insecurities for malicious purposes.
An adversary can obtain the user credentials stored on the mobile phone by transferring the contents to pc/laptop from the phone or memory card.
An adversary can register with valid details of a valid bank account holder and access his/her account details or make transactions.
An adversary can access user credentials directly from the phone’s folders or from phone’s memory card.
An adversary can obtain the new PIN for transacting using the weak forgot password feature or an adversary can change the password/PIN of a valid user without authentication/authorization. An adversary can use the auto-complete feature to access a valid user’s account.
An adversary can guess weak passwords/PIN to retrieve customer information.
Ideal scenario
Threats addressed in the following method:
An adversary can download the client on a laptop/desktop and use its insecurities for malicious purposes
An adversary can use the auto-complete feature to access a valid user’s account.
The customer has to first register with the bank. Customer details like full name, postal address, e-mail address, bank account details and mobile phone number should be provided.
The bank would inform the vendor to push the mobile client application to the mobile number provided by the customer. This can be done through a system which communicates between the server at vendor end and bank end. The vendor enters the mobile number of the customer and the client application is pushed to it. This ensures that the client is not downloaded to a pc or laptop and misused. In case the push is not possible, the customer has to be informed and the client application installed by the vendor.
The application has to ensure that during installation a few checks are done
Transfer the bank’s and vendor’s public key for encryption purposes. There can be two keys generated for the vendor; one for storage and one for data transmission.
The client files/folders are installed on the phone and not in the memory card.
The files and folders should be restricted from being transferred to a memory card or pc/laptop. The access to these files should only be through the executable and not directly.
The installer should be removed after installation.
Application should not allow auto-complete feature.
Threats addressed in the following method:
An adversary can guess weak passwords/PIN to retrieve customer information
Once installation is done, customer has to use the client to register with the vendor for using their application to transact through mobile phones. During this process the above mentioned details should be provided through the client. Along with this, the customer has to create a unique username and password for critical transactions like fund transfer, bill payment, etc and a PIN for non-critical operations like account status check, cheque status enquiry; and a hint question/secret answer for forgot password feature. Ideally, the customer should not create a username/password combination; the customer’s Internet banking credentials should be used. This ensures that for critical transactions, the details are not stored at the vendor’s server. The PIN, which is used for non-critical operations, can be encrypted using a one-way hash function at the vendor’s server.
The password and PIN should follow a strong password policy.
Threats addressed in the following method:
An adversary can register with valid details of a valid bank account holder and access his/her account details or make transactions
There can be two layers of authentication; one using the Internet banking credentials for critical transactions which is verified by the bank; and another using the PIN for non-critical operations by the vendor.
During registration, the application should send the customer details like name, address, etc and mobile number in an encrypted format using the vendor’s transport public key. The MSISDN number has to be appended to this encrypted data by the mobile network provider when it exits the mobile network. The vendor server-side application will verify whether the mobile number entered by the customer and the mobile number provided by the network provider is same or not. Alternatively if this is not possible, the vendor will have to verify with the customer by calling back on the mobile number provided.
After registration with vendor, the customer details like name, bank account details, postal and e-mail addresses are stored at the vendor server.
Threats addressed in the following method:
An adversary can obtain the user credentials stored on the mobile phone by transferring the contents to pc/laptop from the phone or memory card
An adversary can access user credentials directly from the phone’s folders or from phone’s memory card
Ideally, customer details should not be stored on the mobile phone. If they are, these checks should ensure they are secured from misuse.
Store the customer data using the vendor’s storage public key. If for any reason these details are required, the encrypted data can be sent to the vendor server.
Username/password or PIN should not be stored on the mobile phone.
The customer data should not be directly accessible from the mobile phone, only the application should access it.
Forgot password feature:
Threats addressed in the following method:
An adversary can obtain the new PIN for transacting using the weak forgot password feature or an adversary can change the password/PIN of a valid user without authentication/authorization
During user creation, the application should ask for a hint question and answer for ‘forgot password’ feature.
The user should enter the correct answer to the hint question to obtain the new password
Once the user enters the correct answer to the hint question, the customer details from the mobile phone should be deleted. The application should inform the vendor/bank about the password change and should be ready for re-registration of the customer.
The new password should be sent to the user via an SMS
Using this password the customer should register again only with the vendor.
The application should provide the feature to change the password on first logon.
Threats observed during transactions
Based on the services provided to the customer the following threats can be observed
An adversary can sniff the contents of transaction and obtain confidential information.
An adversary can bypass authentication controls.
An adversary can make bogus shopping or purchase transactions for another valid customer.
An adversary can view the account details of another user.
An adversary can modify the ‘from account’ and amount field during a fund transfer process.
An adversary can predict the session id and perform transactions as a valid user.
An adversary can access a valid account using an active session which has not been terminated after a long time of inactivity.
An adversary can login using his credentials and view/modify the details of another valid customer.
Illegal/Invalid transactions can be performed without continuous authentication process for each transaction.
Ideal scenario
Threats addressed in the following method:
An adversary can sniff the contents of transaction and obtain confidential information
All transactions should be through a secured connection. Data transmitted between the client application and the vendor server should be through HTTPS or another secured channel and also encrypted through the vendor’s transport public key. The data flowing back from vendor sever to the client should be through HTTPS or a secured channel.
The data flowing between the vendor server and bank server should be through HTTPS. Also the customer details, which are not required by the vendor, should be encrypted using the bank’s public key. The return should be through HTTPS.
Any data flowing between bank/vendor to other third parties or merchants like for mobile shopping should be through a secured payment gateway.
Threats addressed in the following method:
An adversary can bypass authentication controls
Illegal/Invalid transactions can be performed without continuous authentication process for each transaction
An adversary can view the account details of another user
Each transaction or operation should be authenticated either using a single layer or a dual layer.
The vendor side application should authenticate the customer using the PIN for non-critical operations. Validation checks should be in place to ensure that this authentication control is not bypassed.
For critical transactions, there can be dual authentication mechanism, one using the PIN at the vendor and other using the Internet banking ID at the bank side. Validation checks should be in place to ensure that this authentication control is not bypassed.
Threats addressed in the following method:
An adversary can make bogus shopping or purchase transactions for another valid customer
An adversary can modify the ‘from account’ and amount field during a fund transfer process
For example, in a fund transfer operation the bank should ask for the Internet banking credentials from the customer for authentication and verification. Also checks need to be in place to ensure that the ‘from account’ field cannot be modified or the ‘amount’ field is not negative.
In mobile shopping operation, the payment should be through a secured payment gateway. Ideally, the vendor should not store the details of the shopping done by the customer. In case the vendor performs the payment for the customer for his/her purchases, then only the details need to be stored at the vendor. Then the customer authorizes the bank to transfer the amount to the vendor’s account for making the payment to the merchant for his/her item.
Threats addressed in the following method:
An adversary can predict the session id and perform transactions as a valid user
An adversary can access a valid account using an active session which has not been terminated after a long time of inactivity
An adversary can login using his credentials and view/modify the details of another valid customer
Having a good session management mechanism ensures that attackers don’t use a valid session id for login purposes. Also the application should ensure that users are not able to change the data and view another customer’s details [like URL manipulation].
Other possible threats
An adversary can upload malicious files to the server/application.Ideally, a mobile banking scenario would not require a customer to upload files to the server. Hence the same can be disabled for customers.
An adversary can obtain the confidential customer data and source code from the serverAll customer data and application source code at the vendor server should be protected not only from the outside attackers, but from internal users/developers also.
Malicious activities are undetected.Audit trails and logging need to be maintained for the application which mentions the customer name, bank details and transaction performed with time and date for future reference.
An adversary can obtain the details of the server or error messages provide information for the adversary to perform specific attacks.The application should ensure no messages are provided to the outside world which would reveal information about the system.
An adversary can obtain the vendor private key from the server to perform man-in-the-middle attacks.The private keys should be stored securely and access should only be given to the application to use the keys during any kind of operations.
In short the idea is to maintain CIA during storage and transmission. The concept of dual layer authentication, multiple encryption mechanisms and restricted access through the mobile client application achieves just this.
The Mobile Station International ISDN Number is the standard international telephone number used to identify a given subscriber. MSISDN is defined by the E.164 numbering plan. This number includes a country code and a National Destination Code which identifies the subscriber’s operator