Fraud Prevention for Mobile Apps — Outside of the App: Product Management Case Study
The PM Hierarchy of Needs, according to me. Credit: myself.
Executive Summary/TL;DR
In this case, we were looking at the other side of app-related fraud prevention — possibly fraudulent activities connected to the app, but happening outside of it. This especially relates to logins & accounts being compromised, as well as attempted scamming/phishing attempts.
Introduction
Disclaimer: For the sake of confidentiality and anonymity, all details contained in this case study (especially PII such as names, addresses etc.) are fictitious and don’t contain any details about the respective client. If you’d like to learn more, reach out to me directly.
Going back to my first case study on fraud prevention inside apps, this particular case study considers the second app described — the one involving a user credit-/point-based system.
While we were addressing hardening the app’s UX separately, there’s also fraud potential looming outside of an app — which we had to assess even before public launch.
Problem Statement
Guys who look like this have a 137% chance of scamming your gift cards. Photo by Zanyar Ibrahimon Unsplash
Gift Card Scamming
The above became apparent during the beta testing phase — as we were in the process of collecting beta testers, there were instances of community activities surfacing in which fraudsters were trying to impersonate the client’s employees, offering early access as well as in-app points.
Following up on these fake accounts and links, we found a common scam — trying to get the victims to send them money (mostly via gift cards), and then of course not delivering the promised commodity.
Gift card scams are huge — in the US, nearly $110 million were lost to gift card scams, in the first half of 2023 alone.
It usually starts via DM within a forum, Discord server or similar:
Users would be approached by scammers telling them they’d won beta access or a first look at in-app points, for which they’d have to pay…
…by sending over details to redeem a certain gift card amount from any big brand that are available at a lot of retail stores or can easily be purchased online.
You’ve probably gotten one from a family member or friend before, with some assigned value (e.g. $20 or $50) and a redemption code. Photo by Manuel Cosentino on Unsplash
As Irina Maltseva points out in her comprehensive primer on gift card scams, there are a number of reasons why gift cards are used in scams.
However the main one would be that gift cards often can’t be refunded, traced, or disputed.
Even if scammers have to ‘convert’ the gift card value by using the store credit to buy something and later sell that purchase for cash, or sell the store credit to someone else ‘for nickels on the dime’, they can still recoup 50–70% of the ‘original transaction value’ — anonymously and barely-to-untraceable.
If you’re interested in gift card & tech support scams, Jim Browning has an excellent YouTube channel with very entertaining cases of ‘scamming back at scammers’ — highly recommended.
Login & Account Credential Phishing
Unfortunately unrelated to the 80’s prog rock band with a similar name, as well as the indulgent ice cream flavor by a brand with 2 common male first names based on it. Photo by Bermix Studio on Unsplash
As we noticed that these scamming tactics were being used in community environments, we also noticed phishing attempts to collect user credentials:
mostly by claims to sign up for fake “waitlists”, for which attackers would store the credentials,
and then, assuming that users would later sign up with the exact same credentials for the actual app, hijack their accounts.
As apps also usually have a login screen & feature (of course), this may be considered an in- and out-of-app attack vector; however, especially in circumstances in which logging in or participating in a service does not exclusively happen via app (i.e. desktop versions, community accounts on other services), logins and account credentials can definitely — especially — be attacked from outside the app.
The problem again started with fake accounts and users impersonating company reps sending users to fake versions of existing waitlist pages.
This is more commonly known among banking websites, where fraudsters craft — sometimes pretty convincing-looking — fake login interfaces to grab credentials, use them to gain unauthorized access and steal money.
Feel free to check out the examples below — some of them are quite authentic-looking. Maybe not to you — but maybe to your parents?
How does that relate to Product Management, though?
Photo by Toa Heftiba on Unsplash
If you’ve read up to here, you might think — isn’t this a cybersecurity specialist’s job? (Primarily, yes) And — as a product manager, do I really need to care? (Also, most definitely yes)
As outlined in the highly scientific PM Hierarchy of Needs shared at the outset, security is absolutely foundational to not only your product’s success, but even your product properly working.
Here it is again, for reference. Credit: still myself.
If your product’s security is compromised, your north stars are long gone.
But it’s not just about awareness and accountability — oftentimes, especially concerning product-related vulnerabilities, product managers can also prevent or curb malicious activity, so as a product manager, you may well also need to be part of the solution.
Solution
As an adequate segue — here’s what we did to address the aforementioned threats:
Hardening of Community & Communication Infrastructure
Photo by Jonathan Kemper on Unsplash
Especially in ‘third-party communication channels’ (i.e. Discord, Reddit, Facebook Groups etc.), there’s unfortunately no way that one may assume control of community activity to a degree of making fraudulent activity impossible.
Accordingly, the best one can do is:
First of all, educate your community. This is basic, but important! Let them know how to discern real from fraudulent activity. Your bank has probably informed you many times that they’ll never ask for your PIN or password on the phone or via email — if you’ve understood that, count it as a success.
In order to do so, you also need to make sure to provide ways for users to verify and/or report suspicious activity— as an example, setting up dedicated news sections on your website/app and linking to that over posting images or text in groups or communities, and an email address for reporting suspected fraud cases.
Just because you often can’t entirely own a group or forum doesn’t mean that you should still exercise the maximum amount of control that is at your disposition: have moderators comb through the forum and delete/report fraudulent posts or accounts, assume administrative control of your group, and if the platform allows for display of e.g. ‘Admin’ or ‘Moderator’ badges next to (legitimate) accounts, make use of those as well.
You’ll unfortunately never be able to get ahead of scammers forever — it’s a constant effort. But by using a mix of preventative (such as user education) and deterrent (such as blocking/banning of fake accounts) measures, you can stay on top of what’s happening.
Hardening the Login & Account Credentials
Merely offering single-factor authentication (i.e. username and password) would be at too great of a risk of being compromised based on the fraud attempts, so the most obvious change we could make was to introduce two-factor authentication (2FA).
By requiring a one-time-password (OTP) via SMS for logging into the app, efforts of (re-)using the harvested credentials would be thwarted — even if a scammer would be able to provide a (stolen) valid user name & password combination, the OTP would be sent to the legitimate user’s phone.
Implementing an OTP solution wasn’t even that difficult, there’s a couple of low-cost or (partially) free solutions, such as this one:
At that time, SMS toll fraud wasn’t on our radar yet — but that’s of course another issue to be aware of when using an SMS-based authentication solution:
As for the logins to third-party communities and forums, we again didn’t have control over those. We did however urge community members to use different credentials for the app and for their social platforms (e.g. Discord, Reddit etc.) to contain an effect of a potential breach of either one of the accounts – as you might know, large tech companies’ data also gets breached and stolen…
…and then there’s also no guarantee that they’ll fix related issues for you.
Results
In short, we managed to launch without any substantial or successful attempts at defrauding the platform or its users.
But what’s even better is that upon the community outreach and education efforts, the community would actively participate in identifying, reporting and ultimately foiling further scamming attempts — to be honest, I saw it as a huge success that we were able to make the community care, be engaged, and look out for each other.
Conclusion
Ultimately, I’ll leave you with this:
Before you release to any audience, consider how that audience may misuse your product. Obviously, it makes sense to gatekeep at the beginning, by way of a beta program, waitlist etc. — but even that won’t make you immune to threats.
Using third-party infrastructure always carries a liability. Make sure you’ve done your risk assessment! This especially applies to anything cloud-hosted — make sure that you’ve got redundant components for critical functionalities, and try to self-host or own/whitelist anything critical. As a small example, I always post my blog articles on my own website at www.bertrandrothen.com first — in case Medium goes down, or decides to do something odd…you never know for sure.
When in doubt, use 2FA/MFA. What used to be a conversion/usage obstacle has become pretty common for users (thanks to PSD2 and the likes), and it does prevent quite a high amount of low-level attempts to scam your stuff.
Thank you very much for reading!
If you’d like me to help you with a similar challenge you’re facing, I’m a Freelance Product Manager & Consultant for hire — feel free to reach out to me at hi[@]bertrandrothen.com