Below is a proposal for dealing with a situation of website security. I am wondering whether it seems feasible, from both a technical and usability point of view. I want to make sure that the proposal does contain any glaring errors.

  1. The website

The website in question is a school website where students may purchase various items. These students get an account on the website with a username and password, which they can use to login. Once they login, they have access to protected pages with private content which are unavailable to the public at large.

  1. The security concern

The owners of the website wish to prevent a situation where a single student signs up on the website, obtains a username and password, and then circulates those credentials to a circle of friends who are then able to login to the website and illegally view the private content.

  1. The solution

The central idea we have come up with to deal with this security problem is to permit each student to login to the website on two devices only. Once a student logs in on two different devices, they are restricted to those two devices. If they then attempt to login on a third device, the system would simply not permit them to do so. It is our understanding that other websites offering private content, such as Netflix, use such an approach.

  1. Implementation

Two ideas come to mind to implement the above security measure: IP address and cookies. We rule out IP addresses which can change, and choose cookies. Websites such as allow their customers to login once, and then whenever they return to the website, they are always recognized. This is almost certainly achieved through cookies.

Thus each time a student logs in, we will store on their device a cookie. And we will also store this cookie in our database under that student's account. Thus each time a student logs in on any device, we will check whether the device they are currently logging in on contains the cookie we have stored for that student. If it does not, we will know that the student is logging in on a different device. We will thus be able to know how many devices the student is trying to login on.

  1. Drawbacks

We have identified at least three possible drawbacks to this approach:

  • Clearing cookies. People can, for a variety of reasons, choose to clear the cookies from their computer.
  • A bona fide person may occasionally not have access to their usual device, and wish to login on a different computer.
  • People do purchase new devices from time to time.
  • These are examples of situations where a bona fide user, for legitimate reasons, wishes to login, but will be unable to, due to the website's security restriction of two devices.

We have some ideas as to how to build logic into the system to deal with such situations, which we may implement in the future, but for the time being, we feel that such situations are sufficiently rare that we do not need to handle them programmatically.

Rather, for now, in the event that a student is locked out, they will get a screen with a message explaining why we have not allowed them into the system, and a button which they can click on which will automatically generate an email to the site administrators.

The email will inform them that a student wishes to login on a third device. The administrators can then contact the student, and if they are satisfied that the need is bona fide they will be able to take steps from the CMS to allow that student in.

The size of the student body is sufficiently manageable that the above approach should be feasible.

  1. Fair warning

We will inform the students of these security measures when their account is activated in order to prevent unpleasant surprises.

closed as unclear what you're asking by Xander, Iszi, Deer Hunter, Adi, StackzOfZtuff Nov 18 '15 at 10:59

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 11
    What about copying the cookie value? i.e. student a gives their cookie value to student b. Would that allow student b to access the service? – Jay Nov 16 '15 at 8:37
  • 44
    What is your question ? – Stephane Nov 16 '15 at 8:38
  • 16
    If the user is voluntary sharing the login information so that his friends gets access to the private content the user will also be able to simple copy/print the content and forward it to his friends. Thus this system will only restrict a specific way to share the information but not the sharing of the information in general. – Steffen Ullrich Nov 16 '15 at 8:39
  • 24
    I myself for instance have a desktop, a laptop, a tablet and a phone. So I can only use 2 as a used? Also note that the second you have a techy user involved, he will have figured it out in no time and have written a small browser-plugin that works around this problem. Trust me, the battle software vs. students is one you have lost from the start. Maybe solve the problem why they are sharing passwords instead of trying to prevent the symptoms. Just look at how the world is trying to block pirate bay... – Pinoniq Nov 16 '15 at 12:56
  • 17
    Have you considered restricting to two simultaneous sessions on two arbitrary devices per set of credentials? This solves all the problems associated with restricting a set of credentials to two distinct devices permanently. – Nov 16 '15 at 14:29

15 Answers 15

What you are trying to do is futile. Information can not be contained. You can not prevent someone from passing on information. When they can not share their logins, they just copy&paste the text. When you disable copy&pasting (the common methods to do this can be easily bypassed, by the way), they will make screenshots. When you find some way to make screenshots impossible (I couldn't think of any), they will read it to each other. All you will achieve is impair the user experience for legitimate users without really preventing abuse.

But when you really want to go down that route, you might look at alternative ways of browser fingerprinting than IP address and cookies. There is a lot of other information a web browser transmits on every page request, and often it is sufficiently unique to identify a user. The Electronic Frontier Foundation has an interesting demo with their Panopticlick website.

Among the techniques used are:

  • UserAgent string (browser self-identification)
  • HTTP_ACCEPT Headers
  • Installed plugins and their version numbers
  • Installed fonts
  • Timezone
  • Screen size and color depth
  • Alternative cookie techniques (localstorage, persistent storage in plugins like Flash)

Keep in mind that all these identification methods are prone to false negatives because many of them can change at any time. You should only consider a fingerprint as comming from a new device when multiple properties drastically change simultaneously. When the difference to the previous device profile is minor, you should silently update the device fingerprint instead.

  • 1
    Keep in mind that all these identification methods are prone to false negatives because many of them can change at any time. => In order to account for this, and device change, I would aim toward a deprecation policy. Simply retaining devices only a for "short" period of time (say, a week) will let users upgrade their plugins and devices. – Matthieu M. Nov 16 '15 at 18:32
  • 11
    @MatthieuM. So if I update a plugin or install a font I can't use your website for a week? You know what, I just decided I don't want to use your website anyway. (Better than the current suggestion of permanent, but you can see how the problem remains.) – Bob Nov 17 '15 at 3:05
  • @Bob: Of course not, that would be silly... it has to be combined with a restricted number of devices > 1. The OP proposed 2 devices with permanent registration, to be on par I would aim for 3 devices with a 1 week (for example) deprecation policy. The deprecation policy cannot be too short (with 1h, you can let anyone use your key, wait 1h, and use it yourself) and then you can play on the number of devices. And ideally, you would combine it with the cookie approach to recognize an updated device; but you need to be ready for when cookies have been wiped out. – Matthieu M. Nov 17 '15 at 7:16
  • 2
    Also, if the website is accessed from school computers, all the computers are going to look exactly the same. – Riking Nov 17 '15 at 7:42
  • FWIW we restricted our mobile app to be used only on a single iPad by one user account. Before that an employee could install the app to their relative iPad, sign them in as themselves and the relative gets up-to-date changing data that could be sensitive at their fingertips. With the restriction, the employee still can pass the data on, but it is much much less practical, so we are happy with our solution. It all depends on how far do you want/need to go. – Andrew Savinykh Nov 17 '15 at 20:34

In addition to the existing answers, I just want to stress out that cookies are not meant to be a reliable persistent storage. They can be cleared on many occasions without asking user's consent, for example after a browser crash, an upgrade, profile corruption, you name it.

You cannot just issue a fair warning to your users and expect them to keep the cookies. It's simply not under their control.

What could really stop users from sharing their credentials is the possibility of abuse (e.g. I will never give you my SO password, not necessarily because the terms and conditions say so, but because you will be able to abuse it by impersonating me). Check out if the students already have some kind of school-managed account (like school e-mail, intranet, etc.) and if you could delegate the authentication to this existing system (so that students would log in with their school e-mail and password as credentials). Needless to say, the students will unlikely share such credentials with friends just to make them see the shop.

  • 1
    Even in the absence of school-managed accounts (e.g. students from different schools) you can use their Facebook/Twitter/Google+ accounts via the corresponding authentication APIs -- they probably wouldn't want to share those either. – mustaccio Nov 16 '15 at 16:55
  • 4
    Is it a big problem to create a fake facebook account? Or just log in with a facebook account of someone who doesn't attend this school? – Dmitry Grigoryev Nov 16 '15 at 18:20
  • 1
    Generally it is not, of course, but it may be if one requires matching names on the account and the credit card used to pay for access. It is much less feasible to expect the school authentication system to be open for third party use anyway. – mustaccio Nov 16 '15 at 19:04
  • 1
    +1 for a really practical solution. Also, a list of facebook or gmail accounts could be pulled from students db in the case of absence of such a SSO system. – Askar Kalykov Nov 18 '15 at 10:34

Setting aside the fact that this is futile, which has already been established, there is an additional avenue that could be considered: compulsory two-factor auth. If you require each login account to register a 2FA token (Google Authenticator, etc.) or to simply click a verification link that was sent through a side channel if it looks like they are a different user, it could raise the barrier to entry.

  • 1
    This was going to be my answer. You can use Google Authenticator or Authy, both free, or send a text message with a code to their cell phone (maybe not every teen has a smart phone). Don't limit to 2 devices - it's too big a hassle. Like you said, what if they upgrade? Clear cookies? Etc. Need customer support for that. Big expense. – Chloe Nov 16 '15 at 17:06
  • And the sharing-user-1 tries to login, sends a SMS to the owner-user, which sends back the Google Auth token. Defeated! – ThoriumBR Nov 16 '15 at 19:12
  • 3
    @ThoriumBR "Raise the barrier to entry," not "prevent." :-P – smitelli Nov 16 '15 at 20:31
  • 2
    At least for HOTP/TOTP based 2FA tokens you could simply share the key between friends. – CodesInChaos Nov 17 '15 at 7:58

If your question is "will this work," the answer is no. Without any additional fingerprinting, it is pretty trivial for students to just share the cookie data, rendering your scheme completely powerless. (And if you have additional fingerprinting, then you don't really need the session cookie.)

If your question is "is this a good idea," the answer is still no. Aside from not actually accomplishing what you want, it will cause problems for legitimate users. This scheme will be worse in every measurable way than just asking students to please not share the accounts.

If your question is "can this be done in a better way," well, sorry but the answer is still no. Some forms of fingerprinting, as mentioned in @Philipp 's answer, might help you to better track how many unique users are accessing your content, and perhaps even to control how many directly access it. As noted, this is an inexact science and will not be completely accurate.

However, the problem with that is that your stated goal is not controlling how many users directly access the information; it is how many access the information at all. You can sometimes make this more difficult/annoying via DRM, but it is simply, literally, not possible to completely securely restrict the data with technological measures. Once the students have access to the data, you cannot stop them from sharing that data, completely outside of your service. (Note: not only is adding DRM likely to be a much bigger project than you're hoping for, but it is also mostly useful for binary data like executables or videos. If a significant portion of your private data is text, you may not be able to do much at all.)

The best solution is to simply ask the students not to do it. If you cannot trust the students with private data, then you shouldn't make the data available at all.

If you are still determined to do this (I hope you're not), my recommendation is that the best you can hope for is to somehow include fictitious entries in the data, that are programmatically generated based on students' user accounts. That won't stop the students from sharing, but if the data does crop up somewhere it's not supposed to be, you may at least have a chance of tracking down who originally shared it.

You mention Netflix, but there are important differences between your proposal and Netflix. Netflix enforces a limit on the total number of devices that can be "pre-authorized" — that is, where the user doesn't have to re-enter a password or authorization code — at one time, but the limit is higher (was six; may now be 50), and if the user hits the limit, it doesn't reject the new authorization, it just deauthorizes the least-recently-used device. It also enforces a limit of only one device (or, two, or four, depending on the account) actually streaming a video at the same time.

Also note that by using a cookie alone to identify a device, a user with a single computer who switches between browsers (say IE and Firefox, or IE and Chrome, or IE and Opera, or Chrome and Firefox) will appear to be using two devices. If the user calls technical support for some application and is told "clear your cookies" (a common first step), they will appear to be using a new device. Even my kids' Android tablets have two browsers, the Android default one and Chrome.

If the "content" is pictures or text, it's pretty much impossible to prevent it being copied, in the worst case by a camera pointed at the screen.

So your proposal does have a glaring error, at least from a usability point of view.

Let me start with this: I don't think your solution will help you in any way from preventing them sharing whatever is on that website with friends.

What if they do a screen share and then show them what's on that site? In terms of sharing, you can't stop that. They can take screenshots, print stuff out, video record, etc.
The alternative
A: One way to do that is to restrict the webshop to only be available on the school network, on the school PCs. The reason you want to do this is because you can:

  1. Control who's logging in.
  2. Control the PC and make sure that they can't share stuff.

That being said, they can still take pictures with their phones and share stuff this way.

B: The amount of effort and security you put in place should directly related with what you are trying to protect. Maybe you want to reconsider the whole super secure web app and allow people to regularly log in and strongly advise against sharing. You can then do a "review" of the activity and if people are not using their accounts in a legitimate way, restrict access from webshop.

I implemented a similar mechanism on one of my high traffic websites with paid content. I accomplished it using browser session cookies. The current session cookie is stored in the DB, and when the current cookie changes because the person logged in from somewhere else, the first session has to log in again. This would not necessarily prevent sharing of credentials, but it does prevent multiple users from using the site simultaneously. If two or more users do decide to use the site simultaneously, then everyone is constantly having to re-login on every page visit, which would likely be annoying enough to prevent it. At some point the original account holder gets fed up and will change their password and not share it again.

That being said, after some testing with this feature on, we decided to disable it. We did this for a few reasons:

  1. The feature was causing more headache for our existing users then its usefulness in the prevention of account sharing. Many of our users wanted to use our site at both home and work, and they don't like having to re-login multiple times per day. It's even worse if they use it on their mobile device or with multiple browsers. We considered raising the number of allowed sessions, but decided against it.
  2. Our product is inexpensive enough that most people prefer to pay for their own account rather than bothering to share.
  3. We know some people are sharing, and we just don't care. Most of the sharing we see is from countries where our product may be perceived as expensive by their income standards. I have no problem with friends from those countries getting together and paying for our product as a team. We are not likely to be losing sales anyway, if each individual could not afford the price by themselves.

Slightly different from the slightly answers, but i propose to add some very personal information to the user account so that the student does not want to share his/her password.

For example, link their account with their school grade database: you don't want anyone nosing in your marks. Additionally, add things like phone number, age, address, parent names, etc. which cannot be modified by the user self but only by the school in charge.

My school uses this way too: my school has a website on which to hand in essays (eg.), and to prevent password sharing they link it with your schedule, marks, personal details etc.

Just like other said, completely identifying and distinguishing persons/accounts is impossible. Best of luck!

What you're proposing won't work. People use different browsers, go into privacy mode, log into a work computer, log in from their phone, login from someone elses computer all the time. People are told to clear cookies all the time just to fix other problems. I myself have multiple computers and use multiple browsers. Your site would be totally unusable to me within a day or two. Your website will essentially be unusable very quickly, and students will bombard you with requests to constantly login. Cookies make really terrible persistent storage because they were never intended to persist!

Netflix does indeed control how many steams a single user can stream at any one time. But they do this actively, not just simply rely on a cookie always persisting. If you really need to control the amount of logins, you need to track the amount of ACTIVE logins. That means tracking whether the browser page is open, not simply a simple cookie approach. One way to do this is through javascript running on your website that actively sends a ping back to the server. When the ping is no longer received, de-activate that login.

If you don't somehow track active logins, you're going to be in a world of hurt. You may think you can fake this for a while because you're small, but your site will still be un-usable, and all because you're trying to prevent people from sharing logins.

Make sure that the credentials unique to each person give access to private information that the person would not want shared with other people. Credit card information, grades, home address, phone number, private email, etc. Allow purchases that will be billed to the student later but that can be shipped to any address. And so on.

This then puts a huge incentive into the system for the users to keep their credentials secret and is self-policing. No one, for example, will give away his bank credentials to someone else.

This can be accomplished not just by providing the sensitive information in the application, but also by forcing the reuse of a login that works in another system which does provide that information--perhaps even in a sort of OpenID way.

To respond to the idea that students aren't very security-minded, I am convinced there is a way to do this that will work. Put the sensitive information on the home page, and at the top of every page (or at least a link to go directly there, large and clearly labeled).

Any student who finds his information being used or his account being changed will hurry to inform you and close off access to others.

  • Students may be not the most security-oriented audience, hence this plan may still backfire. – Deer Hunter Nov 17 '15 at 0:03

A similar problem which Amazon has had to solve involves their "Households" feature. Amazon allows you to join accounts to share some Amazon Prime benefits (e.g. free 2-day shipping). The intent is for a household to only need to purchase Prime once, but this is obviously open to abuse where people could join accounts with friends and split the cost of Prime.

Amazon mitigates this problem by making payment methods part of the shared accounts - so anybody you join a "Household" with can also see and use your payment methods. I know that without this, I would be tempted to share accounts with casual friends, but now that payment methods are shared, I'm suddenly much more picky about who I share it with!

Many companies adopt a two-factor authentication approach where the user gets an SMS code on a preregistered phone number which is used to sign in while entering credentials.

While this is a security measure, it has a side effect of making it difficult (if not impossible) to share credentials with multiple users. Also add to this session expiration every few hours, depending on how frequently users log in to your site.

You can also use cookies to find out if a user has multiple sessions logged in simultaneously, which could imply that the user has shared his credentials.

This is obviously not a perfect solution to your problem but it's a feasible one that can be applied to make it difficult to reuse credentials among multiple users.

  • How can they use cookies to detect multiple logins? – Neil Smithline Nov 16 '15 at 18:22

You can develop a system where people can login using biometric verification. E.g. a picture could be taken using the webcam and then software extracts data from that which for the same person is unique, which doesn't change over time scales of the order of a few years.

I would suggest IP-ranges. This will give sufficent protection against account sharing, but will still allow for IP Changes.

The valid IP-range for the user in question, can be determited by a automated lookup to WHOIS. (Actually, WHOIS is designed to allow for automatic lookups). You can then request a IP like, and get back a response like - . Then you add the entry " -" to you auth database.

This only needs to be done everytime a user logs in from a "unauthorized" device, and their authorized number of devices is less than 2.

As a addition, you can make so login from school computers are "Always-free", eg does not need to affect authorization.

This will make the system so anything the user does on the client computer won't matter (like clearing cookies), and it will allow user to login from unlimited number of devices in a specific home (like the tablet, PC, mobile and such).

The limit of 2 IP ranges is then pretty good, since the user will usually login from home, mobile and school. Then home and mobile would be "auhorized" devices, and school is a "free" device.

Another way is to give the user a Yubico U2F token (These sells for $18 at Yubico), that will replace the username/password. They only get ONE token, and getting a new token enrolled will cost like 50$. Then it will be very much more difficult to share access than just sharing a username/password over phone. Combined with the IP range restriction, it would make it very difficult to share access.

EDIT: In short, your solution is bad. Here's an alternative.


As I understand this, this is a common problem presented in an uncommon way.

Multi-factor authentication? You give them a regular log in and when they attempt to log in, send them text containing a random 5-digit (or whatever) code that they must then enter.

This means two factors are considered when logging that person in:

  • Something you know (the username & password)
  • Something you have (the mobile phone associated with the account).

Given this is a school that may contain sensitive information, this sort if approach should be used across the board (as school shared drives often contain photos and such).

This approach is fairly easy to implement via a SMS API.

NOTE: Additionally and email link with a confirmation may work - a pain but if security of children is your priority here, you may be willing to take this route.

protected by Community Nov 17 '15 at 2:50

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.