The study found that wireless carriers use insecure and weak authentication challenges when performing sim swap that can easily be used by attackers for straightforward SIM swap attacks i.e. to steal the mobile identity of the victim. After a successful SIM swap attack, an attacker can easily get access to victims’ social media accounts, bank accounts, other online accounts and services such as cryptocurrency exchanges. Following illustrates one of the scenarios used to perform a sim swap attack.
Besides, researchers managed to reverse-engineer the authentication policies of several popular websites and found that it was quite easy for an attacker to compromise a user’s account on the website provided they have successfully carried out a SIM swap. Some interesting observations,
- Some websites are doubly insecure i.e. SMS-based password recovery tenders SMS MFA completely useless.
- Security is only as good as the weakest link i.e pairing authentication insecure methods with secure options.
- Some websites give users a false sense of security i.e. not notifying users about default SMS MFA method.
This study also provides some concrete yet actionable recommendations for both wireless carriers and websites.
For wireless carriers
To protect their user from the SIM swap attacks, wireless carriers should discontinue insecure methods of customer authentication and replace them with strong authentication methods such as account password, PIN, OTP via SMS or voice call. Carriers should respond to failed authentication attempts by alerting customers. More importantly, limit the information customer support representative can access before the customer has authenticated preferably via back-channels. This is to prevent support representative, intentionally or unintentionally exposing the customer information to the attacker.
To protect their users from the effects of SIM swap attacks, websites should eliminate or discourage SMS-based MFA. Moreover, websites should implement at least one strong MFA option, ideally, Time-based One-time Password (TOTP)or HMAC-based One-time Password algorithm (HOTP) delivered using authenticator apps such as Google Authenticator or Authy.
Websites can also use push notification based authentication as an alternative if the user has already installed their app. More importantly, the website provides should employ threat modeling to identify vulnerabilities in their authentication flows. For instance, some websites use email as login as well as MFA option. This is another example of doubly insecure implementation which can be recognized only after threat modeling is performed.
MFA for financial services
For financial services, we expect by 2021 SMS-based MFA will be completely phased out particularly in Europe and the US. In Europe, the revised Payment Service Directive (PSD2) already requires strong customer authentication and dynamic linking. Payment card networks Visa and Mastercard are also replacing their legacy SMS-based 3D Secure mechanism with a new native app-based 3D Secure 2.0. Still, a large number of banks either don’t use MFA or rely on SMS based MFA (see this list).
How can we help?
As a financial-grade identity and trust management platform, Axioms support the majority of strong and secure MFA options. For instance, our customers have options to activate,
- Time-based One-time Password (TOTP) to use with authenticators
- HMAC-based One-time Password (HOTP) to use with authenticators
- One-time use backup codes saved securely and used occasionally
- Transactional TOTP with dynamic linking of the transaction amount
- In-app pushed TOTP or consent with or without dynamic linking
TOTP and HOTP can be used with any authentication app such as Google Authenticator, Authy, etc. For in-app push notification, we provide native SDKs. We also support email and SMS OTP which we highly discouraged for the same reasons described in this post. As part of authentication, our authorization server also includes additional data and metadata around authentication method used in issued ID tokens and access tokens so that client applications and resource providers can perform progressive authentication if required.