Onleihe HTTPS

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

  • Eine Browsermeldung "diese Verbindung ist sicher" nützt mir wenig, wenn ich darüber vergesse (oder es nicht weiß), dass es Spyware u.ä. gibt, die ich mir unbemerkt installiert habe und welche Formulareingaben bereits direkt bei der Eingabe vor dem Absenden abfängt. Da nützt mir die "sichere" Verbindung nichts.


    Tatsächlich gibt das einen falschen Eindruck von Sicherheit, die nicht gegeben ist. Das macht die Sache nicht besser.


    Und auch der Blick auf den eigenen Router hilft nur bedingt - wenn ich da an die Geschichte vor einigen Monaten denke, als es den Versuch gab, spezielle Routertypen der Telekom zu kapern.


    Das ist so eine typische Denke, wie man sie eben auch bei meiner Bibliothek findet: User sind doof und machen sowieso alles falsch, also hält man sich eine Hintertür offen. Die DTAG ist da notorisch :(


    Im Vergleich dazu sind Passwörter und Leselisten von Onleihe-Nutzern relativ uninteressant. Natürlich finde ich es gut, wenn auch hier möglichst sichere Verbindungen geschaffen werden. Das kann aber nur die eine Seite sein.


    Ich denke, wir sollten uns bewußt machen, daß es keine "uninteressanten" Daten gibt. Hat man genug scheinbar Uninteressantes, kann man damit eine Menge Schindluder treiben. Ich habe mal ein paar Versuche mit meinem aktuellen Merkzettel (aus dem Helferchen) gemacht. Es war beunruhigend.


    Wenn technisch versierte Anbieter möglichst sichere Verbindungen und Prozesse etablieren, ist das natürlich kein Allheilmittel. Wenn Nutzer ihre Daten rechts und links am Weg liegen lassen, kann man den Leuten nur wenig helfen. Stehen allerdings sichere Wege zur Verfügung, geht es nur (haha) noch darum, die User zu sensibilisieren.

  • Wenn wir das Update installiert haben wird auch definitiv die Funktion in Betrieb genommen.


    Sehr gut :)


    Was die in deiner Bibliothek allerdings für ihre Kunden buchen erschließt sich mir nicht so recht. Weil Vormerkungen, Verlängerungen etc. erledigt man über das Lokalsystem und da braucht man kein Passwort Und wenn der Kunde die Ausleihen in der Onleihe nicht selber erledigen kann, dann weiß ich auch nicht, ob ihm geholfen ist wenn der Ausleihvorgang von jemand anderem durchgeführt wird.


    Offenbar erledigen die alle möglichen Dinge für ihre Nutzer, vom Aktualisieren der Daten bis hin zur eigentlichen Ausleihe on- wie offline, auch auf telefonische Bitte. So recht schlau bin ich daraus nicht geworden, weil ich das Bibliothekssystem natürlich nicht kenne und auch keine guten Aussagen bekommen habe. Ich vermute, bei dieser Bibliothek hängt es vor allem an den Bibliotheksmitarbeitern. Als ich meinen Ausweis geholt habe, haben sie fröhlich zugegeben, überhaupt keine Ahnung "von Computern" zu haben. Die Onleihe wurde ihnen scheinbar von der Stadtverwaltung aufgedrückt, aber das Interesse ging (zumindest damals) gegen Null.

  • Inzwischen etwas offtopic:

    Offenbar erledigen die alle möglichen Dinge für ihre Nutzer, vom Aktualisieren der Daten bis hin zur eigentlichen Ausleihe on- wie offline, auch auf telefonische Bitte.


    Da würde mich jetzt schon interessieren, was die für ein System einsetzen und wie die dort dann so arbeiten. Weil bei den Systemen, die ich so kenne geht das was du beschrieben hast auch ohne Kennwort (bis auf die Ausleihe in der Onleihe).

  • Weil bei den Systemen, die ich so kenne geht das was du beschrieben hast auch ohne Kennwort (bis auf die Ausleihe in der Onleihe).


    Habe ich das richtig verstanden: Bibliotheksmitarbeiter können in der Bücherei den PC einschalten und dann ohne eigenes Konto mit Passwort alles mögliche im Bibliothekssystem machen? ?( Oder bedeutet das, dass sie sich einmal ins System einloggen müssen und dann an alles rankommen ?

  • Habe ich das richtig verstanden: Bibliotheksmitarbeiter können in der Bücherei den PC einschalten und dann ohne eigenes Konto mit Passwort alles mögliche im Bibliothekssystem machen? Oder bedeutet das, dass sie sich einmal ins System einloggen müssen und dann an alles rankommen ?


    Das Bibliothekssystem ist natürlich mit Passwort geschützt und nur berechtigte Mitarbeiter haben Zugriff auf das Programm.
    Um ein Kundenkonto zu bearbeiten benötige ich jedoch nicht das Passwort des jeweiligen Kunden, welches der für den Online-Katalog verwendet. Sonst würden sichere PAsswörter keinen Sinn machen, wenn die Bibliothek das für alle Vorgänge bräuchte oder abfragen müsste. Der Kunde legt seine Karte vor und dann wird der Barcode eingelesen und die Medien werden verbucht oder Vormerkungen eingetragen, Verlängerungen erledigt. Und bei telefonischem Kontakt ruft man ein Konto dann eben über Name oder Kundennummer auf und erledigt dann das, was der Kunde von einem wünscht.

  • Danke für die Erklärung; wir sind hier nicht alle BibliothekarInnen :)

  • Gleich als Erstes: Ich muß bei dieser Bibliothek Abbitte leisten. Seit ich das letzte Mal geguckt habe, hat sich da Vieles geändert. Unter anderem kann man jetzt das Paßwort ändern. Vermutlich ist auch (fast) alles andere besser geworden. Mal gucken, ob das WLAN noch offen ist :D :evil:


    Da würde mich jetzt schon interessieren, was die für ein System einsetzen und wie die dort dann so arbeiten. Weil bei den Systemen, die ich so kenne geht das was du beschrieben hast auch ohne Kennwort (bis auf die Ausleihe in der Onleihe).


    -> PM.


    Ich habe dort zB mein Kennwort ändern lassen(!), weg vom Default, weil es anders nicht ging. Inzwischen geht das offenbar via Bibliothekskatalog, so daß es nicht noch eine Person gibt, die das PW kennt.


    Oder bedeutet das, dass sie sich einmal ins System einloggen müssen und dann an alles rankommen ?


    Zu dem Zeitpunkt gab es genau ein PW für Bibliotheksmitarbeiter. Wer das kannte, hatte Vollzugriff.


    Kein Problem, aber zumindest alle Bibliothekskunden - und hoffentlich dort noch nie nach den Passwort gefragt worden.


    Äh, doch :) Aber bei noch einer anderen Bibliothek, nicht der o.g. Als ich das monierte, bekam ich die schnippische Antwort, man könne es auch zurücksetzen, dann müsse man nicht fragen. Ich habe mein Konto da aufgelöst.

  • Zu dem Zeitpunkt gab es genau ein PW für Bibliotheksmitarbeiter. Wer das kannte, hatte Vollzugriff.


    Da normal nur Mitarbeiter auf das entsprechende Programm zugreifen können, ist das ja nicht verwerflich. Im Bereich der Ausleihe braucht man ja Vollzugrif auf alle Ausleihfunktionalitäten und sollte auch Änderungen an den Stamm-Daten vornehmen können (ab und zu ziehen die Leute ja z.B. um und wollen die Kontaktdaten aktualisierne lassen)


    Äh, doch Aber bei noch einer anderen Bibliothek, nicht der o.g. Als ich das monierte, bekam ich die schnippische Antwort, man könne es auch zurücksetzen, dann müsse man nicht fragen. Ich habe mein Konto da aufgelöst


    Oha :/ Wenn bei uns jemand mit Onleihe-Problemen kommt und ich unterstützen soll ist eigentlich der einzige Punkt, wo man mal das Passwort braucht und wenn es was anderes wie das Geburtsdatum wäre, dann müsste es der Kunde definitiv selbst eintippen. Solange es Default ist kann ich das natürlich auch in den Kundendaten nachlesen oder abfragen... aber alles andere will ich nicht wissen.

  • Da normal nur Mitarbeiter auf das entsprechende Programm zugreifen können, ist das ja nicht verwerflic


    Da bin ich wieder bei meinem Feind-im-eigenen-Bett. Unterschiedliche PW bedeutet, daß man die Aktionen jede[s|r] Einzelnen nachvollziehen kann. Das ist nicht nötig, wenn alle gute Menschen sind, aber falls nicht, weiß man wenigstens, wen man fristlos feuern will.


    aber alles andere will ich nicht wissen.


    <3

  • Unterschiedliche PW bedeutet, daß man die Aktionen jede[s|r] Einzelnen nachvollziehen kann.


    Alles wird vom System (zumindest bei uns) nicht dokumentiert - zumindest nicht so ohne weiteres zu sehen. Ansonsten finde ich auch gut, dass die Mitarbeiter unterschiedliche Kennungen haben. Das erleichtert manchmal einfach die Fehlersuche - weil man weiß, wen man ansprechen muss.


    Das hat jetzt aber nix mehr mit https zu tun... wer sich tiefergehend mit den internen Abläufen einer Bibliothek befassen möchte, der fragt am Besten bei der Bibliothek seines Vertrauens nach :saint:

  • Das hat jetzt aber nix mehr mit https zu tun... wer sich tiefergehend mit den internen Abläufen einer Bibliothek befassen möchte, der fragt am Besten bei der Bibliothek seines Vertrauens nach


    Och, hier haben aber alle was davon. Außerdem sind hier Bibliothekar(in)e(n) aus verschiedenen Bibliotheken.


  • Dieser HTTP-Request beinhaltet die Formularparameter als POST-Elemente im Klartext.
    ... Nur wenn die Formularseite bereits SSL-Verschlüsselt ausgeliefert wird, werden alle folgenden Aktionen auch so verarbeitet.


    Hallo

    fschoene

    , wie kommst Du darauf? Hättest Du bitte ne Idee oder irgendwelche Quellen dazu?


    Nach meinem Kenntnisstand wird bei einem

    https

    -Aufruf (wie er aus dem Login-Formular erfolgt),
    vom Browser zuerst der Tunnel verhandelt/aufgebaut und dann die Daten gesichert übertragen. Zumindest sieht das mein Netzwerk-"Siniffer" so und die bisher von mir gefundenen Suchmaschinen-Ergebnisse.


    Dennoch gibt es (genügend) Argumente gegen "gemischte" HTTP & HTTPS Seiten, doch diese halte ich im Zusammenhang mit der ONLEIHE für vernachlässigbar. Weshalb ich finde, dass moderne Browser, wie der FireFox zurecht Alarm schlagen! Das Ziel ist doch immer, dass sich der Benutzer klar macht, klar machen muß: vertraue ich der gerade aufgerufenen Seite, kann ich die möglichen Sicherheitslücken akzeptieren - oder besser nicht und nix wie weg hier!?


    Dass das sogar von Bibliotheks/Anbieterseite als "HTTP Wahn" abgetan wird, erstaunt und verwundert mich zutiefst - mir war nicht klar, das man auch Technologien mobben kann - wieder dazu gelernt ;)


    Und dann mußte ich noch erfahren, dass selbst die (nötige) Anmeldung hier im UserForum, https-los, rein über http und somit ungesichert erfolgt - also, sagte ich mir, was kann ich dann von so einer Agglomeration* schon erwarten...


    Schönen Tag
    kg


    *Zusammenballung, Anhäufung
    "no brain - no pain" -- sagte mir mal ein Admin ;)

  • Ich stimme kgsw.de hier zu. Divibib verharmlost hier Tatsachen und stellt Sie im falschen Licht dar. Zu behaupten, dass keine personenbezogenen Daten übermittelt werden ist einfach falsch. In den meisten Fällen ist doch das Passwort das Geburtsdatum!


    Dies dann noch als http Wahn abzutun grenzt an Frechheit.


    Nach der Umstellung von Firefox hat auch ein anderes Unternehmen ähnliche Argumente vorgebracht, ging aber noch einen Schritt weiter und drohte mit rechtlichen Schritten.
    Nachzulesen hier: https://www.golem.de/news/http…cher-ist-1703-126848.html


    Die Firma behauptet, dass Sie seit 15 Jahren sicher sei und die Warnung von Ff das Geschäft schädigt.


    Nachdem das Unternehmen Wellen geschlagen hat, wurde sie in kürzester Zeit gehackt und die Userdb und anderes gelöscht. Soviel zur Sicherheit.


    Die Umstellung von http auf https für den Userlogin kann auch in kurzer Zeit erfolgen. Hier wieder eine Nebelgranate zu werfen, zeugt nicht von großem Fachverstand.



    Weiterhin wird hier im Thread behauptet, man käme nicht leicht an solche Passwörter, die im Klartext über das Netz gesendet werden, da hier der Router Zuhause kompromitiert seien muss. Dem Stimme ich zwar zu, aber man Stelle sich einfach vor, dass man in einem Café sitzt mit freiem Wlan oder im Urlaub. In diesem Fall reicht eine App auf dem Smartphone, um jeden Verkehr mitzulesen. Dazu braucht der böse Bube nicht einmal Fachkenntnisse, sondern muss nur eine Suchmaschine bedienen können.


    Abschließend möchte ich Divibib bitten die Priorisierung der Umsetzung von http auf https nochmals zu überdenken.


    Falls Divibib eine SSL Ca benötigt. Let's Encrypt ist kostenlos auch für Unternehmen.
    Und falls Divibib Probleme mit der 90 tägigen Ablauffrist der Let's Encrypt Zertifikate hat, stelle ich sogar mein Script zur automatischen "Verlängerung" bereit.

    • Offizieller Beitrag

    Guten morgen Ibiza123,


    Zitat von Ibiza123

    Ich stimme kgsw.de hier zu. Divibib verharmlost hier Tatsachen und stellt Sie im falschen Licht dar. Zu behaupten, dass keine personenbezogenen Daten übermittelt werden ist einfach falsch. In den meisten Fällen ist doch das Passwort das Geburtsdatum!


    Es ist laut den Anforderungen der jeweiligen Software vor Ort(!) id.R. als Default das Geburtsdatum. Dies wird aber als Passwort übermittelt. Das Passwort kann - je nach Software-Anbieter (!) - auch anders lauten. Daher ist es nicht "per se" ein Datum.
    Gerne dazu mit der Heimatbibliothek sprechen, diese gibt sicher gerne Auskunft zu Ihrem jeweiligen Software-Anbieter.


    Zitat von Ibiza123


    Dies dann noch als http Wahn abzutun grenzt an Frechheit.


    Bitte bei solchen Vergleichen explizit angeben, von wem was genau kommt, Danke.


    Zitat von Ibiza123


    Nach der Umstellung von Firefox hat auch ein anderes Unternehmen ähnliche Argumente vorgebracht, ging aber noch einen Schritt weiter und drohte mit rechtlichen Schritten.
    Nachzulesen hier: https://www.golem.de/news/http…cher-ist-1703-126848.html


    Haben wir nicht vor. Wozu auch? Das "Anliegen" ist ja grundsätzlich gerechtfertigt.


    Zitat von Ibiza123


    Die Umstellung von http auf https für den Userlogin kann auch in kurzer Zeit erfolgen. Hier wieder eine Nebelgranate zu werfen, zeugt nicht von großem Fachverstand.


    Nebelgranaten kommen erfahrungsgemäß oft von allen Seiten.


    Zitat von Ibiza123


    Falls Divibib eine SSL Ca benötigt. Let's Encrypt ist kostenlos auch für Unternehmen.
    Und falls Divibib Probleme mit der 90 tägigen Ablauffrist der Let's Encrypt Zertifikate hat, stelle ich sogar mein Script zur automatischen "Verlängerung" bereit.


    Wo auch immer das jeweilige Verfahren herkommt - es muss de facto von irgendwem umgestellt werden. Es gibt knapp 3000 Bibliotheken, die in nicht ganz 200 Onleihen / Verbünden gruppiert oder als Einzelonleihe aufgesetzt sind. Davon sind etwa Drei-Viertel mit entsprechenden Schnittstellen versehen. Eine kleine Anzahl an Bibliotheken nutzt eigene Domains.
    Teilweise umzustellen ist alles andere als sinnvoll, eine "Zwischenlösung" zu fahren macht doppelten Aufwand.



    Ich habe das nachstehende Zitat an den Schluss gesetzt.

    Zitat von Ibiza123


    Abschließend möchte ich Divibib bitten die Priorisierung der Umsetzung von http auf https nochmals zu überdenken.


    Wir möchten die Nutzerinnen bitten, noch etwas Geduld zu haben, aber wir werden hier auch nicht jeden Tag den Stand interner Besprechungen reinstellen. Die Priorität wird bereits überdacht, wie wir es auch im entsprechenden Thema geschrieben haben!
    Die divibib hat immer und immer wieder bewiesen, dass Sie mehr als willig und bereit ist, auf aktuelle Situationen und Anfragen zu reagieren und Projekte neu zu bewerten.
    Bitte also künftig erst informieren oder bei der Heimatbibliothek anfragen.


    aus => Die Onleihe und HTTPS

    Zitat von divibib-Support


    Es gab bereits vor dieser Meldung Überlegungen, die Onleihe komplett auf HTTPS umzusetzen und aufgrund der Unsicherheit, die durch diese Meldung entstanden ist, bewerten wir das Thema selbstverständlich neu.


    Freundliche Grüße und allen einen guten Start in die Woche
    divibib-Support

  • Ich stimme kgsw.de hier zu. Divibib verharmlost hier Tatsachen und stellt Sie im falschen Licht dar. Zu behaupten, dass keine personenbezogenen Daten übermittelt werden ist einfach falsch.


    Übermittelt wird - per HTTPS - an die DiViBib eine Nummer (Nutzernummer) und ein PW. Die DiViBib baut daraus einen Hash, der - nicht per HTTPS - an die Bibliothek weitergeleitet wird. Der Hash wird im System der Bibliothek gegen die vorhandenen Nutzerdaten abgeglichen, indem die Hashes verglichen werden. Die Bibliothek antwortet darauf mit einem "Nutzer gehört mir (nicht)" (im Grund ein Bool).


    Wenn das Salz nicht vergessen wurde (und davon gehe ich aus), werden hier keine personenbezogenen Daten unverschlüsselt übermittelt.


    Btw: Gerade die Tatsache, daß die Bibliothek nur mit einem Ja/Nein antwortet, bedingt, daß die DiViBib keinen Grund für ein fehlgeschlagenes Login angeben kann. Deshalb müssen "kann nicht einloggen"-Fehlermeldungen immer in der Heimatbibliothek landen.


    Nachdem das Unternehmen Wellen geschlagen hat, wurde sie in kürzester Zeit gehackt und die Userdb und anderes gelöscht. Soviel zur Sicherheit.


    Die DiViBib hat keine Userdaten, die ausgelesen werden könnten. Sie hat einen Hash-Algorithmus. Wer ein bißchen im ersten Semester aufgepaßt hat, weiß, daß dieser Algo öffentlich sein darf und sogar soll.


    @divibib-support: Bitte korrigieren, wenn ich das falsch erinnere. Intern verwaltet die DiViBib lediglich die Konten, die aber nicht mit persönlichen Daten verknüpft sind, sondern mit unpersönlichen Kennziffern.


    Die Umstellung von http auf https für den Userlogin kann auch in kurzer Zeit erfolgen.


    Die Daten, die notwendig übermittelt werden (Benutzernummer, PW), sind bereits verschlüsselt. Es herrscht, wenn man von den Fakten ausgeht, keine Eile. Die Fehlermeldung im FF ist lästig, aber, wenn man die Fakten betrachtet, auch nur das.


    Café sitzt mit freiem Wlan oder im Urlaub


    Äh, was? Wer das macht, ohne VPN zu nutzen, dem hilft das schönste HTTPS nichts. Ich wiederhole gern: Gegen den Feind im eigenen Haus ist man machtlos. Ein ungesichertes WLAN zu nutzen ist nichts anderes, als seinen eigenen Router offen zu lassen.

    • Offizieller Beitrag

    Hallo zusammen,


    Zitat von Annanymous


    Die DiViBib baut daraus einen Hash, der - nicht per HTTPS - an die Bibliothek weitergeleitet wird.


    Das hängt auch von der Bibliothek ab; sofern jedoch irgendmöglich liegen die Schnittstellen bei uns mit HTTPS ab.


    Zitat von Annanymous


    @divibib-support: Bitte korrigieren, wenn ich das falsch erinnere. Intern verwaltet die DiViBib lediglich die Konten, die aber nicht mit persönlichen Daten verknüpft sind, sondern mit unpersönlichen Kennziffern.


    Ja, eben jener "Hash-Wert".
    Für uns ist der "User" gleichbedeutend mit seinem "Konto" und nur über dieses als solcher "identifiziert".


    Freundliche Grüße
    divibib-Support

  • Guten morgen Ibiza123,
    Es ist laut den Anforderungen der jeweiligen Software vor Ort(!) id.R. als Default das Geburtsdatum. Dies wird aber als Passwort übermittelt. Das Passwort kann - je nach Software-Anbieter (!) - auch anders lauten. Daher ist es nicht "per se" ein Datum.
    Gerne dazu mit der Heimatbibliothek sprechen, diese gibt sicher gerne Auskunft zu Ihrem jeweiligen Software-Anbieter.


    Zitat von Ibiza123

    In den meisten Fällen ist doch das Passwort das Geburtsdatum!


    Deshalb in den "meisten Fällen".



    Bitte bei solchen Vergleichen explizit angeben, von wem was genau kommt, Danke.


    Das nehme ich zurück und nenne es nur Verharmlosung. Bei so vielen Posts und Divibib Hintergrundwissen, dachte ich, dass Annanymous zu Divibib gehört. Vielleicht mal ein Praktikant im 2. Semester?



    Haben wir nicht vor. Wozu auch? Das "Anliegen" ist ja grundsätzlich gerechtfertigt.


    Habe ich nicht behauptet, sondern nur geschrieben, dass dieses Unternehmen im verlinkten Artikel dies so gemacht hat.



    Nebelgranaten kommen erfahrungsgemäß oft von allen Seiten.


    Worauf wird hier Bezug genommen?



    Wo auch immer das jeweilige Verfahren herkommt - es muss de facto von irgendwem umgestellt werden. Es gibt knapp 3000 Bibliotheken, die in nicht ganz 200 Onleihen / Verbünden gruppiert oder als Einzelonleihe aufgesetzt sind. Davon sind etwa Drei-Viertel mit entsprechenden Schnittstellen versehen. Eine kleine Anzahl an Bibliotheken nutzt eigene Domains.
    Teilweise umzustellen ist alles andere als sinnvoll, eine "Zwischenlösung" zu fahren macht doppelten Aufwand.


    Ich hoffe ich versteh das jetzt richtig. Das Divibib auf onleihe.de für Drei-Viertel von 3000 Bibliotheken die Anmeldung hosted. Also die Anmeldeseite auf euren Servern zur Verfügung stehen, die momentan nicht verschlüsselt ist.
    Und der kleine Rest eigene Server hat eigene Problemen, die euch nicht betreffen?



    Wenn meine Annahme oben richtig ist, warum sollte ich meine Heimatbib fragen, ob sie Eure Anmeldeseite auf HTTPS umstellt?



    Übermittelt wird - per HTTPS - an die DiViBib eine Nummer (Nutzernummer) und ein PW. Die DiViBib baut daraus einen Hash, der - nicht per HTTPS - an die Bibliothek weitergeleitet wird. Der Hash wird im System der Bibliothek gegen die vorhandenen Nutzerdaten abgeglichen, indem die Hashes verglichen werden. Die Bibliothek antwortet darauf mit einem "Nutzer gehört mir (nicht)" (im Grund ein Bool).


    In erster Linie ist es mir egal, wie die Daten von der Heimatbib zu Divibib und umgekehrt kommen, in diesem Thread geht es um die Anmeldeseite und wenn hier Klartextversendet wird, dann kann danach gehasht werden mit oder ohne Salt. Völlig egal.
    Der Umstand, dass jemand ohne große IT Kenntnisse das Passwort mitlesen kann und damit Zugriff auf das Konto hat, sollte doch klar sein.



    Die DiViBib hat keine Userdaten, die ausgelesen werden könnten. Sie hat einen Hash-Algorithmus. Wer ein bißchen im ersten Semester aufgepaßt hat, weiß, daß dieser Algo öffentlich sein darf und sogar soll.


    Nochmal Lesen, vielleicht verstehen Sie es dann. Wer ein bisschen beim Lesen aufgepasst hat, kann erkennen, dass ich mich nur auf das Unternehmen im verlinkten Artikel bezogen habe.
    Was bei Divibib im Hintergrund läuft und beschädigt werden kann, kann z. B. die Userdb des Opencms sein oder was auch immer. Das hat in erster Linie nichts mit dem fehlenden https Support zu tun, sondern mit weiteren Sicherheitslücken, wenn es schon an der Basis fehlt.
    Leider weiß ich nicht, was Sie mit Algorithmus meinen? Der Hash Algorithmus im Allgemeinen oder die Hashes die dadurch generiert werden? Im ersten Fall ist es nicht schlimm, wenn der benutzte Hash Algorithmus genannt wird, aber dazu raten würde ich nicht (Es stellt sich natürlich die Frage ob hier die Salt Funktion auch öffentlich gemacht werden soll Annanymous, vllt. Fragen wir jmd. aus dem 2. Semester ;) ). Im zweiten Fall würde ich strengstens davon abraten auch zur Zeit Hashs aus sicheren Hashing Funktionen öffentlich zu machen.


    Administrator: Bitte korrigieren, wenn ich das falsch erinnere. Intern verwaltet die DiViBib lediglich die Konten, die aber nicht mit persönlichen Daten verknüpft sind, sondern mit unpersönlichen Kennziffern.


    Und das wird nicht in einer DB gespeichert? Aber da schweifen wir wieder ab.



    Die Daten, die notwendig übermittelt werden (Benutzernummer, PW), sind bereits verschlüsselt. Es herrscht, wenn man von den Fakten ausgeht, keine Eile. Die Fehlermeldung im FF ist lästig, aber, wenn man die Fakten betrachtet, auch nur das.


    Jetzt sind wir wieder am falschen Ende. Es geht um die Anmeldeseite, dort werden Daten unverschlüsselt übermittelt. Ich beziehe mich hier insbesondere auf das Geburtsdatum im Passwort. s. o. Aber im Allgemeinen sollte es einfach sein, dass Passwörter im Klartext durchs Netz fliegen. (Hier jetzt Beispiele zu nennen bei denen es auch so ist, wäre nicht hilfreich)



    Äh, was? Wer das macht, ohne VPN zu nutzen, dem hilft das schönste HTTPS nichts. Ich wiederhole gern: Gegen den Feind im eigenen Haus ist man machtlos. Ein ungesichertes WLAN zu nutzen ist nichts anderes, als seinen eigenen Router offen zu lassen.


    [/quote]
    Dass dieser Kommentar in irgendeiner Form kommt, war klar Aluhut^^. Also solange HTTPS korrekt umgesetzt wird, brauche ich kein VPN um meine Anmeldedaten zu schützen. Einen MiM Angriff wäre zu aufwändig, solange niemand physikalischen Zugriff auf mein Gerät hat.
    Der Vergleich mit dem Feind im eigenen Haus ist im Falle des freien Wlans nicht passend. Solange mein Gerät(PC, Notebook, Tablet,Smartphone, You name it) physikalisch sicher ist. ist HTTPS genauso sicher wie VPN, nur nicht so umständlich. Bei SSL Interception hat man hierbei i. d. R. das gleiche Problem. bekommt es aber bei https im Browser schön rot präsentiert. Bei VPN kommt es wiederum drauf an.


    Hallo zusammen,


    Das hängt auch von der Bibliothek ab; sofern jedoch irgendmöglich liegen die Schnittstellen bei uns mit HTTPS ab.


    Also nicht immer verschlüsselt, oder nicht immer über HTTPS, aber immer verschlüsselt. Schweift aber vom Thema ab, das muss man nicht beantworten. ;)


    Schöne Restwoche

    • Offizieller Beitrag

    Ich würde sagen, diese Detail-Diskussionen bringen hier a) nicht weiter und sind hier b) fehl am Platze (Stichwort: Userforum).
    Wer gerne genauere Auskünfte haben möchte, kann sich ggf. per Mail/Kontaktformular über die Heimatbibliothek an die Divibib wenden.


    Einigen wir uns darauf: Bei der Https-Umstellung gibt es noch etwas zu tun und die Divbib ist momentan dran. Durch Fragen/Diskussionen hier wird der Prozess auch nicht beschleunigt.
    Wer die Onleihe aktuell zu unsicher findet (egal ob berechtigt oder nicht), muss eben auf dieses Angebot verzichten.