Security Implications. The future use of standardized web technologies in mobile banking will likely be similar to that of home banking using browsers and websites, but not the same. The similarities and differences allow us to distill some implications. What kept mobile banking relatively safe so far is a number of factors: (1) Mobile banking is not as popular as home banking [iResearch 2014; Board of Xxxxx- xxxx of the Federal Reserve System 2015; Banking & Payments Federation Ireland 2015]*. It is logical that malware is written for the most popular platform for online banking, since more users equals more possible fraud victims. (2) Home and mobile banking have an overlap in supported functions. If these func- tions are security critical (such as when transferring money), the mobile banking implementation is sometimes more limited compared to the home banking imple- mentation by the same bank. Some banks in our survey only allow money transfers to previously used account numbers as destinations through mobile banking. Some others do allow first-time transfers to new accounts, but only with an extra authen- tication step or with a limit on the amount of money (which is sometimes adjustable by the user in the home banking environment). (3) Malware aimed at home banking can be written once and customized for each targeted bank site to allow browser injection and hijacking, a modus operandi known as Man-in-the-Browser [Xxxxx 2010; Xxxxxx and Xxxxxx 2012]. Malware ACM Computing Surveys, Vol. 49, No. 4, Article 61, Publication date: December 2016. A Survey of Authentication and Communications Security in Online Banking 61:9 kits are developed as an open platform to be customized by an adversary for a specific target audience [Xxxxxxx 2008; Xxxxxx et al. 2012]. An example of such a malware kit is Zeus, which allows (silent) injection of data in a browser session on a Windows machine [IO Active 2012]*. Such easy customization is currently not possible in the ecosystem of mobile platforms, since banks tend to write their own platform-specific code for each supported mobile operating system. Individual mobile banking application can be written in an insecure manner [Xxxx et al. 2012; Xxxxxxxx et al. 2012; Xxxxxx et al. 2015], but these applications still have an inherent security advantage because the custom code base makes large-scale attacks on multiple banks difficult. These factors slowly start to change in the evolving mobile landscape. It is claimed that the global number of mobile internet users surpassed the number of traditional desktop Internet users in 2014 [Xxxxxxxxxx 2015]*, the popularity of mobile banking is increasing [Board of Governors of the Federal Reserve System 2014]*, and its growth is expected to continue [Cetera 2015]*. Xxxxx have stated that customer loyalty is seen as critical in their mobile strategy. This might be seen as more important than security when it is considered that the latter has been neglected by a large number of banks during the development of their mobile applications [Xxxxxxx 2014]*. The increase in popularity and the existence of vulnerabilities provide new fertile ground for adversaries, taking away the advantage which (1) provides. Banks have been pushing their mobile services quite hard. When mobile banking replaces home banking further, banks could relax the restrictions placed on certain mobile banking functions. This could reduce the advantage that (2) brings. India pro- vides an example where banks gained the freedom to do this. The government had a policy that stated that transactions initiated through mobile banking had an upper limit. This policy was removed to allow individual banks to set limits based on their own risk perception [Srivastava 2013]. In a market where mobile banking is becoming increasingly more popular [Business Standard News 2014]*, banks could be urged to relax their limits.
Appears in 5 contracts
Samples: End User Agreement, End User Agreement, End User Agreement
Security Implications. The future use of standardized web technologies in mobile banking will likely be similar to that of home banking using browsers and websites, but not the same. The similarities and differences allow us to distill some implications. What kept mobile banking relatively safe so far is a number of factors:
(1) Mobile banking is not as popular as home banking [iResearch 2014; Board of Xxxxx- xxxx of the Federal Reserve System 2015; Banking & Payments Federation Ireland 2015]*. It is logical that malware is written for the most popular platform for online banking, since more users equals more possible fraud victims.
(2) Home and mobile banking have an overlap in supported functions. If these func- tions are security critical (such as when transferring money), the mobile banking implementation is sometimes more limited compared to the home banking imple- mentation by the same bank. Some banks in our survey only allow money transfers to previously used account numbers as destinations through mobile banking. Some others do allow first-time transfers to new accounts, but only with an extra authen- tication step or with a limit on the amount of money (which is sometimes adjustable by the user in the home banking environment).
(3) Malware aimed at home banking can be written once and customized for each targeted bank site to allow browser injection and hijacking, a modus operandi known as Man-in-the-Browser [Xxxxx 2010; Xxxxxx and Xxxxxx 2012]. Malware ACM Computing Surveys, Vol. 49, No. 4, Article 61, Publication date: December 2016. A Survey of Authentication and Communications Security in Online Banking 61:9 kits are developed as an open platform to be customized by an adversary for a specific target audience [Xxxxxxx 2008; Xxxxxx et al. 2012]. An example of such a malware kit is Zeus, which allows (silent) injection of data in a browser session on a Windows machine [IO Active 2012]*. Such easy customization is currently not possible in the ecosystem of mobile platforms, since banks tend to write their own platform-specific code for each supported mobile operating system. Individual mobile banking application can be written in an insecure manner [Xxxx et al. 2012; Xxxxxxxx Georgiev et al. 2012; Xxxxxx et al. 2015], but these applications still have an inherent security advantage because the custom code base makes large-scale attacks on multiple banks difficult. These factors slowly start to change in the evolving mobile landscape. It is claimed that the global number of mobile internet users surpassed the number of traditional desktop Internet users in 2014 [Xxxxxxxxxx 2015]*, the popularity of mobile banking is increasing [Board of Governors of the Federal Reserve System 2014]*, and its growth is expected to continue [Cetera 2015]*. Xxxxx have stated that customer loyalty is seen as critical in their mobile strategy. This might be seen as more important than security when it is considered that the latter has been neglected by a large number of banks during the development of their mobile applications [Xxxxxxx 2014]*. The increase in popularity and the existence of vulnerabilities provide new fertile ground for adversaries, taking away the advantage which (1) provides. Banks have been pushing their mobile services quite hard. When mobile banking replaces home banking further, banks could relax the restrictions placed on certain mobile banking functions. This could reduce the advantage that (2) brings. India pro- vides an example where banks gained the freedom to do this. The government had a policy that stated that transactions initiated through mobile banking had an upper limit. This policy was removed to allow individual banks to set limits based on their own risk perception [Srivastava 2013]. In a market where mobile banking is becoming increasingly more popular [Business Standard News 2014]*, banks could be urged to relax their limits.
Appears in 1 contract
Samples: End User Agreement