Open Data in Bibliotheken und Universitäten — wie es nicht sein sollte

Bibliothek, Data

Bibliotheken und Universitäten verfolgen seit einiger Zeit verstärkt eine Open Data Strategie — und das ist im Wesentlichen auch gut so. Gelegentlich täten sie aber gut daran, diese Daten nicht offen “herumliegen” zu lassen; v.a. dann, wenn es sich bei den Daten um Passwörter handelt. 

Mehrfach ist es mir in den letzten Monaten widerfahren: Ich melde mich bei bibliothekarischen Mailinglisten, internen Blogs und dergleichen an und bekomme darauf eine Bestätigungsmail, in der neben meinem gewählten Nutzernamen und der Emailadresse auch das Passwort im Klartext gelistet ist.

In allen Fällen handelte es sich dabei um von den jeweiligen universitären Rechenzentren bereitgestellte ‘Services’.

Vielleicht bin ich etwas empfindlich, aber gerade von Hochschulrechenzentren erwarte ich, dass sie sowohl Datenschutz als auch Datensicherheit ernst nehmen, dass sie auf dem aktuellen Stand sind und schon einmal etwas von Verschlüsselungstechniken, Public Keys, Hashwerten usw. gehört haben. Das vom Nutzer/von der Nutzerin gewählte Passwort sollte niemals, in keiner Datenbank, nirgendwo abgespeichert werden. Und es sollte auf keinen Fall in einer Mail verschickt werden. Das ist nicht nur schlechte Praxis. Das ist eine Fahrlässigkeit, die geradezu zum Datenmissbrauch einlädt.

Von solchen ‘Services’ sollte man sich sofort wieder abmelden. Bibliotheken sollten erwägen, ihre Mailinglisten und Blogs nicht durch die universitäre Infrastruktur bereitzustellen, sondern durch Anbieter, die wissen, wie man verantwortungsvoll mit Daten umgeht. Und nicht zuletzt bleibt die Frage, wie Bibliotheken die Passwörter ihrer NutzerInnen verwalten?

Advertisements

3 thoughts on “Open Data in Bibliotheken und Universitäten — wie es nicht sein sollte

  1. Gemach! Ich denke nicht, daß Deine Beobachtungen einen vernünftigen Rückschluß auf die Kompetenz der Betreiber-RZ zulassen.

    Die absolute Forderung nach Ablage von Passworten nur als Hash ist nicht immer praktikabel (der von Dir verlinkte Wikipedia-Artikel ist übrigens nicht sonderlich gut – die QS mäkelt fehlende Belege an, schon der erste Absatz vermischt Identifikation, Authentifikation und Autorisation unglücklich): so gibt es Verfahren, die auch ohne Transportverschlüsselung eine relativ sichere Authentfikation ermöglichen (zB. CRAM-MD5), dabei aber nicht nur auf die sicheren Hashes der Passworte zurückgreifen können. Besser liegen Klartext-Passworte auf der Platte, als daß sie über die Leitung gehen.

    Zum anderen stellt jede Form von Sicherheitsmechanismen einen Mehraufwand dar, der ganz nach dem Schneier’schen Trade Off abgewogen sein will. Im konkreten Fall der Registrierung für Mailinglisten und Blogs träte dieser vor allem am Help-Desk auf: Nutzer/in kennt Benutzername und/oder Passwort nicht mehr, Nutzer/in weiß nicht was PGP, GnuPG oder S/MIME ist.

    Blog und Mailinglisten sind auf Grund ihres öffentlichen Charakters dabei durchgängig der Minimum Security zuzurechnen, so daß Aufwände für kryptographische Sicherung der Benachrichtigungs-eMails zu vernachlässigen sind, da der Transportweg hinreichend sicher sein sollte. Wichtiger sind hier hinreichend lange und zufällige Passwörter, die nicht per Brute Force zu knacken sind – die Passworterzeugung sollte also gerade nicht den Nutzer/inne/n überlassen sein.

    Würden also wertvolle Passwörter (Zugriff auf Mail, Fileshares, Server) in der von Dir beschriebenen Form transportiert werden, könnte ich Deiner Forderung zustimmen, sonst plädiere ich für ein Abwägen.

  2. I beg to disagree… nicht hinsichtlich der Kompetenzen der Betreiber von HRZs, aber hinsichtlich drei angeführter Punkte:

    Mailinglisten etc. sind als Minimum Security Cases einzustufen: Wenn dem so ist (m.E. hast du natürlich grundsätzlich recht, in den veranlassenden Fällen handelt es sich jedoch nicht um öffentliche Foren!), dann frage ich mich allerdings, warum überhaupt Passwörter abgefragt werden? Dann reichte es hin, neben der eMail-Adresse nach dem Vornamen, dem Geburtsjahr oder einer simplen Zahlenfolge à la “123” oder “666” zu fragen. Dass diesen Diensten allerdings eine geringe Sicherheitsstufe zugesprochen wird, davon ist nirgends bei der Registrierung die Rede. Im Gegenteil: sobald ein Dienst von mir ein “Passwort” verlangt (zumal eines, das mindestens 8, aber nicht mehr als 9 Zeichen, davon höchstens drei Buchstaben, zwei Sonderzeichen, usw. usf. enthält) , vertraue ich darauf, dass mein Passwort (und alles andere, was ich noch anzugeben habe) als sensible Information angesehen und entsprechend verarbeitet wird.

    Forderung von sichereren Passwörtern? Es nützt dann m.E. gar nichts, solch hochkomplexe Passwörter einzufordern (schon gar nicht bei den genannten MSCs), dann aber diese Passwörter im Klartext fröhlich per eMail in der Welt herumzuschicken oder “auf der Platte liegen zu haben”. Ich will niemandem zu nahe treten, aber wenn Banken wie Chase und Kaufhausketten wie Target ihre Festplatten nicht 100% sicher kriegen, dann zweifle ich daran, dass das Bibliotheken und Universitäten gelingt. Sie sind vielleicht nur nicht so im Fokus?

    Und schließlich:

    Benutzer zum Helpdesk zitieren wegen vergessener Passwörter? Warum sollten wir überhaupt verlangen, dass unsere NutzerInnen am sog. Help Desk aufschlagen, nur weil sie ihr Passwort, ihren Nutzungsnamen oder beides vergessen haben? Wer von uns hat schon Lust, nach Mountain View zu fahren, nur weil wir unser gmail Passwort vergessen haben?
    Geht es nicht anders?
    (Natürlich, und auch wenn es initial etwas Mehraufwand wäre — dieser amortisiert sich recht schnell durch geringere Anfragen am Help Desk.)

  3. Ohne den konkreten Fall zu betrachten, wird das zu nichts führen – deswegen nur noch kurze Repliken:

    ad Warum überhaupt Passwörter / Sichere Passwörter / Verarbeitung von Passwörtern

    Mailman begründet die Vergabe von Passwörtern folgendermaßen: “Sie können weiter unten ein Passwort eingeben. Dieses Passwort bietet nur eine geringe Sicherheit, sollte aber verhindern, dass andere Ihr Abonnement manipulieren. Verwenden Sie kein wertvolles Passwort, da es ab und zu im Klartext an Sie geschickt wird!”

    Bei den zufällig generierten Passwörter (die eben gerade nicht >10 Zeichen mit möglichst großer Entropie lang sein müssen) besteht der Vorteil darin, daß es nicht Password, 123456 oder vorhersagbar eine Jahreszahl ist.

    Grundsätzlich sollte man hier ein gewisses Mißtrauen an den Tag legen – genau deswegen nutzt man für jeden Dienst ein spezielles Passwort (und wenn man ganz sicher gehen will: speziellen Benutzernamen und eMail-Adresse).

    ad Passwort-Recovery via Helpdesk

    Natürlich kann man Passwort-Recovery automatisieren und wird dies auch tun – das bringt aber an anderer Stelle (u.a. beim Nutzenden) Aufwände: es müssen alternative Kontaktdaten hinterlegt (und gepflegt!) werden, die jeweilige Person muß sich an seine genutzte eMail-Adresse erinnern etc.

    Der Vergleich von einem Google-Account (der ja SSO-Funktionen für zahlreiche Dienste bietet) und einem Mailinglisten-/Blog-Account, der Einstellungen für einen einzigen Dienst beinhaltet und von dem man im Laufe des Lebens nicht nur einen ansammelt, ist dann der Vergleich zwischen Wassermelone und Kumquats.

    Behandelt man beides gleich, geht man einen schlechten Trade Off ein.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s