Sicherheit auf dem PrüfstandKennwörter und Kreditkarten, Teil 1

Jesper M. Johansson

Inhalt

Undurchführbare Sicherheitsempfehlungen
Undurchführbar und Unrichtig
Unverständliche Empfehlungen
Die Fallen einer auf Bildern basierenden Websiteauthentifizierung

Vor Kurzem kontaktierte mich die Universität von Minnesota wegen eines Interviews für ihr Magazin. Offenbar wollten sie einen Artikel über einen erfolgreichen ehemaligen Studenten schreiben, und weil sie niemanden finden konnten, entschieden sie sich für mich. Der Interviewer fragte, in welchem Bereich ich arbeite, und ich versuchte einige Minuten lang, das Thema

Sicherheitsinfrastruktursoftware zu beschreiben. Die Reaktion meines Gesprächspartners war: „Das hört sich aber kompliziert an! Bei der Sicherheit geht es doch eher um Kennwörter und Kreditkarten.“

Ich dachte einige Minuten über diese Aussage nach und erkannte, dass da etwas dran war. Bei der Sicherheit geht es wirklich um Kennwörter und Kreditkarten. So stellt es sich zumindest dem Endbenutzer dar. Diejenigen unter uns, die sich beruflich damit beschäftigen, denken, dass es beim Thema Sicherheit um kryptografische Algorithmen geht, ob Kerberos besser ist als TLS oder NTLMv2, um die Vorteile von WS*, ob Kennwort-Hashwerte frisiert werden sollten und um all die anderen esoterischen Themen, über die so gerne diskutiert wird. Unsere Sichtweise ist natürlich anders und geht tiefer als die des Endbenutzers, aber wir haben im Großen und Ganzen einen fundamentalen Punkt aus den Augen verloren: Für die Benutzer, denen wir eigentlich dienen sollten, geht es bei der Sicherheit um Kennwörter und Kreditkarten.

Zugegeben, die esoterischen Themen, über den wir uns so gerne streiten, und die vielen neuen Technologien, die wir uns mit wachsender Begeisterung ausdenken, sind dazu gedacht, die Daten des Endbenutzers zu schützen. Dennoch scheinen wir uns verirrt zu haben. Wir, die Sicherheitssubkultur der IT-Welt, existieren, weil wir einen bestimmten Bedarf unserer Auftraggeber erfüllen: die Notwendigkeit, Daten zu schützen. Das schließt selbstverständlich die Garantie mit ein, dass IT-Ressourcen sicher verwendet werden können. Das ist alles.

In früheren Artikeln wurde bereits darauf hingewiesen, dass niemand einen Computer nur deshalb kauft, damit Antivirussoftware darauf ausgeführt werden kann. Der Benutzer erwirbt einen Computer für Onlinebanking, um Computerspiele zu spielen, E-Mails zu schreiben, Hausaufgaben zu machen oder für andere wichtige Aufgaben. Auch wurde keine IT-Sicherheitsgruppe nur deshalb von Unternehmen ins Leben gerufen, damit NTLMv2 implementiert werden kann. Unternehmen stellen finanzielle Unterstützung für IT-Sicherheitsgruppen bereit, um die Organisationsressourcen zu schützen, damit IT-Ressourcen im gesamten Unternehmen sicher verwendet und die Geschäftsziele erreicht werden können.

Wir geben dabei lediglich Hilfestellung.

Deshalb ist die Frage erlaubt, ob wir heutzutage dabei wirklich noch gute Arbeit leisten. Legen wir, die Sicherheitssubkultur, dem Unternehmen eigentlich eher Steine in den Weg? Werden wir dabei womöglich von Gesetzgebern und Behörden noch unterstützt? Ich bin nicht davon überzeugt, dass dem Endbenutzer viele der neu geschaffenen Technologien wirklich weiterhelfen. Daher werden an dieser Stelle einige Bereiche genauer betrachtet, bei denen wir, die IT-Anbieter der Welt, tatsächlich mehr Schaden als Nutzen anrichten.

Manchmal scheint es, als ob die meisten der Sicherheitsempfehlungen und viele der Sicherheitstechnologien, mit denen wir unsere Benutzer belasten, undurchführbar, unrichtig und unverständlich sind oder (in vielen Fällen) aus einer Kombination dieser drei Faktoren bestehen. In dieser dreiteiligen Serie wird genauer beleuchtet, auf welche Weise der Benutzer durch Empfehlungen neuer Technologien, die einen oder mehrere der genannten Faktoren aufweisen, eher verwirrt wird.

Undurchführbare Sicherheitsempfehlungen

Eine der besten Möglichkeiten, Benutzer zu verwirren, besteht darin, ihnen undurchführbare Sicherheitsempfehlungen bereitzustellen. Manchmal sind diese Empfehlungen zudem noch unrichtig. Abbildung 1 zeigt eine beliebte erprobte, theoretisch vernünftige aber vollkommen nutzlose Empfehlung.

Abbildung 1 Undurchführbare Sicherheitsempfehlung (Zum Vergrößern auf das Bild klicken)

Sehen Sie die Stelle, an der gesagt wird, Sie sollen für jedes Ihrer Onlinekonten ein anderes Kennwort verwenden? Vor dreißig Jahren war diese Empfehlung vernünftig. Die Zahl der damaligen Internetbenutzer belief sich auf einige hundert, und alles waren intelligente Köpfe, die keine besonders guten Kennwörter auswählten. Leider hält sich diese Empfehlung hartnäckig, und es gibt keine erkennbaren Bemühungen, sie auf die heutige Computerverwendung abzustimmen.

Wie viele Onlinekonten haben Sie? Ich persönlich habe 115, plus minus ein paar, die ich nicht verwende. Die Empfehlung in Abbildung 1 schlägt nicht nur vor, dass 115 verschiedene Kennwörter verwendet werden sollen, sondern auch, dass diese 115 Kennwörter alle 30 bis 60 Tage geändert werden sollen. Mit anderen Worten, es sollen täglich 2 bis 4 Kennwörter geändert werden. (Rein rechnerisch bedeutet das auch, dass Sie pro Jahr zwischen 690 und 1380 Kennwörter haben.)

Auch wenn das technische Personal einiger Websites, die diese Empfehlung geben, pro Tag 4 gute Kennwörter finden und 115 aktuelle Kennwörter im Kurzzeitgedächtnis speichern kann, ist mit Sicherheit anzunehmen, dass 99,99 Prozent der normalen websurfenden Öffentlichkeit das nicht kann.

In Wirklichkeit ist die Empfehlung, jedes Mal ein anderes Kennwort zu verwenden, genau wie die Empfehlung, jedes der Kennwörter alle 30 bis 60 Tage zu ändern, theoretisch korrekt und vernünftig. Aber diese Empfehlungen sind ganz einfach undurchführbar. Bei der Anzahl an Kennwörtern, über die der Benutzer heutzutage verfügt, kann dieser Ratschlag nicht ohne konkrete Hilfe, z. B. mit Papier oder Software, befolgt werden. Werfen Sie einen Blick auf das nächste Beispiel.

Undurchführbar und Unrichtig

Der in Abbildung 2 gezeigte Auszug aus einer Empfehlung stammt von der Website einer der größten Banken der Welt und ist sowohl undurchführbar als auch unrichtig. Die Informationen, die unter der Überschrift „Unsere Empfehlung zum Kennwort“ genannt werden, folgen der „unterschiedliche Kennwörter überall“-Tradition. Außerdem wird empfohlen, die Kennwörter „niemals aufzuschreiben“.

Abbildung 2 Undurchführbare und unrichtige Sicherheitsempfehlung (Zum Vergrößern auf das Bild klicken)

Jetzt haben Sie also 115 verschiedene Kennwörter, müssen sich täglich 4 neue Kennwörter ausdenken, und Sie dürfen sie nicht aufschreiben. Eine Zeitlang werden Sie sich vielleicht dumm vorkommen, weil Sie sich nicht alle Kennwörter merken können. Dann aber werden Sie entdecken, dass es allen anderen genauso geht. Der Mensch kann sich einfach keine 115 Kennwörter merken. Wir können uns ungefähr sieben Informationsbrocken merken und verarbeiten. So wurden wir nun einmal programmiert. Wenn Sie den meisten der Kennwortempfehlungen aus dem Internet folgen, reicht das in Wirklichkeit nicht einmal für ein Kennwort (Siehe „The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information“ von George A. Miller, verfügbar unter musanim.com/miller1956).

Leider werden Benutzer durch Kennwortempfehlungen von Seiten der Sicherheitsbranche regelmäßig in die Irre geführt. Wenn die Sicherheitssubkultur den Benutzern mitteilt, überall verschiedene Kennwörter zu verwenden, dann sollte sie ihnen auch das „Wie“ verraten: die Kennwörter aufschreiben und irgendwo sicher verwahren. Schreiben Sie sie auf ein Blatt Papier, verwenden Sie ein geschütztes Dokument, oder verwenden Sie ein spezielles Tool wie PasswordSafe (sourceforge.net/projects/passwordsafe). Ganz ehrlich, wir alle schreiben unsere Kennwörter entweder auf, oder wir verwenden das gleiche Kennwort für alle Konten. In einer Umfrage wurde vor Kurzem sogar festgestellt, dass 88 Prozent der Benutzer das gleiche Kennwort für jedes System verwenden, an dem sie sich authentifizieren müssen (siehe msnbc.msn.com/id/24162478).

Einen großen Anteil an diesem Trend hat ganz sicher die Empfehlung, Kennwörter niemals aufzuschreiben. Benutzer müssen darüber informiert werden, wie sich Kennwörter (und andere vertrauliche Daten) effektiv organisieren lassen, anstatt ihnen die Verwaltung dieser Informationen völlig zu untersagen. Als Folge werden wahrscheinlich sehr viel weniger Anmeldeinformationen Gefährdungen ausgesetzt.

Unverständliche Empfehlungen

Die ersten beiden Abbildungen zeigen uralte Empfehlungen, die in den 60er, 70er und 80er Jahren gut funktioniert haben, in einer Zeit, in der ein normaler Benutzer noch nicht online ging und webbasierte Dienste nutzte. Bisher hat sich noch niemand über diese Art von Empfehlungen beschwert, weil sie in der Regel ganz einfach akzeptiert werden.

Solche Empfehlungen verwirren den Benutzer und erwecken möglicherweise Schuldgefühle, da Kennwörter gespeichert werden. Durch Empfehlungen dieser Art anstelle von praktischen Ratschlägen verursachen Sicherheitsfachleute vielfach Schaden. Schließlich liegt es nicht am Benutzer, selbst herauszufinden, wie die Sicherheit persönlicher Daten verwaltet werden kann. Das ist die Aufgabe der Sicherheitsfachleute. Es müssen akzeptable Möglichkeiten für Benutzer gefunden werden, ihre gesamten Onlinekonten zu verwalten. Da in den meisten Leitfäden immer nur die gleichen, veralteten Empfehlungen wiederholt werden, greifen die Benutzer weiterhin zu Haftnotizen und Tabellen, um ihre vielen Kennwörter nachzuverfolgen.

Kennwörter sind ein guter Authentifizierungsmechanismus. Das Hauptproblem bei Kennwörtern ist jedoch, dass der Benutzer sie nicht im Kopf behalten kann. Anstatt dieses biologische Problem zu lösen, denkt sich die IT-Welt weiterhin eine Menge neuer Methoden aus, wie Kennwörter ersetzt werden können, oder schlimmer noch, wie sie verstärkt werden können. Dies verwirrt den Benutzer sogar noch mehr.

Stellen Sie sich meine Überraschung vor, als ich vor Kurzem eine Finanzdienstleistungswebsite besuchte und mir ein Anmeldebildschirm mit nur einem Textfeld für den Benutzernamen angezeigt wurde (siehe Abbildung 3).

Abbildung 3 Wo gebe ich mein Kennwort ein?

Zuerst dachte ich, dass ich auf einer böswilligen Website gelandet bin. Dann habe ich die Website schnell überprüft (dieser Schritt war einfach, da ein Zertifikat angezeigt wurde) und erkannt, dass es sich um die echte Site handelte. Das Problem ist, dass Benutzer bei der Websiteanmeldung daran gewöhnt sind, die beiden Textfelder „Benutzername“ und „Kennwort“ zusammen auf dem Bildschirm zu sehen. Seit Jahren begegnet ihnen also der gleiche, gewohnte Workflow. Wenn eine Website plötzlich nur nach dem Benutzernamen fragt, gerät der Benutzer aus dem Gleichgewicht. In diesem Fall stellte sich heraus, dass der Anbieter eine Technologie implementiert hat, die Bilder verwendet, um die Website gegenüber dem Benutzer zu identifizieren, und so Phishing-Angriffe verhindern will. Nach Eingabe des Benutzernamens wird im weiteren Verlauf ein Bildschirm mit einem identifizierbaren Bild gezeigt, siehe Abbildung 4.

Abbildung 4 Einige Websites verwenden jetzt Bilder zur Authentifizierung gegenüber dem Benutzer (Zum Vergrößern auf das Bild klicken)

Die Theorie besagt, dass Sie wissen, welches Bild zu welcher Site gehört. Wird nicht das richtige Bild angezeigt, ist die Website eine Fälschung. Das ist an und für sich ein vernünftiges Konzept. Unter der Voraussetzung, dass der Benutzer weiß, welches Bild zu welcher Website gehört, ist diese Strategie relativ sinnvoll.

Selbstverständlich hat der scharfsinnige Leser die grüne Adressleiste in Abbildung 4 bemerkt. Die Adressleiste ist deshalb grün, weil diese Website SSL und Zertifikate für die erweiterte Überprüfung (Extended Validation, EV) verwendet. Das bedeutet aber auch, dass der gesamte Ansatz, ein Bild zur Identifizierung der Site zu verwenden, keinen zusätzlichen Schutz bietet. Für manche Endbenutzer stiftet das Bild stattdessen etwas mehr Verwirrung. Die Website hat sich gegenüber dem Benutzer bereits identifiziert. Sie zeigt ein Zertifikat an, das den Unternehmensnamen, die Adresse der Website und den Namen des vertrauenswürdigen Ausstellers enthält. Die grüne Adressleiste zeigt dem Benutzer, dass das Unternehmen sogar zusätzlich dreimal so viel Geld für ein EV-Zertifikat ausgegeben hat.

Die Bilder könnten selbstverständlich auch gefälscht werden. Wenn der Benutzer sein eigenes Bild einreichen kann, kann ein Angreifer u. U. über verschiedene Möglichkeiten herausfinden, welches Bild verwendet wird. Auch ist sehr gut möglich, dass der Benutzer immer das gleiche Bild für jede Website verwendet. Ein Angreifer muss lediglich eine Website mit für den Benutzer nützlichem Inhalt erstellen (das Ausdenken geeigneter Beispiele sei Ihnen überlassen), und den Benutzer nach einem Bild zur Websiteverifikation fragen. Verwendet der Benutzer das gleiche Bild für alle Websites, hat diese neue Website jetzt Zugriff auf das Bild, das der Benutzer zum Beispiel auf seiner Bankwebsite verwendet.

Bei einigen Websites können Sie Ihr eigenes Bild auswählen, bei anderen wird eine Bibliothek mit Archivfotos verwendet. Auf der Website in Abbildung 4 können Sie zum Beispiel aus 318 Archivfotos auswählen. Der oben beschriebene Trick funktioniert nicht für Websites, bei denen der Benutzer kein eigenes Foto verwenden kann. Darf der Benutzer jedoch kein eigenes Bild verwenden, dann wird er sich sehr wahrscheinlich kaum mehr an die Bilder der Websites erinnern, die er nur gelegentlich besucht. Ich habe ehrlich gesagt keine Ahnung, welches Bild ich auf der Website in Abbildung 4 verwende, aber ich bin mir sicher, dass es nicht das Bild auf dem Screenshot ist.

Das Problem mit dem auf einem Bild basierenden Ansatz ist, dass ein Angreifer so ziemlich jedes der 318 Bilder oder nur einen zufälligen Schnappschuss von Flickr zu zeigen braucht, und viele Benutzer annehmen, dass es sich um das richtige Bild handelt. Wenn sich die Mehrheit der Benutzer an Dinge wie bestimmte Bilder für bestimmte Websites erinnern könnte, gäbe es heute nicht all diese Phishing- und Sicherheitsprobleme.

Warum also soll ein Bild verwendet werden, um die Website gegenüber dem Benutzer zu authentifizieren, wenn sich die Website bereits mithilfe eines Zertifikats authentifiziert hat? Warum nicht einfach nur dieses Zertifikat verwenden und dem Benutzer beibringen, wie er es überprüfen kann? Zertifikate beweisen bereits die Identität der Website gegenüber dem Benutzer.

Der Prozess für das Abrufen eines Zertifikats ist erheblich sicherer als der Prozess, an das Authentifizierungsbild eines Benutzers für eine Site zu gelangen. Wenn es sich um ein EV-Zertifikat handelt und Sie Internet Explorer® 7 oder Firefox 3 verwenden, hebt der Browser die relevanten Zertifikatinformationen sogar in der Adressleiste hervor. Leider funktioniert das Hervorheben nur bei den sehr teuren EV-Zertifikaten.

Die Fallen einer auf Bildern basierenden Websiteauthentifizierung

Die Bildauthentifizierungstechnologie wirft einige Probleme auf. Als Erstes wird dadurch das Sammeln von Benutzernamen einer Website sehr vereinfacht. Die in Abbildung 4 gezeigte Website zeigt den in Abbildung 5 aufgeführten Dialog an, wenn der falsche Benutzername eingegeben wird. Bei Eingabe eines korrekten Benutzernamen für einen Benutzer, der sich für ein geheimes Bild entschieden hat, wird das geheime Bild dieses Benutzers preisgegeben. Dieses Wissen ist natürlich sehr wertvoll für einen Angreifer, der Informationen über einen Benutzer sammeln will.

Abbildung 5 Mit Bildern authentifizierte Websites ermöglichen das einfache Sammeln von Benutzernamen

Die hier gezeigte Art der Implementierung hat praktisch keinen Sicherheitswert. Der Angreifer kann den Anmeldeworkflow einfach auf einer gefälschten Website imitieren. Die gefälschte Website bittet um einen Benutzernamen und reicht ihn an die wirkliche Website weiter. Sie können auf dem Client sogar AJAX verwenden, um das Formular in Echtzeit zu aktualisieren und somit glaubwürdiger zu machen. Wenn die legitime Website außerdem siteübergreifende Anforderungsfälschungsangriffe auf das Anmeldeformular nicht einschränkt, kann der AJAX-Code der wirklichen Website die Anforderung sogar direkt senden, es sei denn, der Browser schränkt siteübergreifende XML-HTTP-Anforderungen ein.

Anhand des zurückgegebenen Ergebnisses kann der Angreifer die Daten analysieren, das Bild extrahieren und es dem Endbenutzer anzeigen. Ein Angreifer, der dem Benutzer eine gefälschte Anmeldewebsite anzeigen kann, kann also auch das geheime Bild des Benutzers anzeigen. Unter dem Strich bietet eine auf Bildern basierende Websiteauthentifizierung absolut keinen zusätzlichen Nutzen. Das Bild wird angezeigt, bevor sich der Benutzer bei der Website authentifiziert, und ist daher für einen Angreifer verfügbar, der den Benutzernamen des Benutzers bereits kennt oder sich verschaffen kann.

Angenommen, dem Benutzer wurde nie beigebracht, vor dem Senden eines Formulars nach einem Zertifikat zu suchen, und das ist eine berechtigte Annahme angesichts der Tatsache, dass die Verwendung einer auf Bildern basierenden Websiteauthentifizierung selbst auf der gleichen Annahme basiert, dann ist es einfach, den Benutzernamen dieses Benutzers herauszufinden. Da außerdem viele auf Bildern basierende Websiteauthentifizierungsmodelle auf einen gültigen Benutzernamen anders als auf einen ungültigen Benutzernamen reagieren, ist das Sammeln von Benutzernamen eine Bagatelle. Noch bevor ein Angriff gestartet wird, kann ein Angreifer dies Out-of-Band erledigen.

Als Ergebnis glaubt der Benutzer entweder, dass er besser geschützt ist, oder er ist noch verwirrter. Es wurden bedeutende Eigenkapitalbeträge ausgegeben, um eine auf Bildern basierende Websiteauthentifizierung zu implementieren, dabei wurde es Angreifern aber nicht erschwert, den Endbenutzer davon zu überzeugen, seine Anmeldeinformationen an gefälschte Websites zu senden.

Das wäre alles für diese Folge von „Sicherheit auf dem Prüfstand“. Im nächsten Monat folgt Teil 2 dieser Serie. Dann werden weitere Beispiele für unsinnige Sicherheitsmaßnahmen und schlechte Authentifizierungsimplementierungen vorgestellt.

Jesper M. Johansson ist Softwarearchitekt mit dem Schwerpunkt Sicherheitssoftware und schreibt redaktionelle Beiträge für das TechNet Magazin. Er hat seine Doktorarbeit zum Thema Management Information Systems geschrieben, verfügt über mehr als 20 Jahre Erfahrung auf dem Gebiet der Sicherheit und ist Microsoft MVP im Bereich Unternehmenssicherheit. Sein aktuelles Buch heißt Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig