Take your Rails development to the next level
Prevent account sharing with MFA
- Why to prevent sharing account
- Prevent account sharing with a third-party service
- Our path to a solution for preventing account sharing
- Solution #1: logs analysis
- Solution #2: unique token per device written in cookies
- Solution #3: login session concept
- Solution #4: device limit, limit of login sessions
- Our results, analysis, and reports
- Summary
TL;DR: MFA increased our app new signups by 30% daily. It can help you but measure the impact of the changes.
Preventing account sharing in your app is vital. Various methods tackle this. Recently, we’ve been focusing on the issue. We discovered a simple, low-risk solution. It protects revenue and boosts security. It assists in generating dynamic reports. This solution allows us track data. It helps to manage violation cases. Look how we have achieved this.
Why to prevent sharing account
Sharing an account is one of the backdoors that leads to financial losses. Instead of having paid two users who are friends in your app, you have only one. They buy one account and share credentials, resulting in underpaying the business.
Another aspect of preventing sharing accounts is security. Someone might steal a user’s credentials. The thief will use the account, and nobody will know about it.
All of that is very important indeed. However, our primary goal was to boost app revenue.
Prevent account sharing with a third-party service
Some services promise to solve the issue with account sharing in your product. That option might sound like a good choice. Relying on their implementation, you sign up. Then, you configure your app by following their instructions and enjoying it. Sounds easy and fantastic. Yet, some disadvantages can prevent you from following this path.
To start, consider how these services tackle the problem. They track user actions. These include clicks, mouse movements, IP addresses, device types, and locations. If the user’s behavior deviates from the norm, the service flags it as suspicious. While effective, there are limitations to this approach. It hinges on a vast amount of user data. The more data and users they have, the more accurate the service becomes. The law of large numbers must function. But you never know if they have enough data. They also need to know your app data and users. Hence, the conclusions about sharing an account might be wrong. In the end, remember that there will always be false positives. It’s essential to have a plan to address them.
This solution takes time to set up and integrate. Dealing with false positives is challenging. You need custom logic to link this service to your app. You lose control over valuable data to improve your product. Also, there’s a fee that may not suit long-term needs. Comparing it to your solution is necessary.
We aimed for user session control, limiting per-user sessions. Account sharing was still possible. The system permitted a fixed number of simultaneous sessions. A user accessing the app on various devices led us here. Working with a third-party service brought obstacles here. Thus, we chose to drop this method.
Our path to a solution for preventing account sharing
As the first step, many recommend using multi-factor authentication (MFA) and stopping there. Indeed, it’s an excellent option to consider. We definitely should implement it. Yet, how can we be sure it helps? How can we prevent user loss after enabling MFA? Each app community is different. Their expectations may vary. Enabling MFA for all for no reason could alienate many users. They may leave the app, hurting the business.
Hence, we need indicators to track the impact of our changes on user behavior. Yet, we must decide who gets MFA enabled and assess whether account-sharing prevention works. Thus, an imaginary “violations per user” is a crucial indicator to track. Ultimately, it aligns with login sessions per user—the fewer active login sessions a user has, the fewer violations. If all goes well, the “violations per user” indicator should drop after enabling MFA. Additionally, we expect more users to sign up. Some users using the shared account should eventually sign up for the app. Moreover, the number of active users should not drop. If all that happens, that would mean the feature works well and improves things rather than hurting the business.
We can easily track the number of new signups and the number of active users without changing the app. Having direct access to the database, we can do that with relatively easy SQL queries.
However, we do not have data for the “violations per user” indicator. Thus, we should implement a solution for that.
Thinking this way, we come up with the following initial ideas:
- Analyze the user agent’s IP and device type in the web server logs. Create a report of suspicious user actions such as often IP change or device type.
- Then, if every subsequent request differs from what’s inside the cookies, it’s a violation.
- After analyzing these reports, come up with an idea of who should have MFA enabled. Eventually, implement MFA for them.
Solution #1: logs analysis
Looking into logs and checking how many unique IPs and devices one user uses is a natural solution that comes to mind. We have implemented it. However, this solution did not derive a “sharing account violations” indicator. The story behind this deserves a separate post. In short, it was a challenging task. Based on this data, we’ve had many false positive reports. This is a challenge for us and giants like Google, LastPass, and even your local banks. For that reason, you get a lot of irritating emails every time you log in to these services. I do, and I have it. Our users could hate it as well. A more straightforward solution should correctly identify the fact of sharing accounts.
Solution #2: unique token per device written in cookies
If we have to limit the users’ login sessions, we could restrict them by device type. We can issue a unique token per user device and store it in the DB along with other important information such as IP and the user agent (device info). The idea was to allow one user to use only one device of a specific type at a time. For example, one user can use one web login on a desktop and one on a mobile app. If someone else uses the same device type at the time, it’s a violation. We successfully implemented this solution, and in fact, it worked well. There were some false positives. But fewer than in the previous solution. We could even stick with this solution. However, the business changed its mind and allowed a limited number of login sessions, independent of the device type.
Nevertheless, even though it’s been rejected, this solution can still be used to implement the “sharing account violations” indicator. We use it to collect and analyze reports.
Solution #3: login session concept
Using the experience of the previous solution, we implemented a modernized version that elaborated into a login session concept. The idea is the following. One user can have many login sessions. A login session is an entity with a unique token. It’s created right after the user’s login and deactivated after the user logs out. This unique token is injected into cookies. We search for an active login session in every subsequent request and create if it still needs to be added. A user with many such login sessions shares an account. And for them, we should enable MFA.
Solution #4: device limit, limit of login sessions
Having the previous solution ready, we can limit the login sessions in the following way: Every time a user logs in, check if the number of login sessions is too big, say 4. If that’s the case, prevent the user from going further and ask them to log in from some of the current login sessions. This is what we are implementing next.
Our results, analysis, and reports
Now, we have the indicator that shows the dynamic of account sharing violations. We gradually enable MFA for those users with the most violations and check the following dynamics.
New signups and active users on a paid plan. Note that it includes users on a trial that lasts for 15 days. That’s why there is this peak on the right side:
Sharing token reports dynamics:
The report dynamics are based on log analysis. It turned out to be useless, and for that reason, we will drop it:
Active login sessions per user with MFA enabled:
Active login sessions per user with MFA disabled:
Active login sessions for all users regardless of the MFA toggle. This one has the data combined with the 2 previous charts:
Looking into these charts, we conclude that:
- The number of new paying signups increases. Roughly 30% more new signups daily.
- The number of sharing account reports based on the token solution decreases. The regression line predicts a drop from 170 points to 120, almost a 30% drop when IP and device differ.
- The number of login sessions per user decreases for users with MFA enabled. This improvement is significant compared to users with MFA disabled.
Summary
In this post, you learned how the positive impact of MFA enabling in your project can be measured. Now, you know which metrics inside your app you should watch for to understand if your solution works and helps the business survive.
Finally, you got a beneficial insight — MFA positively impacts user behavior. It indeed prevents users from sharing accounts. The improvement is significant — roughly 30% more new signups. Additionally, it’s a security improvement for your app. It is worth considering for your project. But keep in mind that your auditory can be different, so measure the impact.
In the next step, we will implement the login session limits. We expect an even more positive impact and will measure the results. Stay tuned!
Follow me on social networks not to miss the next post: