Können Sie verhindern, dass jemand sein Passwort verkauft, um einen ähnlichen Zugriff zu erhalten? Glaubst du, du musst? Es ist ziemlich gleichwertig.

Müssen Sie dies tun?

Aufgrund meiner Erfahrung innerhalb / außerhalb akademischer Institutionen mit Journalzugriff gibt es immer eine gewisse Menge an Ressourcen als Gefallen ( zB "Hey, kannst du mir ein PDF dieses Papiers schicken?"). Sie werden das nie aufhalten können, da ein legitimer Benutzer auf einem korrekten Computer tatsächlich manuell darauf zugreift. Ich persönlich habe jedoch noch nie gesehen, wie Studenten / Mitarbeiter versucht haben, damit Geld zu verdienen.

Überwachung

Selbst wenn sie so Geld verdienen wollten, denke ich nicht, dass sie Cookies teilen ist der beste Weg - es ist sicherlich nicht so, wie ich es machen würde! Schutzmaßnahmen, die Sie dem Cookie-System hinzufügen können (z. B. Fingerabdruck des Browsers des Benutzers und Überprüfung, dass dieser gleich bleibt usw.), gelten nicht für andere Methoden.

Stattdessen (wenn dies tatsächlich ein Problem ist), a Eine vernünftige und robuste Lösung besteht darin, die Nutzungsmuster der Benutzer zu überwachen. Wenn sie das 100-fache der Ressourcen anderer herunterladen oder wenn sie 250 Stunden lang ununterbrochen Ressourcen abrufen (die längsten Menschen können ohne Schlaf überleben), arbeiten wahrscheinlich mehrere Benutzer oder ein automatisiertes System.

Diese Überwachungslösung muss jedoch nicht von Anfang an enthalten sein, sondern kann später hinzugefügt werden - und bis Sie Beweise dafür haben, dass es sich tatsächlich um ein Problem handelt, sollte es meiner Meinung nach ziemlich weit unten liegen Liste der zu erledigenden Dinge.

Sie nicht.

Diese Frage ist im Grunde eine Variante von "Wie mache ich DRM und wie funktioniert es?" und die Antwort ist dieselbe.

Ich bin mir nicht sicher, warum "Verkauf eines dauerhaften Cookies" Ihre primäre Bedrohung darstellt. Normalerweise veröffentlichen Benutzer Ihre Veröffentlichungen nur erneut in SciHub.

Die Cookie-Kontrolle ist keine gute Lösung für Ihr Problem, das nicht so genau definiert ist. Sie könnten viel Zeit darauf verwenden, Benutzer daran zu hindern, ihre Cookies zu versenden, aber Sie blockieren wahrscheinlich den legitimen Zugriff so oft, dass Sie den guten Willen Ihrer Kunden verlieren, und der Aufwand ist wahrscheinlich unverhältnismäßig zu den Vorteilen. Einige mögliche alternative Strategien wären:

• Begrenzen der Anzahl der Geräte, von denen aus sich ein Benutzerkonto anmelden kann. Wenn auf einem oder mehreren Geräten ein Benutzerkonto aktiv ist, kann dies ein Zeichen für Missbrauch sein.
• Geografische Standortverfolgung. Wenn gleichzeitig in Boston und Peking auf ein Benutzerkonto zugegriffen wird, kann dies ein Missbrauch sein / li>
• Bei der Einführung einer 2-Faktor-Authentifizierung müsste ein Benutzer gelegentlich einen zusätzlichen Code eingeben. Dies ist, um ehrlich zu sein, problematisch, es ist teuer einzurichten und zu warten, und die Leute würden ständig ihre Pins vergessen, um einen Token zu erhalten. Auf der positiven Seite können Sie keine Token-Generatoren freigeben. Jemand könnte seinen Token-Code immer noch an einen anderen senden, aber es macht es schwieriger, Anmeldeinformationen gemeinsam zu nutzen.
• Überwachen Sie Benutzermuster auf Missbrauch. Sie könnten einen Algorithmus für maschinelles Lernen für Benutzerstatistiken oder einfach nur alte Schwellenwerte verwenden wie @cloudfeet vorschlägt
• Haben Sie zusätzliche Sicherheitsfragen, für die persönliche Informationen als Antwort erforderlich sind. Nur wenige Menschen vertrauen jemand anderem diese Informationen. Oft sind es die gleichen Informationen wie auf einer Bank-Website oder ähnlichem, sodass sie davon abgehalten werden, sie weiterzugeben. Dies führt zu Problemen für Sie als Websitebesitzer, da Sie jetzt für mehr persönliche Informationen verantwortlich sind.
• Senden Sie regelmäßig E-Mails, die Sie an ihre Verpflichtungen erinnern. Es wird nicht jeden aufhalten, aber sanfte, höfliche Produkte werden funktionieren einige

Ich denke, alle oben genannten Antworten sind falsch. @Andy hat wahrscheinlich Ihre Frage beantwortet, wenn auch viel zu vage. Das Problem besteht darin, dass (a) Sie davon ausgehen, dass Ihre Benutzer ein Bedrohungsvektor sind (Cookies ausnutzen, um nicht autorisierten Zugriff zu erhalten) (b) Sie Cookies als Teil Ihres Authentifizierungsmechanismus verwenden möchten. Was Sie tatsächlich implementieren möchten, ist eine Art von Null-Vertrauenssicherheit, ein Modell, das besagt, dass keinem Benutzer auf jeden Fall in irgendeiner Hinsicht vertraut werden sollte (dies ist zunächst ziemlich schwer zu verstehen).

Im Wesentlichen bedeutet dies, dass Sie Cookies verwenden können, dies sollten jedoch nur Sitzungscookies sein. Shibbeloth und andere ähnliche Designs für akademische Einrichtungen in Großbritannien verwenden eine Kombination aus Sitzungscookies, Authentifizierung durch Dritte (an der Einrichtung) und datenbankgestützter Sitzungsauthentifizierung (im Vergleich zu den beiden anderen). Tatsächlich überprüft es die Institution normalerweise auch auf Benutzerrechte (dh wenn Sie Informatik studieren, benötigen Sie keine medizinische Bibliothek usw.).

Die Verwendung eines dauerhaften Cookies ist also Ihr Problem ein definitives Nein-Nein. Sie scheinen das Risiko bei der Verwendung eines dauerhaften Cookies bereits zu verstehen, dh es kann gestohlen werden (normalerweise im Klartext). Verwenden Sie daher im schlimmsten Fall nicht persistente Sitzungscookies.

Wenn Sie diese Authentifizierungsmethode verwenden, sollten Sie meiner Ansicht nach die Cookies regelmäßig widerrufen und den Benutzer erneut anmelden . Wie ich bereits erklärt habe, ist Shibbeloth vom Design her vielschichtig, da es Ihre Anmeldeinformationen mit denen Ihrer Universität vergleicht. Bessere Designs würden nicht nur Benutzerinformationen vergleichen, sondern mehr als einen Berechtigungsnachweis erfordern (d. H. Eine Textnachricht, eine E-Mail oder eine geheime Antwort wie beim Online-Banking).

Realistisch gesehen können die meisten webbasierten Anwendungen enorm davon profitieren, dass sie zustandslos sind (abhängig von der Anwendung und Ihren Benutzer- / Systemanforderungen). Sie können Sitzungscookies also fast vollständig aus dem Bild entfernen, indem Sie sie verwenden, bis das Browserfenster geschlossen ist / die Zeit abgelaufen ist, oder indem Sie einen verschlüsselten clientseitigen Benutzerspeicher verwenden (bessere Lösung).

Unter anderem Wie andere Benutzer bereits gesagt haben, z. B. Fingerabdruck-Browser und Überwachung der Nutzungsmuster, gibt es viele Strategien, die Sie anwenden können. Sie können auch IP-Whitelisting, Anti-DDoS, regelmäßigen Rollover von Anmeldeinformationen usw. verwenden. Diese sind komplementär, aber keine Lösung für sich.

Was Sie niemals tun dürfen, ist die Priorisierung von Sicherheits- und Softwarefehlern für Benutzer Verbesserung erfahren (sie sind übrigens dasselbe). Wenn Sie dies tun, könnten Sie eines Tages für eine Datenschutzkatastrophe verantwortlich sein (und möglicherweise ins Gefängnis gehen und / oder viel Geld verlieren).

Um das, was Sie suchen, vollständig umzusetzen, verwenden Sie a Webanwendung (wahrscheinlich Javascript-basiert), die nicht installiert werden muss. Diese Anwendung sollte so programmiert sein, dass sie Ihre API vollständig implementiert und das ganze schwere Heben für den Benutzer erledigt. Es sollte idealerweise eine rollenbasierte Zugriffskontrolle (RBAC) über diese API durchführen (identifizieren Sie also die verschiedenen Benutzergruppen, die Sie erwähnt haben). Offensichtlich muss der RBAC auf der Serverseite implementiert werden. Es gibt keinen Grund, warum Ihre API diese nicht direkt oder über einen anderen Kanal wie ein auf Textnachrichten basierendes Token bereitstellen oder verknüpfen kann.

Ich hoffe, dies gibt Ihnen Anlass zum Nachdenken zu Ihrem Design.

Machen Sie es wie die Banken, Lyft und andere Organisationen. Der Benutzer muss einen Text oder eine E-Mail mit einem Validierungscode erhalten, bevor Sie den Anmeldevorgang abschließen können.

Das klingt sehr nach EBSCO. Ich bin der Administrator einer Institution, die die Premiere der akademischen Suche, PsycArticles, JStor und einige andere EBSCO-Abonnements verwendet.

Im Moment verlassen wir uns (wie viele andere auch) auf EZProxy, aber diese Lösung wird immer weniger haltbar, da mehr Inhalte SSL / TLS enthalten. Proxy für verschlüsselten Datenverkehr ist keine sehr gute Idee.

Ich kann Ihnen sagen, dass diese Vorstellung, dass Institutionen Shibboleth oder SAML nicht durchführen können, zunehmend ungenau ist. Es gibt einige, aber es ist Zeit für sie, sich mit dem Programm vertraut zu machen und einen SSO-Identitätsanbieter in Betrieb zu nehmen. Wenn meine Sub-400-FTE-Einrichtung dies kann, können sie es auch. Sie können sich auch OAuth ansehen.

Als Ersatz für diejenigen mit wirklich inkompetenten IT-Mitarbeitern können Sie Konten selbst verwalten. Fordern Sie die Institutionen auf, in jedem Semester einen Bericht mit E-Mail-Adressen für Lehrkräfte und Studenten hochzuladen, Einladungen für diejenigen auf der Liste zu versenden, die neu sind, das Ablaufdatum für diejenigen, die zurückkehren, zu verlängern und die Konten für die Institution zu sperren, die es sind nicht mehr in der Liste.

Sicher, als Benutzer könnte ich jemand anderem Zugriff gewähren, aber das gilt auch für jeden anderen Dienst. Selbst mit dem vorhandenen System konnte ich mich zu Hause am Laptop eines anderen anmelden. Sie werden nicht wirklich etwas verloren haben.

E-Mail an die Institution per E-Mail mit einem Link, der ein kurzlebiges Cookie (3 Tage) in ihrem Browser erstellt. Dies ist eine einmalige Verwendung. Institutionen haben fast immer eine E-Mail. Erlauben Sie ihnen, die E-Mail-Adresse ihrer Institution einzugeben. Dies verhindert, dass das Journal mit Passwörtern im System umgehen muss, und ermöglicht es Professoren, an die Arbeit zu gehen.

Ich gehe davon aus, dass Sie sich keine Sorgen darüber machen, dass hohe Geldsummen gestohlen werden (wie bei einem Bankgeschäft). Wenn Ihnen die tatsächliche 2-Faktor-Authentifizierung oder sogar das "physische Werden" (Kartenleser) zu viel ist, wie wäre es damit:

• Implementieren Sie eine regelmäßige Anmelde- / Kennwortauthentifizierung (natürlich mit HTTPS)
• Nehmen Sie Ihr Sitzungscookie und erstellen Sie ein zweites Cookie, das aus Hash (session_cookie + IP + geheimes Salz) besteht.
• Wenn Sie Fügen Sie daher die SSL-Sitzungs-ID zu diesem Hash hinzu (der das Schließen des Browsers nicht fortsetzt, was für Sie gut ist). Dies kann zu Unannehmlichkeiten führen, wenn eine Partei eine Neuverhandlung einleitet (wodurch Sie eine neue Sitzungs-ID erhalten und den Benutzer gezwungen werden, sich erneut anzumelden).
• Neben der Überprüfung des Sitzungscookies überprüfen Sie auch die Client-IP für jede einzelne Anforderung mit diesem zweiten Informationsbit (das, wie gesagt, ein zweites Cookie sein oder mit dem ersten verkettet sein kann, spielt keine Rolle). .

Jetzt kann der Benutzer das Cookie nach Herzenslust weitergeben, und niemand kann es verwenden, es sei denn, er kann auch die IP-Adresse fälschen (in diesem Szenario eher unwahrscheinlich; wahrscheinlich viel schwieriger) als der ursprüngliche Benutzer nur Inhalte weiterleitet, die er rechtmäßig heruntergeladen hat) und / oder die SSL-Sitzungs-ID (unmöglich).

Da es noch niemand erwähnt hat, wäre Browser-Fingerabdruck eine andere Schwierigkeit, ein Cookie an anderer Stelle zu verwenden. Grundsätzlich müssen Sie die Eigenschaften der verwendeten Software und Hardware untersuchen, die auf irgendeine Weise durchgesickert sind, und diese als "Fingerabdruck" verwenden, um das verwendete Gerät zu identifizieren.

Natürlich müssen Sie das Gerät senden Irgendwann einen Fingerabdruck auf Ihren Server, damit Sie überprüfen können, ob eine Sitzung nicht in einem anderen Browser und / oder Gerät verwendet wurde, sodass ein entschlossener Angreifer zu diesem Zeitpunkt versuchen könnte, die Daten so zu ändern, dass sie den von gesendeten Informationen entsprechen der Browser des tatsächlichen Benutzers. Abhängig von Ihrer Implementierung kann dies jedoch verwendet werden, um die Messlatte zumindest etwas höher zu legen.

Eine Cookie-basierte Lösung hindert Benutzer nicht daran, ihre Konten zu verkaufen / zu vermieten. Eine bessere Lösung wäre eine serververwaltete 2-Faktor-Authentifizierung basierend auf der IP-Adresse:

• Ermöglichen Sie der Registrierung von Konten
• Wenn Sie sich anmelden oder versuchen, ein Anmelde-Cookie außerhalb dieses Satzes zu verwenden, wird ein E-Mail-Bestätigungslink mit einer Erinnerung angezeigt, um unbefugten Zugriff zu verhindern.
• Wenn das neue Der Bereich wird bestätigt, er wird zu den autorisierten Speicherorten hinzugefügt und der älteste in der Liste wird entfernt, um Platz zu schaffen.

Verwalten einer 2-Faktor-Authentifizierungsdatei auf dem Computer des Endbenutzers funktioniert nicht, da der Endbenutzer diese Datei auch verkaufen könnte. Daher muss die 2-Faktor-Authentifizierung serverseitig erfolgen.

Profilieren Sie auch die Spezialisierungs- und Zugriffsfelder der Endbenutzer. Wenn beispielsweise ein Konto eines Physikprofessors plötzlich mit dem Herunterladen von Wirtschafts- und Soziologiepapieren beginnt, sperren Sie es offensichtlich.

Messdatenmengen (ähnlich wie bei mobilen Datenplänen) für Downloads pro Konto. Beispielsweise wird das erste halbe Gigabyte an Artikeln, die ein Benutzer jede Woche herunterlädt, normal heruntergeladen. Danach werden die Downloads dieses Benutzers auf 200 KB / s gedrosselt (ändern Sie die Zahlen nach Belieben). Die meisten Zeitschriftenartikel sind nicht riesig und die Download-Drosselung würde die meisten normalen Benutzer nicht betreffen, wird sich jedoch für Bulk-Downloader als unglaublich frustrierend erweisen.

Sie können die von Ihrer Organisation signierte Client Certificate Authentication (SSL) verwenden. Dies sollte internetweit sein, ähnlich wie ein VPN, aber einfacher und billiger.