Andrei Kaleshka's wroclove.rb 2024 talk (his first English-language talk) on fighting credential sharing in a Ruby on Rails music-education application that sells classes for musicians. Frames account sharing as a revenue problem (paying members letting friends/family reuse credentials) and surveys possible countermeasures: third-party device-identification services like Fingerprint (rejected for data-ownership and integration cost), analyzing IP/user-agent/location logs (attempted, not precise enough), and multi-factor authentication. Because turning MFA on for everyone is risky (user distraction, churn), the team first built a 'scaffolding' of data and indicators: signups per day, user retention, login sessions per user, and Stripe revenue. Implementation details: installed paper_trail to collect historical data; introduced a login_sessions table whose id is injected into the cookie session and validated via Devise's warden hooks (record_login on after_login; maybe_logout on current_user to expire stale sessions; maybe_logout_mfa for users who should pass MFA; expire on after_logout). iOS app uses devise_token_authenticatable while the browser uses a custom UUID login-session concept. Login-session records also capture CloudFront request headers (IP, geo, latitude/longitude) — though location data in practice is unreliable. Multi-factor authentication was implemented with the devise-two-factor gem using email codes (no phone numbers were available) and a 30-day remember-cookie. MFA is enabled weekly for users that violate the rule (4+ active login sessions, detected via a SQL query) rather than for everyone. Analysis and charts are built in Metabase (Docker setup, custom SQL). Results over the rollout: login sessions per user trended down, total logins kept growing, retention looked healthy, and signups gained ~27% on the regression line (with caveats — organic search also grew). Next planned step: hard cap of 4 concurrent login sessions per user, prompting users to choose which one to expire on the 5th login. Q&A covers why 4 (multiple device types plus an upcoming React Native app; also a business-client request; accepts they can't stop sharing 100%), how MFA enablement is automated (SQL query on login_sessions counts), whether shared cookies are defended against (no), why MFA is email-only rather than authenticator app or SMS (no phone numbers; minimize user friction to avoid churn), whether users just create new shared email accounts (not yet analyzed via logs), and what the app is (music-education courses for musicians).