Onleihe HTTPS

onleihe:hilfe
Aktuelle Meldungen finden Sie stets auf der :hilfeseite für die Onleihe.

  • Moin Zusammen,


    ich bekam eine Nutzeranfrage, die ich einfachheitshalber hier mal reinstellen möchte.


    Und zwar fragte ein Leser bei uns nach, warum denn bitteschön die Onleihe-Seite nicht HTTPS verwendet.
    Ja, warum nicht? Hat gewiss 'nen Grund, ich kenne ihn aber nicht.
    Um Hilfe zur Erleuchtung wird freundlich gebeten!


    MfG
    TimAlbrecht


  • Und zwar fragte ein Leser bei uns nach, warum denn bitteschön die Onleihe-Seite nicht HTTPS verwendet.


    Auf unserer Hilfeseite/FAQ steht folgendes:


    "Erfolgt das Einloggen bei der Onleihe über eine gesicherte Verbindung?


    Lediglich das Anmeldeformular zur Eingabe wird nicht
    gesichert übertragen. Das Absenden des Formulars und somit die
    Übertragung der Zugangsdaten erfolgt dann über eine gesicherte
    Verbindung."

  • Ich hab das mal wissen wollen, weil ich finde, dass es hier um durchaus sensible Daten geht. Die Antwort war, dass die DiViBib es für unnötig hält, weil das Formular für die PW-Abfrage ja gesichert sei. Ich fand das unbefriedigend.

  • ok, dank @gimiju jetzt nach nochmaligem durchsuchen der Hilfethemen, hab ich den Passus dann auch gefunden. Ist ja zumindest eine Aussage.
    Jetzt hatte ich dann auch genau den Gedanken von Anonymus, wobei ich denke, dass das tatsächlich so ausreicht, mit der Teil-Verschlüsselung.
    Abgesehen vom Passwort sehe ich da jetzt nicht DIE sensiblen Daten, abgesehen von der E-Mail-Adresse vllt., mit denen hier in der Onleihe gewirtschaftet wird,
    ohne jetzt einen Aufstand von wegen persönliche Daten anzetteln zu wollen.
    Generell bin ich auch eindeutig pro Nutzung HTTPS, eher zu oft als zu selten.

  • Lesegewohnheiten halte ich auch für ein sensibles Datum (ähnlich wie Suchanfragen in einer Suvhmaschine). Das ist wunderbar geeignet, Persönlichkeitsprofile zu erstellen. Es muss sich nur jemand die Mühe machen und die Kommunikation mitzuschneiden.

  • Abgesehen vom Passwort sehe ich da jetzt nicht DIE sensiblen Daten, abgesehen von der E-Mail-Adresse vllt., mit denen hier in der Onleihe gewirtschaftet wird,


    Dann lad mal ein Lehrbuch über Chemie (Oberstufe) und eines über $_radikale_religion herunter. Vielleicht noch ein paar über politische Attentate. Sollte jemand mitlesen, bist du in Schwierigkeiten.


    Es geht dabei nicht einmal darum, was man alles aus diesen Daten herauslesen kann oder was man herauslesen kann, wenn man diese Daten mit anderen korreliert (Website-Besuche, Emails etc). Entscheidend ist, daß alles, was nicht verschlüsselt ist, von den verschiedensten "interessierten Parteien" abgeschnorchelt und ausgewertet wird.


    Generell bin ich auch eindeutig pro Nutzung HTTPS, eher zu oft als zu selten.


    Yep.

    • Offizieller Beitrag

    Hallo zusammen,


    wir planen auch hier weitere Maßnahmen, aber aktuell sehen wir es als ausreichend an, wenn der Datenaustausch über https erfolgt. Die Eingabemaske selbst ist http. Bei ca 180 Onleihen, mit zig Webseiten, Weiterleitungen und Zertifikaten, etc. sind Anpassungen hierzu ein großes Thema.


    Es kommt hinzu, dass weiterhin bei vielen Bibliotheken das Passwort per Grundeinstellung recht simpel ist und die wenigsten Nutzer dies ändern oder nicht ändern können, weil nicht bei jedem OPAC eine Änderung des Passwortes möglich ist. Diese extreme Eingrenzung auf einen "Nummernkreis" ist in sich schon nicht sonderlich sensibel.


    Auf der anderen Seite kann ich mir gut vorstellen, dass eine Passwort-Vorgabe mit Sonderzeichen, Groß-/Kleinbuchstaben und Zahlen, sowie mindestens 8 Zeichen nicht zu Begeisterungsstürmen bei den meisten Nutzern führen wird.
    Denn eine "gesicherte oder verschlüsselte Verbindung ist kein Garant für Sicherheit, wenn dann doch wieder einfache Passwörter verwendet werden. Hier sind die Softwarehäuser und die Bibliotheken gefragt und das Thema kann schlussendlich auch nur in diesem Dreieck gelöst werden.


    Freundliche Grüße
    divibib-Support

  • Ein Schritt nach dem anderen führt auch weiter! Irgendwann kann man dann auch das Passwort besser sichern. Vorschlag für den nächsten Schritt in dieser Richtung: jede Bibliothek legt eine kurze Beschreibung / einen Link zur Änderung auf die Anmeldeseite im Browser (sofern das PW änderbar ist).
    Ich musste da auch schon ziemlich suchen ....

  • Vorschlag für den nächsten Schritt in dieser Richtung: jede Bibliothek legt eine kurze Beschreibung / einen Link zur Änderung auf die Anmeldeseite im Browser (sofern das PW änderbar ist).


    Ich kann jetzt nur für mein System sprechen, aber da ist es nicht möglich einfach mal da was zu Verlinken. Die CMS im Hintergrund sind recht komplex und nicht auf alles hat man dann nen Zugriff um da was zu ändern....

  • wir planen auch hier weitere Maßnahmen, aber aktuell sehen wir es als ausreichend an, wenn der Datenaustausch über https erfolgt. Die Eingabemaske selbst ist http. Bei ca 180 Onleihen, mit zig Webseiten, Weiterleitungen und Zertifikaten, etc. sind Anpassungen hierzu ein großes Thema.


    Wir reden ja nicht nur über Paßworte, sondern auch über den Abruf von Medien und den Seiten der Onleihe (DiViBib-seitig), zB um die Leselisten zu schützen. Ich denke, da ginge was.


    Ich kann jetzt nur für mein System sprechen, aber da ist es nicht möglich einfach mal da was zu Verlinken. Die CMS im Hintergrund sind recht komplex und nicht auf alles hat man dann nen Zugriff um da was zu ändern....


    Hast Du Zugriff auf die Frontpage, kannst da also etwas ändern? Falls ja, ist die Änderung trivial: Du würdest den nötigen Link zum OPAC aus einem anderen Browser kopieren und in der Frontpage einfügen. Bei einem CMS sollte Dir dazu ein Frontend ähnlich wie das der Forensoftware zur Verfügung stehen.

  • Auf die Seite der Divibib habe ich keinen Zugriff und da das im Verbund läuft landen wir vermutlich da schon in einer Sackgasse.
    Meine Äußerung bezog sich eher darauf, dass ich bei mir im Online-Katalog die Funktion zum Passwort ändern nicht rausziehen kann und auf der Startseite präsentieren. Die wird einem angezeigt, wenn man im Benutzerkonto eingeloggt ist, allerdings nur durch ein Symbol. Und das ist ne Seite vom ich im System des Katalogs auch nicht dran basteln kann weil die vom System im kompletten so ausgeliefert wird.

  • Hallo zusammen!
    Ich wollte die Diskussion um zwei Punkte ergänzen.

    • Webseiten mit HTTPS -Verschlüsselung erhalten bei Google ein besseres Ranking. Wer sich schon was zu Thema SEO gelesen hat, der weiß wie wichtig das Ranking bei Google ist.
    • Zudem nervt u. a. der Firefox, wenn eine Seite nicht auf HTTPS umgestellt ist. - Die Nutzer erhalten die Meldung, dass die Seite nicht sicher wäre.

    @ divibib-support: Es wäre schön, wenn die Umstellung auf HTTPS nicht allzu lange dauert.


    Beste Grüße
    s.foesel

  • Ups, da hatte ich wohl in meinem Post nicht genau genug hingeschaut. Der Anmeldeserver ist jetzt schon HTTPS, somit ist die Sicherheitsmeldung der Browser nicht berechtigt, siehe hier:
    Https und Passworte


    Das gilt allerdings nicht für die Daten des Forums: hier wird zwar ein sicheres Kennwort erzwungen, dieses dann aber per HTTP übermittelt.

    Einmal editiert, zuletzt von psturm ()

  • Also die Daten werden definitiv ungesichert übertragen. Da das Eingabeformular die Daten ungesichert per POST an https://upa.onleihe.de... übergibt. Erst von dort werden die Daten dann verschlüsselt weitergereicht.
    Das ist eindeutig zu wenig Sicherheit.


    Viele Grüße - F. Schöner

  • Ich verweise an dieser Stelle auf die Stellungnahme der Divibib im anderen Thread zu diesem Thema:

    Zitat

    Die Übertragung der Anmeldedaten erfolgt verschlüsselt per HTTPS, lediglich die Anmeldemaske als solche ist HTTP.Für die Browser ist dies nicht ersichtlich, daher ist es einfacher schlicht alles als HTTPS zu fordern.Über die Systeme der Onleihe ist aber eine Verknüpfung von z.B. Ausleihen mit personenbezogenen Daten nicht möglich, da von der divibib keine personenbezogenen Daten gespeichert werden. Nach erfolgreicher Authentifizierung des Bibliotheksnutzers erfolgt die weitere Verwaltung des Bibliotheksnutzers im Onleihe-System von divibib durch eine pseudonyme, mittels Hash-Wert generierte User-ID, die der divibib - oder Dritten - keine Rückschlüsse auf die Identität des Nutzers ermöglicht.  Dazu auch unsere "allgemeine Datenschutzerklärung" Somit gibt es im Datenverkehr zwischen der divibib und den Bibliotheken keine sensiblen, personenbezogenen Daten.


    In voller länger hier zu finden: Https und Passworte

  • Nochmal:
    Die Daten des Benutzers werden bei der Authentifizierung unverschlüsselt - also im Klartext - über das Internet an den Server der Onleihe übertragen. Erst dort wird dann eine verschlüsselte Verbindung zum LMS hergestellt.
    In der allgemeinen Datenschutzerklärung steht im Gegensatz dazu:

    Zitat

    Es wird ein verschlüsselter Kanal zur Nutzerdatenbank der Bibliotheken hergestellt, um den Bibliotheksnutzer unmittelbar durch seine Bibliothek authentifizieren zu lassen.


    Tatsächlich wird also keine unmittelbare, verschlüsselte Verbindung hergestellt.

  • Nochmal:
    Die Daten des Benutzers werden bei der Authentifizierung unverschlüsselt - also im Klartext - über das Internet an den Server der Onleihe übertragen. Erst dort wird dann eine verschlüsselte Verbindung zum LMS hergestellt.
    In der allgemeinen Datenschutzerklärung steht im Gegensatz dazu:


    Tatsächlich wird also keine unmittelbare, verschlüsselte Verbindung hergestellt.


    Wie kommst Du darauf?
    Wenn ich mir den Quelltext der Anmeldeseite anschau, find ich dort
    "div class="item-2"><div class="login">
    <form action="

    https://www.voebb.de/w3/divibib/access.rdr" method="post" accept-charset="ISO-8859-1"

    >
    <input type="hidden" name="tid" value="727352C534F2F1160A396988D27ED1F3"/>
    <input type="hidden" name="locale" value="de"/>
    <input type="hidden" name="login" value="x"/>
    ......
    Meine rudimentären Kenntnisse der Seitenprogrammierung sagen mir, dass damit von meinem Browser eine verschlüsselte Verbindung in Richtung voebb hergestellt wird. So wie es in der Datenschutzerklärung steht.

  • Der Ablauf ist so:
    Mit Absenden der Formulars wird vom Browser ein HTTP-Request an die im action-Attribut hinterlegte Adresse gesendet.
    Dieser HTTP-Request beinhaltet die Formularparameter als POST-Elemente im Klartext.
    Mit der Übergabe der Parameter durch den Webserver an das Script auf dem fernen Webserver werden die Daten im weiteren Verarbeitungsverlauf SSL-Verschlüsselt. Aber erst dann.
    Es ist eben nicht so, dass der Browser auf dem Client-Computer eine SSL-Verbindung aufbaut.
    Nur wenn die Formularseite bereits SSL-Verschlüsselt ausgeliefert wird, werden alle folgenden Aktionen auch so verarbeitet.