How would you prevent someone from selling his persistent cookie to someone who is not an institution member and wants to gain access?

Question

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?

Answer 1

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.

Monitoring

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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).

Answer 9

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.

Answer 10

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.

Answer 11

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