Most of our publishers sell subscriptions to institutions and people get access by being identified as part of the institution. This institution authentication happens with IP ranges or Shibboleth, but not all institutions support Shibboleth or other SAML, and IP ranges do not help without VPN or proxy server. So, publishers want us to devise a scheme by which a user will gain short term access to his institutional holding (that is, to the content subscribed by his institution) while he is outside the IP range of the institution (e.g. at home or traveling.) The solution needs to be as simple as possible for the user, it should not require that they download anything and it should work well for users coming from mobile phones or from their laptops. The process could require that the users initiate this access while inside the IP range, but ideally, they should be able to initiate their 30 day access even if they are away from the institution and forgot to set it up.

In particular, please state how the user will assert that he is a member (faculty, student, employee, whatever) of the institution that he claims. Remember, that the institution has no authentication server and will not install one. Also, the user will not install an application on his computer. The complete solution will invariably involve a persistent cookie at some point. How would you prevent someone from selling his persistent cookie to someone who is not an institution member and wants to gain access?

  • 24
    usernames and passwords using the institution's email domain is the common design pattern for this
    – schroeder
    Commented May 3, 2017 at 12:27
  • 5
    @Dimitris MAC addresses can be faked.
    – Awn
    Commented May 3, 2017 at 13:27
  • 107
    If your threat model assumes your users to be the attackers, I don't think there's an adequate solution for what you're looking for.
    – Awn
    Commented May 3, 2017 at 13:29
  • 5
    In fact, can you prevent someone downloading the data onto a thumb drive? Commented May 4, 2017 at 0:48
  • 37
    If Alice has access to the content, and you successfully prevent Bob from using Alice's credentials to access the system, what's to prevent Alice from legitimately getting the content and sharing it with Bob via email/Google Drive/Dropbox/thumb drive/print out/etc.? If you have a determined "borrower" and a willing "sharer" you won't prevent extra-curricular distribution. All of those methods are much easier than selling (or freely distributing) validated cookies.
    – FreeMan
    Commented May 4, 2017 at 12:28

11 Answers 11


Can you prevent someone from selling their password to get similar access? Do you think you need to? It's pretty much equivalent.

Do you need to do this?

From my experience being inside/outside academic institutions with journal access, there's always some amount of sharing resources as a favour (e.g. "hey, could you send me a PDF of this paper?"). You'll never be able to stop that, because it is actually being manually accessed by a legitimate user on a correct machine. However, I have personally never witnessed student/staff trying to make money from this.


Even if they wanted to make money like this, then I don't think sharing cookies is the best way - it's certainly not how I'd do it! Protections you could add to the cookie system (e.g. fingerprinting the user's browser and checking it stays the same, etc.) won't apply to other methods.

Instead (if this is actually a problem), a reasonable and robust solution is to monitor user's usage patterns. If they are downloading 100x the resources of anyone else, or if they fetch resources consistently for 250 hours straight (the longest humans can survive without sleep), then there's probably multiple users or an automated system at work.

However, this monitoring solution doesn't have to be included from the beginning, it can be added in later - and until you have evidence that it's actually a problem, I think it should be quite far down your list of things to do.

  • 2
    @Dimitris: You could do various things to link the cookies more tightly to a particular computer/browser, but that only protects against sharing cookies, not any other methods of sharing access.
    – cloudfeet
    Commented May 3, 2017 at 12:40
  • 8
    So, no, that is not a robust solution, even ignoring the fact that MAC addresses can be changed.
    – cloudfeet
    Commented May 3, 2017 at 12:42
  • 12
    @Dimitris How would you verify that the device actually has the correct MAC address? Unless the device happens to be within the same ethernet network as your server (not gonna happen), you can’t see the device’ MAC server-side. Commented May 4, 2017 at 8:56
  • 3
    @Dimitris Trivial workaround that basically circumvents all possible hardware based solutions: Clone a VM. Heck, set up a VM in azure and share credentials to it.
    – Voo
    Commented May 4, 2017 at 19:17
  • 3
    Mac addresses can change, too. From ethernet to Wifi and back twice per day, occasionaly to the GSM module mac, and of course my overzealous firewall had to chime in with its own virtual network adapter with the latest update as well... Commented May 4, 2017 at 20:32

You don't.

This question is basically a variant of "How do I do DRM and have it work?" and the answer is the same.

I'm not sure why "selling a persistent cookie" seems like your primary threat. Normally users will just repost your publications to SciHub.

  • 8
    Pretty much this (+1). DRM solutions do not work for a reason, and that reason is that computers were originally designed to be fully programmable machines. The only way to make DRM (or the paper access solution OP is after) work is to allow a user to access the resource only from hardware that is 100% under your control. (Which is not something viable for a publisher)
    – grochmal
    Commented May 5, 2017 at 4:16

Cookie control is not a good solution to your problem, which isn't that well defined. You could spend a lot of time on preventing users from sending their cookies around, but you are likely to block legitimate access enough times that you will lose the goodwill of your clients, and effort is likely to be disproportional to the benefits. Some possible alternative strategies would be:

  • Limiting the number of devices a user account can be seen to log in from. If you see a user account active on 3 devices or so that could be a sign of abuse
  • Geographic location tracking, if a user account is being accessed in Boston and Beijing at the same time it could be abuse
  • Introducing 2 factor authentication of some kind, a user would have to put an extra code in occasionally. This is problematic to be honest, it's expensive to set up and maintain, and you'd have people constantly forgetting their pins to get a token. On the plus side you can't share token generators. Someone could still send their token code to someone else, but it makes it more difficult to share credentials
  • Monitor user patterns for abuse, you could use some sort of machine learning algorithm on user statistics or just plain old thresholds as @cloudfeet suggests
  • Have extra security questions requiring personal information as answers. Few people will trust someone else this information, often it would be the same as what's asked on a banking website or the like, so it would discourage them sharing it. This does introduce problems for you as a website owner as you now are responsible for more personal information
  • Send periodic emails reminding them of their obligations, it won't stop everyone, but gentle, courteous prods will work for some
  • Regarding limiting the number of devices, how do you identify what device a user is using?
    – Anders
    Commented May 3, 2017 at 17:20
  • 3
    In most cases, geolocation is based on IP. A legitimate user might have his reasons to juggle VPNs.
    – svavil
    Commented May 3, 2017 at 20:25
  • 2FA can be shared since it's based on a secret key from which a unique code is derived from the current time. You just have to share that secret key and you can generate your own codes. This is in a TOTP scenario which is most common. Commented May 3, 2017 at 21:14
  • 2
    Three devices: work desktop, home desktop, smartphone. If you're going to limit the number of devices, four or five is a better number.
    – Mark
    Commented May 4, 2017 at 1:07
  • 1
    @Mark The phrase was "If you see a user account active on 3 devices or so" -- you might use work/home/mobile at different times, but would be unlikely to be active on all three at the same time! Plus the "or so" suggests the number isn't set in stone.
    – TripeHound
    Commented May 4, 2017 at 10:04

I think all of the above answers are wrong. @Andy probably answered your question, albeit far too vaguely. The problem is that (a) you are assuming your users are a threat vector (exploiting cookies to gain unauthorised access) (b) you want to use cookies as part of your authentication mechanism. As it happens, what you actually want to implement is a type of zero trust security, a model which says that no user should be trusted in any event in any respect (this is quite hard to understand at first).

Essentially, the implication is that you can use cookies but these should just be session cookies. Shibbeloth and other similar designs for academic institutions in the UK, do use a combination of session cookies, third party authentication (at the institution) and database-led session authentication (by comparison to the other two). In fact, it usually checks the institution for user rights too (i.e. if you are studying computer science you don't need the medical library etc).

So, using a persistent cookie is your problem, this is a definite no-no. You seem to already understand the risk in using a persistent cookie, which is that it can be stolen (usually in plaintext). Therefore, use non-persistent session cookies at the worst.

What you should be doing, in my view, if you were to use this authentication method is to revoke the cookies regularly and require the user to login again. As I've explained, Shibbeloth is multi-factored by design as it compares your credentials to those held by your university. Better designs would not just compare user information, but require more than one credential (i.e. a text message, email or a secret answer as in online banking).

Realistically, most applications which are web-based can benefit hugely from being stateless (depending on the application and your user / system requirements). So, you can take session cookies out of the picture almost entirely by using them until that browser window is closed / time elapsed or by using an encrypted client-side user store (better solution).

Among other mitigations which other users have said, such as fingerprinting browsers and monitoring usage patterns, there are lots of strategies you could employ. You could also use IP whitelisting, anti-DDoS, regular credential rollover etc. These are complementary, but not a solution of themselves.

What you must never do, is de-prioritise security and software flaws for user experience improvement (they are the same thing by the way). If you do this, one day you might be responsible for a data protection catastrophe (and potentially go to prison and/or lose a lot of money).

To fully implement what you are looking for, use a web application (probably javascript based) which does not need to be installed. That application should be programmed to fully implement your API and do all the heavy lifting for the user. It should ideally carry out role-based access control (RBAC) over that API (so identify the different user groups you have mentioned). Obviously, the RBAC needs to be implemented on the server side. There is no reason your API cannot provide or link directly into this and store tokens issued directly, or through another channel such as a text-message based tokenw.

I hope this gives you some food for thought in relation to your design.

  • 8
    "What you must never do, is de-prioritise security and software flaws for user experience improvement". DRM has nothing to do with security. It's just one of the many, many business requirements, another of which is the user experience. If you designed the perfect DRM which nobody wanted to use, you'd still be out of business.
    – Voo
    Commented May 4, 2017 at 19:21
  • 3
    +1, but regarding your assertion that "[One must never] de-prioritise security...for user experience..." strikes me as gross hyperbole. Not every system is protecting nuclear launch codes and the like; on the flip side of the coin, you can build the most secure system in the world, but if no one cares to use it, it's all been a fruitless exercise. In the real world, exceedingly few worry about security to that degree (far too little concern in general, I would posit), but it's not often practical to go to maximal lengths to protect data which is, more times than not, only semi-critical.
    – tjbtech
    Commented May 5, 2017 at 0:36
  • Thank you for your comments. I can see the logic in what you are saying, but I cannot agree. In blue chip companies these days, software is particularly difficult to hack - take Facebook for example. However, everything is hackable to some extent, in that it can be exploited in some way or another. Can being the operative word. My point is that most hacks these days are zero-day exploits tailored to the system uniquely. So a data breach or DRM breach is a matter of when, not if. The question is, do you want to mitigate it or not. Commented May 5, 2017 at 4:08
  • Not all data breaches are alike, and the tradeoffs to be made vary. One can quite reasonably decide to mitigate some cases and not mitigate others -- if a user sharing access to a nonprivileged account can be leveraged into a full breach, it's the bigger issues allowing that escalation/leverage that need to be addressed. Commented May 5, 2017 at 16:50
  • 2
    There are always trade-offs between user experience and security. It's pointless to say that you can never ever put the user experience first. Surely the journal articles here would be more secure if one could only them access them in person under escort by an armed guard after the Board of Trustees of their institution has verified that they are authorized to access them (and someone else has verified that really was the Board, etc...), but it would be a horrid user experience. The trick is knowing which trade-offs to make and how, not categorical rules that security always comes first. Commented May 5, 2017 at 21:12

Do like the banks, Lyft, and other organizations are doing. Require that the user receives a text or email with a validation code before you allow completion of the login progress.


This sounds an awful lot like EBSCO. I'm the admin at an institution that uses the Academic Search Premiere, PsycArticles, JStor, and a few other EBSCO subscriptions.

Right now we (like many others) rely on EZProxy, but this solution is becoming less and less tenable as more content goes SSL/TLS. Proxying encrypted traffic isn't a very good idea.

I can tell you that this idea that institutions can't do Shibboleth or SAML is increasingly inaccurate. There are a few out there, but it's time for them to get with the program and get an SSO identity provider going. If my sub-400 FTE institution can do it, so can they. You might also look at OAuth.

As a fallback for those with truly incompetent IT staffs, you could manage accounts yourself. Require institutions to upload a report each term with e-mails addresses for faculty and students, send out an invitations for those on the list who are new, extend the expiration date for those who are returning, and suspend those accounts for the institution that are no longer in the list.

Sure, as a user I could give access to someone else, but that's true of any other service, too. Even with the existing system, I could log in on someone else's laptop while I'm home. You won't really have lost anything.

  • I've noticed that a few institutions are struggling with EZProxy because proxying encrypted traffic reliably for a lot of users can be difficult to properly configure. Many universities these days are using Google and Microsoft accounts for SSO, and this in turn with Shibboleth. Commented May 6, 2017 at 18:17
  • In this case of my institution, it's mainly that we're just cheap. We're still running an ezproxy version from 2005 that only wants to use compromised RC4 SSL protocols rather than TLS, and I can't get approval to upgrade it. Though in fairness to my superiors, their reluctance stems from the fact that you can't just buy the program anymore; OCLC only sells it now with an annual subscription where each year's renewal costs more than we spent to get it in first place 12 years ago. It's effectively more than a 10-fold price increase. Commented May 6, 2017 at 21:29

Email their institution email with a link that will create a short lived cookie(3 days) in their browser, that is one time use. Institutions almost always have an email. Allow them to enter their institution email. This prevents the journal from having to deal with passwords on the system, and lets professors get to work.


I assume you are not worried about hefty sums of money being stolen (like in a banking setup). So, if actual 2-factor-authentication or even "getting physical" (card reader) is too much for you, how about this:

  • Implement regular login/password authentication (with HTTPS of course, as usual).
  • Take your session cookie and create a second cookie which consists of hash(session_cookie + IP + secret salt).
  • If you so wish, add the SSL session ID to that hash (which does not persist closing the browser, which is good for you). This might lead to a bit of inconvenience if any party initiates a renegotiation (which would give you a new session ID and thus force the user to log in again).
  • Aside from verifying the session cookie, also verify the client IP for every single request using that second bit of information (which, as said, may be a second cookie or concatenated into the first, does not matter).

Now the user can give away the cookie to his heart's content and nobody will be able to use it unless he can also spoof the IP address (rather unlikely in this scenario; probably much harder than the original user just forwarding any content he legitimately downloaded) and/or the SSL session ID (impossible).

  • How about basic username/password (as mentioned in this answer) BUT the account creation process is either done by the licensing institution via API call or can only be done from the institution's netblock(s). Once the account is created, normal user/pass authentication. If you are worried about account sharing, then add 2 factor in by sending an email wtih a link that completes the authentication process to the user's institution provided address
    – ivanivan
    Commented May 7, 2017 at 20:03

Because nobody's mentioned it yet, another make using a cookie elsewhere harder would be browser fingerprinting; basically, examining properties of the used software and hardware that are leaked in some way and using these as a "fingerprint" to identify the used device.

Of course, you're going to have to send the device fingerprint to your server at some point so you can verify that that a session did not end up being used on a different browser and/or device, so a determined attacker could at this point try to modify the data to correspond with the information sent by the actual user's browser. Still, depending on your implementation, it could be used to at least raise the bar somewhat.


Cookie-based solution doesn't prevent users from selling/renting their accounts - a better solution would be server-managed 2-factor authentication based on IP address:

  • Allow accounts to register to a small set of IP addresses.
  • Logging in or attempting to use a login cookie outside this set prompts an email confirmation link with a reminder to prevent unauthorized access.
  • If the new area is confirmed, it gets added to the set of authorized locations and the oldest one in the list gets removed to make room.

Maintaining a 2-factor authentication file on the end-user's computer doesn't work because end-user could sell that file as well, therefore the 2-factor authentication needs to be handled server-side.

Also profile end-users' fields of specialization and access behavior. For example, if an account belonging to a physics professor suddenly starts bulk-downloading economics and sociology papers, obviously lock it down.

Meter data amounts (similar to mobile data plans) on downloads per account. For example, the first half-gigabyte of articles a user downloads each week download normally, after which that user's downloads are throttled to 200KB/s (change the numbers as you see fit). Most journal articles aren't huge and the download throttling wouldn't affect most normal users, however it will prove incredibly frustrating to bulk-downloaders.

  • 1
    Downvote. Huh? IP addresses? Have we overlooked the fact that people share them, at work, coffee shops, and so forth? Wow.
    – Xavier J
    Commented May 6, 2017 at 13:58
  • No solution's perfect. IP addresses can be masked or proxy-routed. There are tools to change your computer's MAC address. So you just have to go with the best computer/user identifier. Commented May 9, 2017 at 0:30

You could use client certificate authentication (SSL), signed by your organization. This should be internet-wide, somewhat like a VPN, but simpler and cheaper.

  • 1
    how do you distribute and install those certs? wouldn't this suggestion be contrary to the stated requirements?
    – schroeder
    Commented May 5, 2017 at 12:43
  • Well, the installation mechanism is built into the operating system, so to the average user, it is intuitive. And they could be distributed by e-mail, althought the requirement "the user should not have to download anything" is a little bit vague, since we are talking about downloading materials anyway. On the server side, you could have an SQlite database for user-certificate pairing, and a simple script, like PHP for authentication, which kind of avoids having a dedicated server. The certificates should be issued on request, designed to expire with the OP's requirements. Commented May 5, 2017 at 12:56
  • 2
    and so how do prevent the user from selling the client cert (same problem as the cookie)? I also disagree that installing a cert is as intuitive for users as downloading an article from a journal site ...
    – schroeder
    Commented May 5, 2017 at 14:10
  • @schroeder I know, I am stretching it way to far, but I am genuinely interested in providing an answer. After some Googling, it seems that on the server side you could detect whether the certificates are being used at the same time from two different machines (or, even more detectable, from a spoofed MAC/IP). That could be a good-enough incentive to clients for not sharing the certificate. Furthermore, shouldn't the Terms of Use prevent this? And isn't the OPs problem actually a breach of contract, or even a basis for a criminal penalty? Commented May 5, 2017 at 15:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .