© photocase.com

Statt mit einem dicken Panzer wehrt sich der Kaktus mit dünnen Stacheln. Die behindern ihn nicht beim Wachstum und schützen trotzdem effektiv. Ähnlich sollten Entwickler Sicherheitssoftware entwerfen und sie den Bedürfnissen und Verhaltensmustern ihrer Anwender anpassen.

Benutzer hassen es, an ihren Programmen herumzukonfigurieren, besonders wenn es sich um komplexe Sicherheitstechnik handelt, die sie nicht verstehen. Eine Usability-Studie für PKIs [2] untersuchte dazu eine Gruppe von technisch hervorragend ausgebildeten Anwendern, die meisten mit einschlägigem Doktorgrad. Die Kernfrage: Wie lange brauchen sie, um sich ein X.509-User-Zertifikat auszustellen. Antwort: über zwei Stunden. Die Probanden werteten den Test als einen der schwierigsten, der ihnen je gestellt wurde.

Grob verschätzt

Das ist kein Einzelfall. Sicherheitsexperten unterschätzen sehr häufig, wie lange ein Anwender für eine Aufgabe tatsächlich braucht. Wenn es die Gilde der Sicherheitsexperten in zehn Minuten schafft, dann gilt das keinesfalls auch für Durchschnittsbenutzer. Die sind vielleicht nach zehn Stunden immer noch nicht fertig. Um solche Hürden zu vermeiden, muss sich eine Applikation so weit wie möglich selbst konfigurieren und dem User nur wenige, ihm vertraute Optionen überlassen. Ein Netzwerkserver könnte zum Beispiel während der Installation ein selbst signiertes Zertifikat ausstellen und es automatisch bei der weiteren Kommunikation verwenden.

Theorie und Praxis

Die theoretische Sicherheit der selbst signierten Variante ist zwar deutlich niedriger als bei dem Zertifikat einer anerkannten CA. Weil sich aber kaum jemand eine solche Beglaubigung leisten wird, ist ironischerweise die effektive Sicherheit beim simplen, selbst signierten Zertifikaten höher. Wer die Zusammenhänge gut genug versteht, um sich ein besseres Zertifikat zu besorgen, kann dies ja jederzeit nachholen.

Einen pragmatischen Mittelweg geht die Plug&Play-PKI [3] in Cryptlib. Die Bibliothek stammt vom Autor dieses Beitrags. Mit ihr ortet ein Clientprogramm selbstständig einen CA-Server und kommuniziert mit ihm. Der Anwender braucht nur noch einen Namen und ein Passwort einzutippen. Das ist in weniger als einer Minute erledigt, auch ohne Doktortitel in Informatik. Bei Appliances, also Geräten ohne Bedienoberfläche, sollte der Hersteller das Zertifikat vorkonfigurieren.

Passwörter sind besser als ihr Ruf

Wie Teil 1 der Reihe belegte, sind Benutzer im Umgang mit Passwörtern bestens geübt [1]. Eine Applikation tut gut daran, beim traditionellen Username-Passwort-Schema zu bleiben und diese Daten durch einen sicheren Tunnel (SSL/TLS oder SSH) zu übertragen statt auf komplexe PKIs zu setzen. Bei näherer Betrachtung erweisen sich PKIs oft genug auch nur als umständlich ausgeführter User-Passwort-Mechanismus: Der Benutzer tippt Username und Passwort ein, um seinen geheimen Schlüssel zu dechiffrieren, der ihn dann im zweiten Schritt authentifiziert.

Da viele User unsichere Geheimwörter wählen, empfehlen sich Protokolle wie das passwortbasierte TLS-PSK (Transport Layer Security, Pre-Shared Keys, [4]). Es verzichtet darauf, dem Gegenüber das Codewort preiszugeben, auch nicht durch einen sicheren Tunnel. Ein positiver Nebeneffekt beim Einsatz von TLS-PSK ist dessen beiderseitige Authentifizierung. Nicht nur der Client muss sich ausweisen, auch der Server authentifiziert sich gegenüber dem Client. Das klappt ohne den Overhead, die Kosten und die Komplexität einer PKI.

Ähnliche positive Effekte erzielt die Kombination eines Sicherheitsmechanismus mit einer für User erkennbar sinnvollen Aufgabe. Die bekannteste Variante dieses Tricks ist der Zündschlüssel: Autofahrer benutzen den Schlüssel nicht, weil er ihnen als Sicherheitsgerät wichtig wäre, sondern einfach weil sie dem Fahrzeug damit mitteilen, wann es den Motor starten und wann wieder abstellen soll (Abbildung 1). Die Sicherheit ist aus Sicht der Fahrer ein angenehmer Nebeneffekt, den sie meist nicht einmal wahrnehmen.

Abbildung 1: Autofahrer nehmen ihren Schlüssel nicht als hinderliches Security-Device wahr. Er ist nur das Gerät, mit dem sie ihren Wagen starten. Diese Doppelbelegung mit einer vom Anwender gewünschten Funktion wäre auch in der IT-Sicherheit hilfreich. (Bild: © photocase.com)

Durch die Hintertür

Sehr konsequent setzte in den 50er Jahren der KW-26 Teletype Link Encryptor (eine Verschlüsselung für Fernschreiber) auf das Huckepack-Verfahren [5]. Als Schlüssel diente dem Gerät eine Lochkarte. Um zu verhindern, dass Benutzer dieselbe Karte mehrfach verwenden, haben die Entwickler einen Shredder direkt beim Lochkartenleser montiert. Wenn jemand die Tür zu diesem Gerät öffnete, vernichtete der Shredder die alten Karten automatisch.

Das Vernichten war damit einfach Bestandteil einer gewöhnlichen Vorgehensweise. Der Erfolg dieser simplen Mechanik stellte jede militärische Disziplin in den Schatten, die Anwender dazu verpflichtete, Karten nur einmal zu verwenden. Leider ergibt sich nur selten eine Gelegenheit, Sicherheitsmechanismen huckepack auf andere Abläufe zu setzen. Wenn es klappt, dann funktioniert der Trick außerordentlich gut.

Automatik oder Gangschaltung

Der Entwickler muss sich an vielen Stellen entscheiden, ob eine Operation automatisch und damit im Verborgenen abläuft oder ob der Benutzer die Entscheidung fällen darf oder muss. Letzteres nehmen Anwender oft als aufdringlich wahr. Sie versuchen – so weit wie möglich – monotone Aufgaben zu vermeiden. Keinem Menschen liegen langweilige, sich wiederholende Tätigkeiten. Sie nehmen lieber eine Abkürzung.

Je aufwändiger Operationen wie Verschlüsseln oder Signieren ausfallen, umso größer der Wunsch nach Vereinfachung. Der Entwickler hat die Wahl: Entweder verzichtet er auf perfekte Sicherheit und automatisiert möglichst viel oder er akzeptiert, dass seine Anwender die Funktion weitgehend ignorieren.

Verlangt ein Mechanismus, dass der User eine Smartcard einlegt, seine PIN eintippt und sich biometrisch ausweist, dann wird die Funktion weitgehend ungenutzt bleiben. Klappt die Verschlüsselung fast von allein, dann sinkt deren Sicherheit, die User werden sie dafür aber auch tatsächlich verwenden. Den besten Kompromiss finden, das ist die Aufgabe des Entwicklers.

Bewusste Entscheidung

Automatismen sind aber nicht in jedem Fall die beste Wahl. Bei wichtigen Sicherheitsentscheidungen braucht ein Programm sogar aufdringliche Dialoge. Die Software muss sicherstellen, dass der User eine Aktion ausdrücklich gestattet, bevor das Programm weiterläuft. Es ist eine bewusste Entscheidung des Anwenders nötig. Heimlich und ohne eindeutigen Wunsch des Users seine Nachrichten signieren wäre schlechter Stil (vergleichbar einer blinden Unterschrift unter einen Vertrag) und wird vor Gericht kaum bestehen. Diese Art der Signatur wäre praktisch wertlos.

Verlangt ein Programm vom Anwender eine solche sicherheitsrelevante Entscheidung, dann muss es auch dafür sorgen, dass dem User die Folgen seines Urteils bewusst sind und er die Aktion nicht versehentlich auslöst. Dazu gehören mindestens folgende Vorsichtsmaßnahmen:

• Event-Buffer löschen (Mausklicks, Tastenanschläge).
  Dies verhindert, dass das Programm auf Entscheidungen reagiert, die
  für einen anderen Dialog gedacht waren.
• Keine Defaultaktionen verwenden. Zu leicht löst eine
  versehentlich berührte Leertaste die Aktion aus. Als sichere
  Variante bleibt nur, nichts zu tun. Auf keinen Fall darf der User
  versehentlich ein Dokument signieren.
• Im Zweifel einen Anwalt fragen, um Wortwahl und Aufbau des
  Dialogs so zu gestalten, dass Gerichte die Entscheidung des Users
  anerkennen.

In Abbildung 2a ist der erste Entwurf eines Warndialogs zu sehen, gedacht für ein Programm, das digitale Signaturen ausstellt. Ein Anwalt könnte vor Gericht behaupten, dass seine Klientin mit dem Klick auf »OK« bloß eine Warnung quittierte. Da Richter selten eine fundierte IT-Ausbildung genossen haben, stehen die Chancen gut, dass der Anwalt damit durchkommt und das Gericht den Vertrag für nichtig erklärt.

Abbildung 2a: Der erste Entwurf eines Dialogs, der auf einen Vertragsabschluss hinweist, beschränkt sich auf eine Allerweltsbeschriftung der Buttons.

Richtige Beschriftung

Im zweiten Versuch haben die Entwickler hinzugelernt und die Beschriftung der Buttons geändert (Abbildung 2b). Jetzt muss jedem Benutzer klar sein, dass er mit dem Klick auf »Signieren« den Vertrag unterschreibt. Trotzdem gibt es ein Schlupfloch für Advokaten: Der »Signieren«-Button liegt an der Stelle, an der sich üblicherweise der »Abbrechen«-Knopf befindet. Mit Halbwissen aus den Design-Richtlinien der Plattform bewaffnet könnte der Anwalt einen Richter davon überzeugen, dass inkompetente Entwickler mit der falschen Anordnung ihre User verwirren. Der dritte Anlauf schließlich (Abbildung 2c) berücksichtigt auch diese Forderung.

Abbildung 2b: Schon besser: Durch die eindeutige Beschriftung wird dem User klar, dass er per Klick auf den mittleren Button eine Signatur ausführt.

Abbildung 2c: In der dritten Fassung sortieren die Entwickler die Schaltflächen in der üblichen Reihenfolge, um Verwirrung zu vermeiden.

Solch kleinkariert anmutende Anfeindungen muss ein Programm bestehen, will es auch im feindlichen Umfeld einer Gerichtsverhandlung nicht den Kürzeren ziehen. Gefährlicher als der verrückteste Phisher und schlimmer als jeder Geheimdienst sind Expertengutachten der Gegenseite. Auch gegen ihre gefürchteten und ausgeklügelten Attacken muss sich eine Applikation wappnen.

Sichere Vorgaben

Ein sicheres Programm braucht sinnvolle Defaults. Insbesondere muss die am nächsten liegende Option auch die sicherste sein. Klickt ein Benutzer in jedem Dialogfenster auf »OK«, sollte das ihn und andere nicht in Schwierigkeiten bringen. Ein Beispiel ist in Abbildung 3a und 3b zu bewundern: Egal was im Text des Fensters steht, die Anwender werden den Dialog nur als Hindernis wahrnehmen und wie üblich auf »Ja« (oder »OK«) klicken. Wäre »Ja« die sichere Variante, dann würde die instinktive Handlung des Users ihn schützen.

Abbildung 3a: Die Entwickler überlassen in diesem Dialog dem User die Beurteilung, ob das nicht näher genannte Sicherheitsproblem gefährlich ist.

Abbildung 3b: Die Benutzer nehmen den Dialog aus Abbildung 3a so wahr wie diesen und klicken wie immer auf »Ja«. Sie wollen nur schnell weiterarbeiten.

Usability-Tests haben gezeigt, dass manche Benutzer tatsächlich in jedem Fenster »OK« anklicken. Daraus leitet sich ein einfaches Testverfahren ab: Der Entwickler wählt in einem Versuch immer und überall »OK« und prüft, ob das Ergebnis in jedem Fall die sichere Entscheidung war. Darauf folgt ein zweiter Versuch unter der Annahme, dass jede Frage aus einem Angriff resultiert. Wenn hinter »Wollen Sie das Dokument wirklich öffnen« nicht die Einladung zur Weihnachtsfeier warten, sondern ein Wurm mit einem Makro-verseuchten Office-Dokument, verwandeln sich vermeintlich harmlose Fragen schnell in heikle Entscheidungen. Sehr viele Programme halten diesem primitiven Test nicht stand.

Wechselspiel

Ein wirksames Mittel gegen das Ja-Klicker-Problem sind Multiple-Choice-Fragen an Stelle einfacher Ja-Nein-Entscheidungen. In einem realistischen Testszenario [6] mussten Kandidaten die Korrektheit von Schlüssel-Fingerprints bewerten. Ein Drittel der Kandidaten fiel Angriffen zum Opfer, wenn ihnen das System einfache Ja-Nein-Fragen stellte. Hatten sie dagegen die Wahl zwischen fünf Optionen, bei denen eine “keine Antwort ist korrekt” lautete, fiel die Fehlerrate auf nahezu null. Während beim Ja-Nein-Test die Kandidaten nicht lange überlegten und sogar erkennbare Unregelmäßigkeiten als vorübergehende Fehler deuteten und einfach ignorierten, zwang sie die längere Auswahlliste dazu, über das Problem und die korrekte Lösung nachzudenken.

Die Windows-Shareware Winzip nutzt eine ähnliche Technik: Solange das Programm nicht bezahlt und registriert ist, begrüßt es den Anwender mit einem Hinweisdialog. Bei jedem Start vertauscht die Software die Anordnung der Buttons. Das zwingt die User, den Text zu lesen statt blind »Cancel« zu drücken. Auch der neuseeländische Zoll vertauscht auf seinem Einwanderungsformular einige der Ja-Nein-Fragen. Damit wird es unmöglich, einfach alle Kästchen in einer Spalte anzukreuzen, ohne die Fragen zu lesen. Das ist besonders hinterhältig, wenn man bedenkt, dass die Leute dieses Formular nach ihrem 12-Stunden-Flug noch im Halbschlaf ausfüllen.

Gute Bremsen

Auch viel versprechend: Die gefährliche Antwort für einige Zeit sperren (nicht anklickbarer, grau gefärbter Button). Das gibt dem User Zeit, den Text der Dialogbox tatsächlich zu lesen, bevor er sich in Gefahr begibt. Um keine Verwirrung zu stiften, braucht der Button einen sichtbaren Countdown. Daran erkennen die Anwender, dass es nach der Pause weitergeht, und nutzen die Zeit wirklich fürs Lesen und Überlegen.

Auch diese Technik ist von lästigen Registrierdialogen bekannt. Eventuell bleibt nichts anderes übrig, um User zum Nachdenken zu bewegen. Klar ist aber auch, dass ihr Einsatz eine seltene Ausnahme bleiben muss. Gar nicht störend, aber ebenfalls wichtig: In Sicherheits-Dialogfenstern auf den Schließen-Button im Fensterrahmen verzichten.

Plädoyer für Einfachheit

Eine weitere Empfehlung lautet, den sicheren Defaultfall einfacher zu gestalten als die riskante Variante, denn bei dieser muss dem Anwender klar sein, dass er etwas Gefährliches unternimmt. Gut gelöst hat dies ein Datenbank-Replikationssystem, bei dem der Master-Server mehrere Slaves steuert. Das Kommando zum Start eines Slave lautet »start slave«. In dieser Form nutzt es SSL, um die Kommunikation zu schützen. Um auf SSL zu verzichten, muss der Anwender »start slave without security« wählen. Das kostet mehr Aufwand und hinterlässt ein unbehagliches Gefühl.

Ganz anders arbeiten E-Mail-Clients: Per Default kommunizieren sie im Klartext mit dem Mailserver. Das ändert sich erst, wenn der User ein Häkchen vor »Use SSL« setzt. Zu allem Überfluss versteckt sich diese Option tief in den Konfigurationsdialogen oder ist nur per Kommandozeilenoption erreichbar. Klar, dass die meisten Benutzer gar nicht auf die Idee kommen, SSL anzuschalten.

Kleine Änderungen mit großer Wirkung

Die vorgeschlagenen Änderungen in der Oberfläche und beim Verhalten von Sicherheitssoftware sind relativ klein. Dennoch entscheiden sie darüber, ob Sicherheitsfunktionen überhaupt zum Einsatz kommen oder brach liegen. Statt nur auf den theoretisch erreichbaren Schutz zu bauen, ist es beim Software-Entwurf entscheidend, auch die praktische Seite zu betrachten. (fjl)