Limiting account misuse
Account sharing for B2B publishers – part 2
So, you’ve identified that account sharing is a problem for your business. What do you do about it?
There are two distinct strategies here:
- You can actively make it harder to share accounts; or
- You can passively track the users who share their accounts, then use that data to sell more seats to the customer.
Prevention of account sharing also splits into two:
- Using authentication techniques that only the real account holder can log in with; or
- Limiting devices or sessions.
A quick crash course in authentication… When someone authenticates (logs in) they are presenting you with:
- Something only they know (like a password, PIN, etc.);
- Something they are (i.e. biometric data like a fingerprint); or
- Something they possess (such as a phone, which can receive a token by SMS).
- I would also include something they have access to (like an email inbox) in the last category.
The de facto (although it’s slowly changing) method for logging in to a Web site is a password. If you don’t want someone to access your online banking you set a strong password and keep it secret. But here’s the problem: if you do want to let someone else access your account (i.e. account sharing) then you can just set a weak password and tell them what it is. The responsibility for keeping others out is with the user not the vendor.
That problem is pretty hard to get around in the “something they know” family, because knowledge can be shared. If you want to actively prevent account sharing you need to leverage one of the other two systems.
Side note: this post is not particularly discussing 2-factor authentication (2FA) or multi-factor authentication (MFA) but, in a nutshell, those systems are asking for multiple authentication techniques. They do not necessarily state which techniques but it’s often a password + a token by SMS.
Authenticating someone using “something they are” is definitely an area to watch keenly. If you primarily deliver content through native apps it’s pretty easy to leverage in-device biometrics today. On the Web it’s harder as you are targeting a multitude of devices with different biometric capabilities. That said, standards are being created to work with password-less authentication, in particular the Credential Management API which allows you to use fingerprint sensors on Mac OS and Android (if the device supports them). If you want to invest early, then definitely look into these techniques and offer them for users who have a supported device. The big challenge is that you’ll probably need to support passwords too, for the foreseeable future, so a user who wants to share their account can just elect to use a password instead of their fingerprint.
So what about “something they possess”? There are a bunch of low-hanging fruit here. It’s often impractical to send a user a physical device (like an RSA key), so I’ll focus on things they already own like SIM cards (that receive SMS message), email inboxes and social media accounts. To leverage any of these authentication schemes you need to send a token using that channel that only the true owner can pick up; for social media this is codified as OAuth2.0 (it’s a similar effect, at least) but for the other two you’ll need an Identity Management tool that supports them.
The flow goes like this:
- To log in, the user enters their email address or phone number
- A single-use token is sent to them by email or SMS
- They enter the token on-site or in-app to authenticate
Only the owner of the inbox or device has access to that token, so only they can log in. The user can still abuse this system by forwarding on the token but, crucially, they need to be an active participant in every single log in. Unlike password-based account sharing, where the user told their peer the password once and they then have access forever-forward, they will now need to forward on the token every time the piggyback user logs in.
If you use a “something you own” scheme, you can push account sharing further down the long tail by imposing a limit on concurrent sessions. Given that a user is only allowed to be logged in from one device at a time, and two users are trying to use your service, they will each need to log in every session – always by passing on a token from one to the other. That is such a jarring experience (and clearly tied to their illicit behaviour) that there’s a real drive to either not share or, if the value is high enough, to buy another licence.
Of course you can use this system with any means of delivery that the user would feel uncomfortable sharing. They would share a password – they wouldn’t give someone access to their inbox, their SMSs or their Facebook account.
You can limit the number of devices that a customer can use to access your service by either setting a maximum number of concurrent session or by restricting the user to named devices.
Named devices are perfect for high value content. Typically, device management is used only with native apps not on the Web. Limitations of the Web mean that device’s “name” can only be pinned to a session, local storage or a device fingerprint. Sessions and local storage (unlike on a native app) are highly transient and becoming more so: cookie can be deleted, “incognito” session are used, corporations routinely clear data from their employee’s browsers.
How about pinning the “name” to a device fingerprint? That is an interesting approach but not perfect. The system works as follows:
- A user authenticates using any scheme (let’s say a password)
- In the background, a hash is created of static information we know about the device, like the operating system (OS), the browser, the screen size and maybe fonts and browser extensions
- They are asked to name their device (“Work laptop”)
- An identity management system stores the hash and name against the user
- Subsequently, if the user logs in from a device with the same hash, they are considered to be using the “Work laptop”
- If the user (or a piggyback user) logs in from a device with a different hash then they are asked to manage their devices.
There is a real problem with this approach, however… static data is so generic it’s not useful. Consider the OS. If a visitor users a Mac then that part of the hash is the same for every other mac user. You can’t really use data such as browser version because the “device” will change every time someone’s browser is updated: it’s not static data.
Building an effective fingerprint is hard, to the point that it cannot really work standalone. But this might be a useful technique to deploy in conjunction with other tactics, such as “something you have” authentication.
For the Web, the simplest way to limit devices is a concurrent session limit. This is similar to the flow for named devices but it’s completely opaque to the user. If you allow 2 concurrent sessions, and the user logs in from a third browser, then the oldest session in deleted. The user cannot choose which session is deleted, because they are unnamed. Again, this is not going to stop account misuse but it will require bad actors to log in more frequently, so could be coupled with a password-less authentication scheme.
It’s definitely useful leverage, when trying to negotiate an increase at renewal time, if you can categorically prove that the customer has bought 10 seats but 30 of their employees use the service. Be aware that you need users to abuse their accounts to get that benefit, so don’t rush block account sharing.
There are a number of metrics you can track to get an indicator of account sharing. All publishers of high-value B2B content absolutely need to report on concurrent sessions – that’s the low hanging fruit – but you can also look at unique IP addresses per user and other dimensions that are likely to be small for a real user. Building these kinds of report is usually pretty straight forward (and was covered in the previous post) but know that it will need to be based upon server log data or your IAM’s reporting if you want to see IP addresses.
The pay off
At Zephr, we have seen B2B publishers tackle the issue of account sharing head on. It’s really not that hard to go from it being trivially easy for a user to abuse their licence to it being quite difficult and explicitly fraudulent. We have seen huge revenue uplifts attributed to these drives and prove a bunch of tools for the publisher to leverage.
This is never going to be one-size-fits-all but being conscious of the cost of the problem is essential. And know that there are things you can do to deter this behaviour.