July 8, 2019

Lessons from Japan: Preventing Account Takeover through App Security

Retail Account takeover prevention in Japan - Build38


Lessons from Japan: Preventing Account Takeover through App Security

Recently, it has appeared on the news that one of the largest convenience store chains in Japan, that uses a mobile wallet in order to perform payments associated to a credit card, has suffered an attack that ended up in the total loss of 55 Million Yen by almost 1,000 users. Based on public information, it is believed the attack was based on an account takeover scheme. The attacker started a password recovery process that ended up in sending an email with a password reset link.

Apparently, the process was implemented in a way that the user had the option to send the reset link to an alternative email address than the one that was originally used to sign for the account. This is a very strange practice as generally when resetting your password you use some element as the original root-of-trust (the original email address) but in this case it seems that they were using some very basic information like birth date as the root-of-trust.

Even if there is no evidence that the Mobile App was compromised and if additional countermeasures would have prevented the attack, the question here is: Can we design a password reset mechanism that can overcome the flaws of current methods? Beside this particular news, we have heard of many cases of account takeovers by attackers using SIM Card replacement mechanisms, where the Service Provider has to rely on the Mobile Network Operator / Carrier of the user to do the right verification before providing a SIM Card replacement.

Solving the issue: What if the Service Provider didn’t have to rely on third parties for that?

That brings us to an improved flow for the password recovery mechanism. Imagine you have a Mobile Wallet that you use to make purchases and you have a Mobile App in your phone, protected by some kind of user verification, e.g. Fingerprint or FaceID. One day, you want to access your account from a website. Or you are asked to login again and you forgot your account password. In a current scenario, the user would request a password reset and a link would be sent to their Email that once clicked would be used to set a new password. An alternative would be an SMS to their phone number with the link or a code for the password reset.

In the improved scenario, the Mobile App on the phone is strongly linked to it. This means that it can’t be copied to a different phone, the keys stored can’t be compromised or the communication sniffed. We also don’t have any need to rely on an SMS, whose phone number may have been compromised by poor carrier KYC mechanisms to get a SIM Replacement, or Emails that may be have compromised in multiple ways. This would work as follows: I want to login through the website but I can’t remember my password. I click on recover password. The user is asked through the website to open their app on the phone, do user verification, e.g. Fingerprint, and once is verified the possibility to define a new password is shown on the website. In the case of someone trying to take over the account, once they request the reset password link they will not get through as the real user is not going to open the app and accept the reset of the account.

Actually, such a flow would go in the direction of the Payments Japan Association guidelines that “requires the operators of mobile payment services to confirm the linkage between the devices of users and apps downloaded on them to prevent unauthorized access.”

In the case that the user forgets the password and loses access to their phone at the same time, a specific “Red” path for the user verification shall be established. The good thing is that in this scenario, if an attacker is pretending to have lost their phone and forgot the password of the user, the actual user could be alerted of this happening though a warning to the App on the legit mobile device, being able to inform the Service Provider that they have not initiated such a process and alerting the Service Provider that an attack is happening.

Thus, using a strong device binding and a hardened app we can solve many of the risks associated with online account takeovers. Build38, through its family of technologies under the Trusted Application Kit (T.A.K) is able to make Service Providers independent of security processes of others, e.g. Mobile Network Operators / Carriers, Email and ISP providers.

Related posts

Discover the next generation 
of mobile app security