Sicherheit – Nein Unsinn!

In letzter Zeit häufen sich zumindest in meiner Wahrnehmung unsinnige Verifikationen oder Multi-Faktor-Authentifizierung (MFA). Auch die Verschlüsselung mit dem Geburtsdatum hat wenig mit Sicherheit zu tun. Also mal ein kleiner Exkurs zu MFA und anderen fragwürdigen Verfahren, deren Verbreitung in Deutschland leider eher zu als abnimmt.

• Begriffe und Sicherheitsmechanismen
  • Authentisierung und Authentifizierung
  • Multi-Faktor-Authentifizierung (MFA)
  • Sicherheitsfragen
  • Verschlüsselung und Schlüssellängen
  • Schlüssel und Inhalte auf getrennten Kanälen
• Unsinn nach Verwendern
  • Verifikation mit Telefonnummer bei Ebay-Kleinanzeigen
  • Emailverifikation bei der Telekom
  • Sicherheitsfragen in den Verwaltungsportalen
  • Verschlüsselung von Corona-Schnelltestergebnissen mit dem Geburtsdatum
  • Geburtsdatum und Videoidentifikation bei Hays
  • Google will mein Geburtsdatum
  • Outlook.com
  • Verifiziert bei diversen Anbietern
  • Bundesamt für Unsicherheit will oder akzeptiert Zertifikat per Email

Begriffe und Sicherheitsmechanismen

Da nicht jeder Leser mit allen Begriffen vertraut ist erstmal ein paar Begriffe und Sicherheitsmechanismen. Dabei gehe ich nur auf das ein, was bei Verantwortlichen von außen erkennbar schief geht. Was ich von Verantwortlichen positiv erwarte, ergibt sich aus Sicherheitsanforderungen und Bedrohungsmodellierung, worauf Anwender achten müssen oder können aus Digitale Selbstverteidigung.

Authentisierung und Authentifizierung

Wenn Sie verwirrt sind, wenn Mal von Authentisierung und Mal von Authentifizierung die Rede ist – da gibt es in Deutschland eine in meinen Augen wenig hilfreiche Unterscheidung, die vom Bundesamt für Sicherheit in der Informationstechnik (BSI) und Hasso Plattner Institut propagiert werden, aber mehr Verwirrung stiftet als Klarheit bringt. Nach deren Definition, auch auf Wikipedia: Authentifizierung zu finden, sind es die Teilschritte die durch den Benutzer bzw. dem Client und auf dem Server laufen, und in der Praxis tritt das eigentlich immer zusammen auf. Im Englischen wird diese Unterscheidung nicht gemacht, und daran halte ich mich – außer bei Zitaten.

Multi-Faktor-Authentifizierung (MFA)

Auch wenn die PIN gemessen an Passwortempfehlungen reichlich unsicher erscheint ist dieses Verfahren sogar sehr sicher, denn nach der Eingabe von drei falschen PINs wird die Karte einbehalten. Die 10.000 möglichen Werte durchprobieren – das wird nur dann funktionieren wenn man eine PIN wie 1234 verwendet – das ist dann von der gleichen Qualität wie ein Passwort "abcd1234" oder "Passwort". Erfolgversprechend ist in erster Linie das Ausspähen des Opfers, also sollte ich darauf achten dass der Automat nicht manipuliert wurde (z.B. mit aufgesetzter Tastatur), ich niemanden zusehen lasse und idealerweise meine Spuren verwische nachdem der Automat das Geld ausgegeben hat. Dann hat der Taschendieb, Räuber oder auch Finder meiner Karte wenig Chancen auch noch das Bankkonto zu plündern. Aus diesem Beispiel kann man auch erkennen, dass es sinnvoll ist, wenn die Faktoren oder Kategorien unterschiedlich sind.

MFA im Internet ist meist weniger sicher und/oder weniger zuverlässig. An häufigsten verwendet werden zwei Varianten von Einmalpasswörter (englisch One-Time-Password):

• Das Einmalpasswort wir z.B. auf dem Mobiltelefon berechnet
• Ein generiertes, meist zufälliges Einmalpasswort wird per SMS verschickt, z.B. SMS-Transaktionscode, auch kurz smsTAN oder mTAN

Beide suggerieren dem einfachen Anwender den 2. Faktor "Besitz eines Mobiltelefons".

Bei den berechneten Einmalpasswörtern geht es nicht um den Besitz des Telefons. In Wirklichkeit geht es um den Besitz eines (mit dem Anbieter geteilten) Geheimnisses, mit dessen Hilfe man oder meist eine Anwendung – auf dem Mobiltelefon oder woanders – nach einem bekannten Verfahren das Einmalpasswort berechnen kann. Passwort und das Geheimnis – zwei Faktoren aus derselben Kategorie Wissen. Nur dass das ganz vielen Benutzern erst bewusst wird, wenn sie das Mobiltelefon verlieren und von diesem Wissen keine Kopie (z.B. im Passwortmanager) existiert. Der einzige Vorteil von Einmalpasswörtern ist, dass sie nur sehr kurzzeitig gültig sind, aber das hat Angreifer nicht abgehalten, Phishing-Seiten zu bauen, die das Einmalpasswort halt sofort verwendet haben. Wenn ich gute Passwörter verwende (siehe auch Digitale Selbstverteidigung: Sicherheit beginnt mit starken Passwörtern) und mir zutraue, Phishing-Seiten zu erkennen, dann bieten Einmalpasswörter in meinen Augen keinen zusätzlichen Schutz. Dass immer wieder das Gegenteil behauptet wird liegt vor allem daran, dass der Durchschnittsanwender oft keine sicheren Passwörter verwendet, und bei MFA das unsichere schlechte Passwort durch das dann bessere Einmalpasswort ersetzt wird. Aber hier zwingen uns die Anbieter eine unbequeme Lösung auf statt uns aufzufordern, gute Passwörter zu verwenden.

Bei SMS-Transaktionscodes sollte man wissen, dass Mobiltelefone nicht unbedingt nur von einer Person genutzt werden, verloren gehen können, man seine Mobilnummer beim Anbieterwechsel ändert, und Telefonnummern auch irgendwann wiederverwendet werden können. Genau wie bei IP-Adressen: Telefonnummern können personenbezogene Daten sein, aber man kann nicht unterstellen, dass sie eine Person identifizieren oder eindeutig nur einer Person zugeordnet sind. Mann sollte wissen, dass man sich in Funklöchern aufhalten kann und dann keine SMS empfangen kann. Dass es meistens (Ausnahme: Geräte mit eSIM) nicht wirklich der Besitz eines Mobiltelefons ist, sondern der Besitz der SIM-Karte, und heute viele SIM-Karten ohne aktive PIN (bzw. PIN 0000) geliefert werden – also kann man die SIM-Karte auch leicht in ein anderes Telefon einsetzen. Auch gab es schon Malware die SMS weitergereicht haben, und gemessen an https sind die Protokolle im Telefonnetz unsichere Dinosaurier. Wikipedia: Transaktionsnummer – Sicherheit listet eine ganze Reihe Probleme auf. In meinen Augen überwiegen die Nachteile die Vorteile.

SIM-Karte und PIN ist übrigens ein anderes gutes Beispiel für MFA: man besitzt die SIM-Karte und man weiß die PIN. Man sollte die PIN nicht deaktivieren, auch wenn es natürlich unbequem ist, bei jedem Neustart des Mobiltelefons die PIN eingeben zu müssen. Wenn das Mobiltelefon mit Verschlüsselung und Passwort geschützt ist, dann kann man die PIN auch dem Mobiltelefon anvertrauen – aber man sollte überprüfen dass die PIN abgefragt wird, wenn man die SIM-Karte in ein anderes Mobiltelefon einsetzt.

Manchmal wird ein Transaktionscode statt per SMS per Email verschickt. Das ist fragwürdig, denn wenn ich MFA verwende, dann in aller Regel weil ich dem Benutzer nicht zutraue sichere und unterschiedliche Passwörter zu verwenden. Dann müsste ich aber auch gleich unterstellen, dass nicht nur der Zugang zum Dienst sondern auch zum Postfach kompromittiert ist.

Mehr Informationen auch beim BSI: Zwei-Faktor-Authentisierung, nur dass das halt MFA generell empfiehlt statt an sichere Passwörter zu erinnern.

Und zu allerletzt: Die Profis unterscheiden nach PCIDSS: MFA zwischen Multi-Faktor-Authentifizierung, bei der alle Faktoren gleichzeitig bzw. zusammen geprüft werden, und der Mehr-Schritt-Authentifizierung, bei der das Nacheinander stattfindet – und dem Angreifer damit u.U. schon verrät dass man das schlechte Passwort geraten hat bevor es das Einmalpasswort abfragt. Ganz oft wird leider nur Mehr-Schritt-Authentifizierung verwendet. Das hilft dann vielleicht nicht bei diesem Dienst weiter, aber weil das Passwort dann vermutlich schlecht war, ganz oft bei einem anderen. Beim Geldautomaten oben – die Karte behält der Automat ein, bis die PIN eingegeben wurde oder abgebrochen wird.

Sicherheitsfragen

Das grundsätzliche Problem bei Sicherheitsfragen ist, dass die richtige Antwort in fast allen Fällen nicht nur dem Benutzer sondern auch vielen anderen bekannt ist, oder über öffentliche Quellen wie z.B. Telefonbuch, Social Media, oder über Social-Engineering ermittelbar ist. Wikipedia zitiert Josh Levins In What City Did You Honeymoon? And other monstrously stupid bank security questions. Josh Levin ist natürlich nicht der einzige, der von Sicherheitsfragen abrät. Auch das NIST, OWASP, und Bruce Schneier (2005) raten eindeutig von Sicherheitsfragen ab. OWASP zitiert dabei auch Studien von Microsoft (2009) und Google (2015), die klar zeigen, dass Sicherheitsfragen nicht funktionieren. Sicherheitsfragen entsprechen also schon einige Zeit nicht dem Stand der Technik. Das BSI bezieht (mal wieder) keine klare Stellung, in APP.3.1 erwähnt es zwar OWASP, aber konkreter wird es nicht. Um es klar auszudrücken: wer Sicherheitsfragen verwendet, hat mit großer Wahrscheinlichkeit Entwickler, die von Sicherheit wenig oder keine Ahnung haben und die OWASP-Cheatsheets nicht kennen.

Werden Sicherheitsfragen verwendet, dann sollte man als Benutzer falsche Antworten eingeben – z.B. generierte Passwörter des Passortmanagers – und sie dann auch am besten dort aufbewahren für den Fall, dass sie wirklich irgendwann zum Einsatz kommen sollten. Leider erschweren einige Verwender das dadurch, dass die Eingaben validiert werden und damit der Zufall begrenzt wird.

Verschlüsselung und Schlüssellängen

Information wird verschlüsselt, damit sie von Unbeteiligten nicht mitgelesen oder eingesehen werden kann. Dabei ist schon lange Konsens – mehr auf Security by Obscurity, dass das Verfahren öffentlich sein soll, aber der Schlüssel geheim. Und damit der Schlüssel auch nicht mit der Brute Force Methode, also Durchprobieren ermittelt werden kann, muss er auch eine gewisse Länge haben. Wie viele Bits es braucht hängt vom Verfahren ab, aber weniger als 128 Bit werden heute nirgends verwendet. 128 Bit steht für etwa 3,4 * 10³⁸ verschiedene mögliche Schlüssel. Oder wenn man ein entsprechend komplexes Passwort aus den jeweils 26 Groß- und Kleinbuchstaben, Ziffern, und ca. 20 Sonderzeichen würfelt, dann sollte es eine Länge von mehr als 20 Zeichen haben.

Warum schreibe ich das? Weil die typischen Sicherheitsfragen und insbesondere aktuelle Versionen natürlich meist kürzere Antworten haben und oft mit einem Wörterbuch aufgezählt werden können.

Schlüssel und Inhalte auf getrennten Kanälen

Wenn ich verschlüsselt kommuniziere, dann muss ich irgendwie auch die notwendigen gemeinsamen (bei symmetrischer Verschlüsselung) oder öffentlichen (bei asymmetrischer Verschlüsselung) Schlüssel bzw. Zertifikate zwischen den Kommunikationspartnern austauschen oder über ein geeignetes Protokoll wie Diffie-Hellman-Schlüsselaustausch erzeugen. Völlig klar, dass das für Normalanwender ein schwer zu verstehendes Thema ist. Aber was jeder mitnehmen kann und soll ist, dass Schlüssel (oder Passwort) und Inhalt nie über den gleichen Kanal übertragen werden sollen. Also insbesondere nicht beides per Email.

Unsinn nach Verwendern

Verifikation mit Telefonnummer bei Ebay-Kleinanzeigen

Jahrelang konnte ich Ebay-Kleinanzeigen ohne Telefonnummer verwenden, doch vor kurzem wollte man meine Telefonnummer verifizieren. Von Verifikation kann keine Rede sein, denn meine Telefonnummer kennt Ebay nicht. Man will sie mir unnötigerweise abverlangen, ob nur einmal oder jedesmal neu ist mir unbekannt. Ich habe Beschwerde bei der zuständigen Aufsicht eingelegt.

Auch hier, die Telefonnummer und SMS bringt zur Verifikation und damit zur Betrugsprävention gar nichts. Vielleicht ist der Gedanke von Ebay, dass die Anbieter von Mobilfunknummern nach §172 TKG zur Identitätsfeststellung verpflichtet sind. Aber zum einen gibt es meines Wissens keinen Grund für Ebay eine Identitätsfeststellung vorzunehmen und damit kann man den Einwand Vorratsdatenspeicherung geltend machen, zum anderen gibt es Dienste mit öffentlichen Telefonnummern zum Empfangen von SMS, s. SMS online empfangen – so klappt's. Und ganz praktisch, wenn man jedesmal eine SMS bekommt und die eingeben muss, dann nervt das nicht nur, sondern man wird auch noch von der schlechten Mobilfunkabdeckung in Deutschland abhängig, und ich habe auch keine Lust beim Wechsel meines Mobiltelefonanbieters auch noch Ebay Bescheid zu geben.

Emailverifikation bei der Telekom

Die Telekom verschickt aktuell Emails an Ihre Kunden, in denen Sie zur Verifikation die Postleitzahl oder das Geburtsdatum abfragt, um es nach Aussage des Konzerndatenschutzes der Telekom dann für 2FA (Zwei-Faktor-Authentifizierung) zu benutzen. Welch ein Unsinn! Zunächst handelt es sich um zweimal Kategorie Wissen, also keine echte Mehr-Faktor-Authentifizierung, sondern allenfalls um Sicherheitsfragen. Und dann auch noch Wissen das nicht geheim, sondern bei vielen Menschen öffentlich ist – findet man im Telefonbuch, auf der Webseite oder in sozialen Medien, und spätestens wenn man einen Menschen besser kennt, kennt man auch beide Informationen.

Selbst wenn man die Antworte nicht wüsste, beim Geburtstag gibt es – biblisches Alter ausgeschlossen – weniger als 125*12*31 = 46.500 verschiedene Möglichkeiten, bei der Postleitzahl sind es ca. 30.000, maximal 100.000 Möglichkeiten. Das sind viel weniger Möglichkeiten als bei einem richtigen Passwort und ein Computer kann die in kurzer Zeit durchprobieren. Was macht die Telekom in so einem Fall? Das Konto des berechtigten Nutzers sperren? Oder die IP-Adresse des Angreifers? Wir wissen es nicht.

Überraschend aber gut: eigentlich hat die Telekom die Postleitzahl schon, denn die braucht sie für die Rechnungen aus dem Vertrag. Ob sie hier die Zweckbindung in Artikel 5 I lit. b DSGVO ernst nimmt?

Sicherheitsfragen in den Verwaltungsportalen

Die Verwaltungsportale von Bund, Baden-Württemberg, Bayern, Berlin, Brandenburg, Hessen, und Sachsen verwenden ebenfalls Sicherheitsfragen, siehe Verwaltungsportale – was macht die Aufsicht? obwohl von Sicherheitsfragen abgeraten wird. Dazu habe ich eine Anfrage beim Bayerischen Staatsministerium, dem Bundesministerium des Inneren, und dem Bundesamt für Unsicherheit laufen. (Ergänzt am 14.10.2022)

Verschlüsselung von Corona-Schnelltestergebnissen mit dem Geburtsdatum

Da frag ich mich wirklich warum ich nicht früher kritisch wurde – das Verschlüsseln mit dem Geburtsdatum bei Corona-Schnelltestergebnissen ist natürlich noch schlechter als die Verwendung des Geburtsdatums für eine Verifikation der Emailadresse bei der Telekom, und dass man das Geburtsdatum durchprobieren – steht auch schon oben. Aber in diesem Fall kann man die 46.500 Möglichkeiten sogar durchprobieren ohne dass irgendjemand das mitbekommen könnte. Ich vermute mal, dass das ganze Verfahren vom Dienstleister definiert wurde, und der Datenschutzbeauftragte der Apotheke da vielleicht gar nicht beteiligt war.

Geburtsdatum und Videoidentifikation bei Hays

Auch der Personaldienstleister Hays verwendet das Geburtsdatum zur Verschlüsselung und beruft sich dabei sogar auf den Wunsch von Betroffenen. Auch verwendet Hays Videoidentifikation ohne dass es dafür eine Rechtsgrundlage gibt (s. a. Beschwerde Hays).

Google will mein Geburtsdatum

Diesmal nicht um die Sicherheit zu verbessern, sondern man brauche das für manche Dienste, die Google nur mit Erwachsenen durchführen darf. Nur dass ich diese Dienste gar nicht verwende. War da nicht etwas mit Datensparsamkeit und Zwecktrennung in der DSGVO?

Outlook.com

Auch Microsoft schickt mir immer mal wieder Emails Ungewöhnliche Anmeldeaktivität für das Microsoft-Konto, ohne zu informieren, ob diese Anmeldeaktivität erfolgreich war, sprich mein Passwort erraten wurde, oder eben nicht. Wurde mein Passwort tatsächlich erraten – sehr unwahrscheinlich – dann muss ich es ändern. Wurde es nicht erraten, dann sollte Microsoft die entsprechende IP-Adresse oder das Netzwerk des Angreifers sperren und mich in Ruhe lassen – denn solche Versuche Passwörter zu erraten sind völlig normal. Wahrscheinlich hätte man mich auf irgendeiner Webseite dann genötigt, MFA anzuschalten, aber darauf verzichte ich gerne.

Verifiziert bei diversen Anbietern

Das Attribut verifiziert gibt es bei ganz vielen Plattformen, darunter Tinder, Meet5, und anderen. Dem sollte man nicht wirklich Beachtung schenken. Meet5 schreibt in den FAQs: "Verifiziert" bedeutet, dass dieser Nutzer schon mal bei einem Treffen dabei war, er wurde dort erkannt und die Person auf dem Bild entspricht diesem Nutzer. Ob der Name oder sonstige Angaben richtig sind – keine Aussage. Auch das Fehlen besagt nicht viel, denn die Bestätigung habe ich auch erst nach dem dritten Treffen bekommen. Ein Betrüger würde zwei Nutzer anlegen, ein wenig attraktives Treffen anlegen und dabei die einzigen Teilnehmer gegenseitig bestätigen.

Noch fragwürdiger die Plattformen bei denen man den Status verifiziert sofort bekommen kann – da ist dann oft künstliche Dummheit beteiligt, und der Chaos Computer Club hat gezeigt, dass die sich leicht austricksen lässt – siehe Chaos Computer Club hackt Video-Ident.

Bundesamt für Unsicherheit will oder akzeptiert Zertifikat per Email

Das ist natürlich schon mega-peinlich. Das BSI möchte mir endlich meine Auskunft elektronisch schicken – gut – und möchte dafür ein Zertifikat von mir ohne auf unabhängige Verifikationsmöglichkeit zu achten – Email reicht. Das geht zwar technisch, ist aber unsicher. Mehr dazu auf Bundesamt für Unsicherheit in der Kommunikationshistorie, oder zu PGP und S/MIME auf Vergleich RFC 7672 vs. PGP / S/MIME.

Leserbriefe, Reaktionen, Ergänzungen

Dieser Artikel war teilweise motiviert durch die Freundin, deren Beschwerde über die Email-Verifikation der Telekom wir dann gemeinsam eingereicht haben. Leider zeigt diese Beschwerde auch, wie unwillig der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) ist, Sicherheitsprobleme (möglicherweise abgesehen von fehlender obgliatorischer Transportverschlüsselung) ernst zu nehmen.

Dass der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg sich bei Verschlüsselung von Corona-Schnelltestergebnissen mit dem Geburtsdatum bewegt hat, liegt an einer Untätigkeitsklage die ich eingereicht habe. Ich werde noch ausführlicher darüber berichten.