Pouvez-vous empêcher quelqu'un de vendre son mot de passe pour obtenir un accès similaire? Pensez-vous que vous en avez besoin? C'est à peu près équivalent.

Avez-vous besoin de faire cela?

D'après mon expérience à l'intérieur / à l'extérieur des institutions académiques avec accès aux revues, il y a toujours une certaine quantité de ressources de partage en tant que faveur ( par exemple "hé, pouvez-vous m'envoyer un PDF de ce document?"). Vous ne pourrez jamais arrêter cela, car un utilisateur légitime y accède manuellement sur une machine correcte. Cependant, je n'ai personnellement jamais vu des étudiants / membres du personnel essayer de gagner de l'argent avec cela.

Surveillance

Même s'ils voulaient gagner de l'argent de cette manière, je ne pense pas que le partage de cookies est le meilleur moyen - ce n'est certainement pas comme ça que je le ferais! Les protections que vous pourriez ajouter au système de cookies (par exemple, prendre les empreintes digitales du navigateur de l'utilisateur et vérifier qu'il reste le même, etc.) ne s'appliqueront pas aux autres méthodes.

Au lieu de cela (s'il s'agit réellement d'un problème), un Une solution raisonnable et robuste consiste à surveiller les modèles d'utilisation des utilisateurs. S'ils téléchargent 100 fois les ressources de quelqu'un d'autre, ou s'ils récupèrent des ressources de manière cohérente pendant 250 heures consécutives (les humains les plus longs peuvent survivre sans dormir), alors il y a probablement plusieurs utilisateurs ou un système automatisé au travail.

Cependant, cette solution de surveillance n'a pas à être incluse dès le début, elle peut être ajoutée plus tard - et jusqu'à ce que vous ayez la preuve qu'il s'agit réellement d'un problème, je pense que cela devrait être assez loin liste de choses à faire.

Vous ne le faites pas.

Cette question est essentiellement une variante de "Comment faire un DRM et le faire fonctionner?" et la réponse est la même.

Je ne sais pas pourquoi "vendre un cookie persistant" semble être votre principale menace. Normalement, les utilisateurs republieront simplement vos publications sur SciHub.

Le contrôle des cookies n'est pas une bonne solution à votre problème, qui n'est pas si bien défini. Vous pourriez passer beaucoup de temps à empêcher les utilisateurs d'envoyer leurs cookies, mais vous risquez de bloquer l'accès légitime suffisamment de fois pour que vous perdiez la bonne volonté de vos clients, et les efforts seront probablement disproportionnés par rapport aux avantages. Voici quelques stratégies alternatives possibles:

• Limiter le nombre d'appareils à partir desquels un compte utilisateur peut être vu pour se connecter. Si vous voyez un compte d'utilisateur actif sur environ 3 appareils, cela pourrait être un signe d'abus
• Suivi de la localisation géographique, si un compte d'utilisateur est en cours d'accès à Boston et à Pékin en même temps, il peut s'agir d'un abus
• En introduisant une authentification à 2 facteurs, un utilisateur devrait parfois insérer un code supplémentaire. Pour être honnête, c'est problématique, la configuration et la maintenance sont coûteuses et les gens oublient constamment leurs épingles pour obtenir un jeton. Du côté positif, vous ne pouvez pas partager les générateurs de jetons. Quelqu'un peut toujours envoyer son code de jeton à quelqu'un d'autre, mais cela rend plus difficile le partage des informations d'identification
• Surveillez les modèles d'utilisation abusifs, vous pouvez utiliser une sorte d'algorithme d'apprentissage automatique sur les statistiques des utilisateurs ou simplement d'anciens seuils comme @cloudfeet le suggère
• Ayez des questions de sécurité supplémentaires nécessitant des informations personnelles comme réponses. Peu de gens feront confiance à quelqu'un d'autre à cette information, souvent ce serait la même chose que ce qui est demandé sur un site Web bancaire ou autre, donc cela les découragerait de les partager. Cela pose des problèmes pour vous en tant que propriétaire de site Web, car vous êtes désormais responsable de plus d'informations personnelles
• Envoyez des e-mails périodiques pour leur rappeler leurs obligations, cela n'empêchera pas tout le monde, mais des conseils doux et courtois fonctionneront pour certains

Je pense que toutes les réponses ci-dessus sont fausses. @Andy a probablement répondu à votre question, bien que trop vaguement. Le problème est que (a) vous supposez que vos utilisateurs sont un vecteur de menace (exploitant les cookies pour obtenir un accès non autorisé) (b) vous souhaitez utiliser des cookies dans le cadre de votre mécanisme d'authentification. En fait, ce que vous voulez réellement implémenter, c'est un type de sécurité zéro confiance, un modèle qui dit qu'aucun utilisateur ne doit en aucun cas faire confiance à aucun égard (c'est assez difficile à comprendre au début).

Essentiellement, l'implication est que vous pouvez utiliser des cookies, mais ceux-ci ne doivent être que des cookies de session. Shibbeloth et d'autres conceptions similaires pour les établissements universitaires au Royaume-Uni utilisent une combinaison de cookies de session, d'authentification tierce (au sein de l'établissement) et d'authentification de session basée sur une base de données (par rapport aux deux autres). En fait, il vérifie généralement l'institution pour les droits d'utilisateur aussi (c'est-à-dire que si vous étudiez l'informatique, vous n'avez pas besoin de la bibliothèque médicale, etc.).

Donc, l'utilisation d'un cookie persistant est votre problème, c'est un non-non définitif. Vous semblez déjà comprendre le risque lié à l'utilisation d'un cookie persistant, à savoir qu'il peut être volé (généralement en texte brut). Par conséquent, utilisez au pire des cookies de session non persistants.

Ce que vous devriez faire, à mon avis, si vous deviez utiliser cette méthode d'authentification, c'est de révoquer les cookies régulièrement et de demander à l'utilisateur de se reconnecter . Comme je l'ai expliqué, Shibbeloth est multi-facteurs de par sa conception car il compare vos informations d'identification à celles détenues par votre université. De meilleures conceptions ne permettraient pas seulement de comparer les informations utilisateur, mais nécessiteraient plus d'un identifiant (par exemple, un message texte, un e-mail ou une réponse secrète comme dans les services bancaires en ligne).

De manière réaliste, la plupart des applications basées sur le Web peuvent bénéficier énormément d'être sans état (en fonction de l'application et de la configuration requise par l'utilisateur / système). Ainsi, vous pouvez supprimer les cookies de session presque entièrement en les utilisant jusqu'à ce que la fenêtre du navigateur soit fermée / le temps écoulé ou en utilisant un magasin d'utilisateurs crypté côté client (meilleure solution).

Entre autres atténuations ce que d'autres utilisateurs ont dit, comme les navigateurs d'empreintes digitales et la surveillance des modèles d'utilisation, il existe de nombreuses stratégies que vous pouvez utiliser. Vous pouvez également utiliser la liste blanche IP, l'anti-DDoS, le remplacement régulier des informations d'identification, etc. Ce sont complémentaires, mais pas une solution en eux-mêmes.

Ce que vous ne devez jamais faire, c'est dé-prioriser la sécurité et les failles logicielles pour l'utilisateur l'expérience d'amélioration (c'est la même chose d'ailleurs). Si vous faites cela, vous pourriez un jour être responsable d'une catastrophe de protection des données (et potentiellement aller en prison et / ou perdre beaucoup d'argent).

Pour mettre pleinement en œuvre ce que vous recherchez, utilisez un application Web (probablement basée sur javascript) qui n'a pas besoin d'être installée. Cette application doit être programmée pour implémenter pleinement votre API et faire tout le gros du travail pour l'utilisateur. Il devrait idéalement effectuer un contrôle d'accès basé sur les rôles (RBAC) sur cette API (identifiez donc les différents groupes d'utilisateurs que vous avez mentionnés). Évidemment, le RBAC doit être implémenté côté serveur. Il n'y a aucune raison pour laquelle votre API ne peut pas fournir ou créer un lien direct vers celui-ci et stocker les jetons émis directement, ou via un autre canal tel qu'un jeton basé sur un message texte.

J'espère que cela vous donnera matière à réflexion. à votre conception.

Faites comme les banques, Lyft et d'autres organisations le font. Exigez que l'utilisateur reçoive un texte ou un e-mail avec un code de validation avant d'autoriser l'achèvement de la progression de la connexion.

Cela ressemble beaucoup à EBSCO. Je suis l'administrateur d'une institution qui utilise Academic Search Premiere, PsycArticles, JStor et quelques autres abonnements EBSCO.

Pour le moment, nous (comme beaucoup d'autres) nous appuyons sur EZProxy, mais cette solution devient de moins en moins tenable à mesure que le contenu passe à SSL / TLS. Le proxy du trafic chiffré n'est pas une très bonne idée.

Je peux vous dire que cette idée selon laquelle les institutions ne peuvent pas faire Shibboleth ou SAML est de plus en plus inexacte. Il y en a quelques-uns, mais il est temps pour eux de se lancer dans le programme et de créer un fournisseur d'identité SSO. Si mon établissement de moins de 400 ETP peut le faire, ils le peuvent aussi. Vous pouvez également consulter OAuth.

Pour remplacer ceux dont le personnel informatique est vraiment incompétent, vous pouvez gérer vous-même les comptes. Exiger des établissements qu'ils téléchargent un rapport à chaque trimestre avec les adresses électroniques des professeurs et des étudiants, envoyer des invitations pour les nouveaux inscrits sur la liste, prolonger la date d'expiration pour ceux qui reviennent et suspendre ces comptes pour l'institution qui n'est plus dans la liste.

Bien sûr, en tant qu'utilisateur, je pourrais donner accès à quelqu'un d'autre, mais c'est également vrai pour tout autre service. Même avec le système existant, je pourrais me connecter sur l'ordinateur portable de quelqu'un d'autre pendant que je suis à la maison. Vous n'aurez vraiment rien perdu.

Envoyez un e-mail à leur établissement par e-mail avec un lien qui créera un cookie de courte durée (3 jours) dans leur navigateur, à usage unique. Les institutions ont presque toujours un e-mail. Permettez-leur de saisir l'adresse e-mail de leur établissement. Cela évite au journal d'avoir à gérer les mots de passe sur le système et permet aux professeurs de se mettre au travail.

Je suppose que vous n'êtes pas préoccupé par le vol de sommes importantes (comme dans une configuration bancaire). Donc, si l'authentification réelle à 2 facteurs ou même "obtenir physique" (lecteur de carte) est trop pour vous, que diriez-vous de ceci:

• Mettez en œuvre une authentification de connexion / mot de passe régulière (avec HTTPS bien sûr , comme d'habitude).
• Prenez votre cookie de session et créez un second cookie composé de hash (session_cookie + IP + secret salt) .
• Si vous si vous le souhaitez, ajoutez l'ID de session SSL à ce hachage (ce qui ne persiste pas à fermer le navigateur, ce qui est bon pour vous). Cela pourrait entraîner un peu d'inconvénient si une partie lance une renégociation (ce qui vous donnerait un nouvel ID de session et obligerait ainsi l'utilisateur à se reconnecter).
• En plus de vérifier le cookie de session, vérifiez également l'adresse IP du client pour chaque requête en utilisant ce deuxième bit d'information (qui, comme dit, peut être un deuxième cookie ou concaténé dans le premier, n'a pas d'importance) .

Maintenant, l'utilisateur peut donner le cookie au contenu de son cœur et personne ne pourra l'utiliser à moins qu'il ne puisse également usurper l'adresse IP (plutôt improbable dans ce scénario; probablement beaucoup plus difficile que l'utilisateur d'origine transmettant simplement tout contenu qu'il a légitimement téléchargé) et / ou l'identifiant de session SSL (impossible).

Parce que personne ne l'a encore mentionné, une autre difficulté à utiliser un cookie ailleurs serait la empreinte digitale du navigateur; en gros, en examinant les propriétés des logiciels et du matériel utilisés qui ont fait l'objet d'une fuite et en les utilisant comme «empreinte digitale» pour identifier l'appareil utilisé.

Bien sûr, vous allez devoir envoyer l'appareil empreinte digitale sur votre serveur à un moment donné afin que vous puissiez vérifier qu'une session n'a pas fini par être utilisée sur un navigateur et / ou un appareil différent, de sorte qu'un attaquant déterminé pourrait à ce stade essayer de modifier les données pour qu'elles correspondent aux informations envoyées par le navigateur de l'utilisateur réel. Néanmoins, en fonction de votre implémentation, il pourrait être utilisé pour au moins élever quelque peu la barre.

La solution basée sur les cookies n'empêche pas les utilisateurs de vendre / louer leurs comptes - une meilleure solution serait l'authentification à 2 facteurs gérée par le serveur basée sur l'adresse IP:

• Autoriser les comptes à s'inscrire à un petit ensemble d'adresses IP.
• La connexion ou la tentative d'utilisation d'un cookie de connexion en dehors de cet ensemble entraîne un lien de confirmation par e-mail avec un rappel pour empêcher tout accès non autorisé.
• Si le nouveau La zone est confirmée, elle est ajoutée à l'ensemble des emplacements autorisés et la plus ancienne de la liste est supprimée pour faire de la place.

Maintenir un fichier d'authentification à 2 facteurs sur l'ordinateur de l'utilisateur final ne fonctionne pas parce que l'utilisateur final pourrait également vendre ce fichier, donc l'authentification à 2 facteurs doit être gérée côté serveur.

Également profiler les domaines de spécialisation et le comportement d'accès des utilisateurs finaux. Par exemple, si un compte appartenant à un professeur de physique commence soudainement à télécharger en masse des articles d'économie et de sociologie, verrouillez-le évidemment.

Mesurez les quantités de données (similaires aux forfaits de données mobiles) sur les téléchargements par compte. Par exemple, le premier demi-gigaoctet d'articles qu'un utilisateur télécharge chaque semaine se télécharge normalement, après quoi les téléchargements de cet utilisateur sont limités à 200 Ko / s (modifiez les nombres comme bon vous semble). La plupart des articles de revues ne sont pas énormes et la limitation du téléchargement n'affecterait pas la plupart des utilisateurs normaux, mais cela s'avérera incroyablement frustrant pour les téléchargeurs en masse.

Vous pouvez utiliser l'authentification par certificat client (SSL), signée par votre organisation. Cela devrait être à l'échelle d'Internet, un peu comme un VPN, mais plus simple et moins cher.