Ruby on Rails

Summarized using AI

Prevent Account Sharing

Andrei Kaleshka • April 12, 2024 • Wrocław, Poland

In the talk titled "Prevent Account Sharing," presented by Andrei Kaleshka at the wroc_love.rb 2024 event, the focus is on addressing the challenges of account sharing, particularly in the context of user authentication in applications. Kaleshka begins by sharing a personal anecdote from his school days, illustrating the difficulties of sharing limited resources, which parallels the issues faced with account sharing today. He identifies two main problems: credential theft and unauthorized account sharing among friends and family.

Key points discussed include:
- Initial Challenges: Account sharing leads to security issues and revenue loss, prompting the need for a solution that balances user experience and security.
- Solution Exploration: Kaleshka explores various methods, including third-party fingerprint authentication, IP address analysis, and logs, ultimately finding them complex and insufficient.
- Multi-Factor Authentication (MFA): He proposes implementing MFA but acknowledges user resistance due to potential login complications. A data-driven approach is employed to analyze the impacts of MFA before broad implementation.
- Data Collection: The team establishes a strategy to track key indicators, such as sign-ups, user retention, and session counts, using tools like the Paper Trail gem for data logging and Metabase for visualization.
- Results of Implementation: Initial findings indicate an increase in login sessions per user, coupled with a decline for users flagged for MFA, suggesting some success in curbing account sharing.
- Future Plans: The application plans to limit active user sessions to four to manage account sharing while enhancing user engagement through data analysis.
- Conclusion: Kaleshka asserts that while MFA implementation improved security significantly, further investigation is needed to understand user behaviors thoroughly.

In conclusion, the presentation emphasizes the importance of defining clear indicators to assess the impact of new security measures and the necessity of maintaining a user-friendly experience. Ultimately, proper implementation of MFA can bolster application security and revenue health, while the journey remains ongoing as the team navigates the complexities of user behavior and session management.

Prevent Account Sharing
Andrei Kaleshka • April 12, 2024 • Wrocław, Poland

wroclove.rb 2024

00:00:09.160 And thanks everyone for coming to this talk today. This is my first English talk.
00:00:15.599 I hope it will be good and that you enjoy it. Thank you.
00:00:21.359 Okay, let's start.
00:00:26.840 I remember being at school, where we had ten computers for the class and only one of them was working. We had ten students in the class, and we had to share that one computer somehow.
00:00:40.160 So, it was definitely a problem. Nowadays, it's not an issue at all, but there were times when it was a significant challenge.
00:00:46.800 The account sharing that I will talk about today involves the credentials you share with your friends, family members, and others when you buy an application to share it with everyone.
00:01:06.119 This presents two cases: one is when someone steals your credentials and uses your account while you're paying for it.
00:01:12.280 This is obviously a security problem, but companies often don't view it as such. They usually focus on revenue because improving revenue is the primary goal of every commercial organization.
00:01:24.600 In our application, we faced similar issues where some users were sharing their credentials. Observing how revenue was dropping, we recognized there was a problem and that we needed to address it.
00:01:58.000 I personally don't favor very complex solutions. When facing a problem, I try to analyze available options and stick with the simplest solution that sufficiently meets our needs.
00:02:17.720 There are various approaches to address the problems I mentioned earlier. First of all, there are third-party solutions, such as using a fingerprint authentication service.
00:02:31.959 With such services, you can rely on their solutions. However, you don't own the data and can't analyze it fully, which is a significant drawback.
00:02:44.720 Other solutions include analyzing logs, looking into IP addresses, user agents, and additional location information. We tried to implement these solutions but found them complicated.
00:03:14.640 Moreover, we couldn't find a 100% precise solution that would work for us. Therefore, we abandoned this approach.
00:03:23.000 We then came across an article suggesting that multi-factor authentication could improve the situation. It seemed like a good idea, so we enabled multi-factor authentication for our users.
00:03:44.160 However, this creates complications during login, and we need to consider how much this solution would actually benefit users.
00:03:57.240 It's a valid question: If we implement this solution for everyone, would it genuinely improve the situation? There is a risk that users might not appreciate this requirement and might leave the application.
00:04:07.759 These are the challenges we faced while trying to implement multi-factor authentication.
00:04:18.000 So how do we understand whether enabling multi-factor authentication in our application improves the situation or makes it worse? This is the question we aimed to solve.
00:04:41.640 In the construction business, there's a concept of scaffolding. Before starting a project, they build scaffolding around which they construct buildings.
00:05:01.560 When faced with a similar project in the IT sector, we realized we didn't have sufficient data at the start to prove whether implementing multi-factor authentication would yield better results.
00:05:18.159 Thus, we came up with a plan: first, we would collect data, then identify indicators that would tell us whether the situation was improving or declining.
00:05:36.440 Then, we planned to enable multi-factor authentication only for those users who definitely shared their accounts.
00:05:55.680 This way, we could differentiate the risks when implementing this potentially beneficial solution.
00:06:03.840 The indicators we identified included the number of sign-ups per day over various periods, user retention, and the number of login sessions per user.
00:06:22.400 Initially, we did not have detailed data in our application regarding user sessions, which hindered our understanding of who was sharing an account.
00:06:38.560 We also monitored revenue through Stripe, anticipating that it wouldn't decrease further.
00:06:58.200 Our expectation was that while the number of login sessions per user would drop, all other indicators should ideally show an improvement.
00:07:19.200 To collect data, we initially relied on the Paper Trail gem, which can be easily integrated into existing Ruby on Rails applications.
00:07:40.560 Another approach could have been to implement event sourcing. If we had included this feature from the beginning, it would have simplified our data collection process.
00:07:57.680 However, since we didn't have that, we opted for Paper Trail instead, as it seemed practical for our needs.
00:08:17.680 Next, we created a login sessions table, a model that represents each login session. The idea is to create a record in our database every time a user logs in.
00:08:35.280 This allows us to identify the active session for every user, as the ID comes with every request following their login.
00:09:02.600 Next, we needed to analyze the data we collected. We wanted to represent it in a clear and straightforward manner to understand whether the situation was improving or declining.
00:09:30.440 For this analysis, we used Metabase, which allowed us to visualize data through charts and numbers.
00:09:46.760 Metabase is an excellent tool, and it's fairly easy to set up, especially with Docker, which can take around five minutes to install and configure.
00:10:05.600 After implementing our solution, we examined the results. Initially, the number of login sessions per user increased, observable through average sessions per user.
00:10:34.320 As we progressively enabled multi-factor authentication for users who violated our rules, we noted a decline in login sessions per user.
00:10:49.840 In November, we observed this decrease, indicating that the number of logins was slowly dropping.
00:11:05.600 To prepare the data for analysis, we had to write custom SQL queries. Without SQL, charting our results would have been challenging.
00:11:22.400 This situation illustrates that there will always be users who do not share accounts, so we don't need to enforce multi-factor authentication for them.
00:12:00.600 The overall user engagement also improved, as illustrated by the total number of login sessions increasing.
00:12:28.320 We also monitored user retention, showcasing the number of active users remaining on specific days.
00:12:48.720 This data demonstrates that while some users drop off quickly, others stick around for a longer time. Thus, the overall trend appears to be positive.
00:13:05.960 We anticipated that the number of daily sign-ups would increase, yet the data shows a more fluctuating trend.
00:13:20.320 In December, we observed a dip in sales activity, but overall, signs indicated improvement. Drawing a regression line illustrated a notable gain of approximately 27% after implementing this solution.
00:13:48.240 So, we can conclude that multi-factor authentication indeed improves account security and reduces sharing, resulting in increased sign-ups.
00:14:03.120 Although other factors, like organic search, were simultaneously increasing, we couldn't attribute specific impacts solely to multi-factor authentication.
00:14:31.520 However, our data indicated that the situation was improving significantly.
00:14:47.040 In our future plans, we aim to limit the number of active sessions per user to a maximum of four. When users exceed this limit, they will see a prompt to choose which session to expire.
00:15:00.560 Essentially, we believe that we can achieve a fair balance and resolve the problem of account sharing adequately.
00:15:25.760 Our success story emphasizes how multi-factor authentication can positively impact the health of an application.
00:15:43.920 The takeaways include: when faced with implementation challenges, take time to define indicators that will measure the impact of your actions.
00:16:02.320 Analyze available data and ensure you have the skills to interpret it effectively.
00:16:25.680 If you have any questions, thank you for your attention! I'm ready to answer.
00:16:57.160 I have a question: why did you decide on the limit of four concurrent sessions? That number seems adequate for sharing an account among friends or family.
00:17:18.240 It's important to note that our application is used across different devices, and businesses specified this number. Additionally, the historical data showed that users rarely exceeded using four devices.
00:17:48.639 While we can't completely solve the issue, limiting it to four sessions seemed reasonable.
00:18:05.960 For users sharing their credentials, we implement additional measures. To identify which users should have multi-factor authentication enabled, we defined specific rules.
00:18:28.960 If a user has four or more active login sessions, we automatically enable MFA for them.
00:18:46.440 I have another question related to sharing credentials in the form of cookies. Do you protect against users sharing cookies?
00:19:07.760 Currently, we do not have protections in place against that type of sharing.
00:19:27.440 Another question: could you explain why MFA options, such as using a second device or an authenticator application, were not deemed suitable?
00:19:49.440 We aimed to implement solutions that minimize user disruptions, and we lacked user phone numbers to send codes. An authenticator app would require additional steps from users.
00:20:03.840 We prioritized simplicity to maintain the user experience while still improving security.
00:20:19.920 Thank you for your insightful presentation! However, do you track if users create new accounts intentionally to bypass session limitations?
00:20:39.600 We have not analyzed this behavior through logs yet, but we should consider addressing it.
00:20:57.920 Our main objective is to stop revenue from dropping, and for now, we are satisfied with that.
00:21:11.840 We have time for just one more question.
00:21:22.480 What does your application do?
00:21:39.760 It's an educational application for musicians, selling various classes and courses.
00:21:57.920 Thank you, Andrei, for addressing our questions! Let's give a big round of applause for our first speaker.
Explore all talks recorded at wroclove.rb 2024
+6