Viele Onlinedienste speichern neben dem Zugangsnamen und geheimen Passwort auch die „geheime“ Antwort auf eine Frage, die der Benutzer entweder selbst formulieren kann, oder die vom System vorgegeben ist.

Ich möchte hier erläutern, warum solch ein System kein sicheres System ist und keinesfalls verwendet werden sollte.

Zu unterscheiden ist zwischen zwei Varianten:
Der vorgegebenen Frage (bzw. einer kurzen Auswahl mehrerer Fragen) und der frei zu definierenden Frage.

Die vorgegebene Frage lautet z.B. „Wie ist der Geburtsname Ihrer Mutter“ oder „Wie heißt Ihr Geburtsort“. Beides keine besonders großen Geheimnisse.
Manchmal stehen 5 Fragen zur Auswahl, manchmal ist 1 vorgegeben. Der einzige Unterschied ist, dass es 5mal so aufwändig ist die Antwort auf 5 unsichere Fragen zu recherchieren, als die Antwort auf 1 Frage. 5 x unsicher ist aber noch lange nicht sicher.

Man kann natürlich auch der zu verifizierenden Person selbst die Formulierung nicht nur der Antwort, sondern auch der Frage überlassen.
Doch auch das ist keine gute Idee, denn meist wird er keine gute Frage formulieren können oder wollen. Denn was könnte eine gute Frage sein? Eigentlich nur etwas so privates und intimes, dass man es NIE einem anderen Menschen mitteilen würde. Doch gerade das wird natürlich NIEMAND an so einer Stelle eingeben und ggf. würde er/sie es auch keinem Call-Center-Agent mitteilen wollen. Alle Fragen und Antworten darauf sind also per se untauglich, da man Geheimnisse eben NICHT verrät.

In jedem Fall wird eine nicht besonders geheime Information auf eine bekannte oder einfache Frage zum Kriterium über den Identitätsnachweis einer Person.
Die richtige Antwort auf diese Fragen wird aber gerade als ein Kriterium für den Beweis der Identität herangezogen — wozu sollten sie sonst gut sein.
Eine grobe Gefährdung der Sicherheit persönlicher Daten!

Ein untaugliches Kriterium zum Identitätsnachweis wird aber auch dadurch nicht besser, dass es zusammen mit anderen kombiniert wird. Zumal man sich das konkrete Szenario eines Call-Center-Agents vorstellen muss, der einen genervten Anrufer an der Leitung hat, der ungeduldig ist, unfreundlich wird und sich darüber beschwert, warum das mit dem Zugang so kompliziert ist und man ihm nicht glaubt, dass er der Anrufer ist. Nicht nur Psychologen werden sich gut vorstellen können, das der geplagte Call Center Agent im Zweifel lieber dem Anrufer vertraut, als ihm nicht zu vertrauen, das Gespräch daduch in die Länge zu ziehen und den Kunden zu verärgern.

Warum aber sollte der Geburtsname der Mutter als Kriterium für Sicherheit taugen? Ich weiß es nicht, aber ich kann mir zahlreiche Möglichkeiten vorstellen, für jeden beliebigen Menschen den Geburtsnamen der Mutter zu erfahren:
Szenario 1: „Marktforschung“:
Anruf beim zu kompromittierenden selbst und Behauptung man möchte ein telefonisches Interview für Marktforrschungszwecke durchführen. Neben anderen unverfänglichen Fragen, die dem Gespräch Glaubwürdigkeit verleihen, wird die Frage nach dem Geburtsnamen der Mutter, ggf. auch nach dem Geburtsort etc. gestellt. Mit größter Wahrscheinlichkeit wird diese Information unbedenklich vom interviewten preisgegeben.

Szenario 2: „Gespräch mit dem Nachbarn„
Anruf beim Nachbarn der zu komprommittierden Person. Der Nachbar wird unter einem Vorwand in ein Gespräch verwickelt .… und wenn er die Person kennt — vielleicht sogar schon länger und auch mit der Familiensituation vertraut ist — nach den zu erschnüffelnden Informationen gefragt.

Szenario X:
Gespräche in denen die gewünschten Informationen zu erfragen sind lassen sich mit vielen anderen Menschen führen, mit Schulen, Behörden, Kollegen, Versicherungen, Vermietern, Arbeitgebern, Hobbyfreunden etc. .

Natürlich kann man auch im Internet suchen und bei Prominenten oder Menschen mit einem überdurchschnittlichen Selbstdarstellungsbedürfnis wird man auch dort Antwort auf die Fragen finden.

Also bitte: Sicherheitsverantwortliche aller Länder, beendet diesen Schwachsinn!

ACHTUNG: Dieser Artikel ist keine Anleitung zum Betrug und Missbrauch. Dieser Artikel ist eine Aufforderung an die für Datenschutz und –sicherheit Verantwortlichen solch schwachsinnigen „Sicherheitsmechanismen“ nicht mehr zu verwenden und auf geeignetere Verfahren zurückzugreifen.

Die Ursache lag wohl an einer Änderung des /etc/mysql/my.cnf die mit dem letzten Debian-Upgrade einherging. Genaugenommen stand nun in der Konfigurationsdatei wieder

bind-adress = 127.0.0.1

Was bewirkt der Eintrag? Nicht mehr, als dass der mysql-Server nur von der Maschine selbst auf der er läuft (localhost) aus erreichbar ist. Dies genügt meist, wenn diese Maschine auch der Webserver ist, auf der die Webprojekte php etc. laufen. Denn dann hat der Apache, der mittels eingebundenem php-Modul der Eigentümer der Prozesse ist, die auf mysql zugreifen die gleiche IP wie der mysql-Server.

Doch damit klappt natürlich der Zugriff auf die MySQL-Datenbank von einem anderen Rechner aus nicht — also auch nicht von dem Windows-Client an dem ich arbeite. Nun kann man natürlich einfach die Zugriffsbeschränkung deaktivieren und alles klappt wieder (nach einem Reload der Einstellungen in mysql). Doch vorher sollte man nochmals alle Benutzerrechte an der mysql-Datenbank überprüfen und ggf. korrigieren. Der Zugriff sollte für alle Benutzer immer nur von localhost aus möglich sein, wenn dies für die jeweilige Anwendung genügt. Einen Benutzer root sollte es nicht geben — zumindest sollte er nicht von überall auf die mysql-DB zugreifen können — sicheres Passwort hin oder her!

Doch man sollte sich natürlich auch nicht — wie ich — durch eine Fehlkonfiguration des mysql-Benutzers root selbst vom Zugriff und der Konfiguration der mysql-Einstellungen aussperren. Falls dies doch passiert hilft folgendes vorgehen:

1. mysqld stoppen (via Prozess-ID)
2. unter Debian (3.1)

    /usr/bin/mysqld_safe -user=root --pid-file=/var/run/mysqld/mysqld.pid --skip-grant-tables

   um hierdurch die Rechteeinstellungen zu übergehen.

   ACHTUNG: NUN DARF JEDER ALLES — DIESER ZUSTAND SOLLTE MÖGLICHST ERST NACH EINER UNTERBRECHUNG DER INTERNETVERBINDUNG HERGESTELLT WERDEN!

3. Nun aber schnell die Benutzerrechte wieder in Ordnung bringen und den msql-Server neu „normal„starten!