Software soll sich am User orientieren und nicht umgekehrt – diese simple Weisheit gilt bei Sicherheitsprogrammen besonders. Nur wenn die Applikation sich jederzeit verhält wie erwartet, eine verständliche Sprache spricht und optische Hilfen gibt, schützt sie den Anwender ausreichend.

Anwender haben oft sehr konkrete Vorstellungen, wie Software zu funktionieren hat und in welcher Reihenfolge welche Tätigkeiten anstehen sollen. Weicht ein Applikation von diesem Schema ab, bereitet sie den Benutzern große Schwierigkeiten. Als abschreckendes Beispiel eignet sich das Erzeugen eines Schlüsselpaars (öffentlicher und privater Key). Wer an einer Unix-Kommandozeile sitzt, wirft gewöhnlich GPG oder OpenSSL an, füttert die Kommandozeile mit einer länglichen Folge von Optionen, reagiert auf Nachfragen des Programms und wartet darauf, dass das Tool die Schlüssel an der vom User vorgegebenen Stelle ablegt. Für CLIs (Command Line Interfaces) ist dieser Ablauf normal, die Benutzer erwarten es nicht anders.

Dummerweise haben die GUI-Entwickler das Interface stur übernommen: Die Option »-k Schlüssellänge« mutiert mal zu einer Combobox mit einer Liste vorgegebener Werte und aus »-a Algorithmus« wird vielleicht ein Satz Checkboxen. Abbildung 1 zeigt eines dieser missglückten Designs. Dieses Exemplar scheut nicht einmal davor zurück, in einem Expertenmodus den User wieder auf die Kommandozeile zurückzuwerfen.

Abbildung 1: KGPG dient als grafisches Frontend zu GPG. In diesem Dialog erzeugt der User einen neuen Schlüssel. Leider orientiert sich die Oberfläche viel zu sehr am Kommandozeilen-Original.

Dieses GUI ist lediglich eine grafische Fortsetzung des CLI, die jeder Kommandozeilenoption ein grafisches Element zuordnet. Doch damit nicht genug: Die Optionen verteilen sich manchmal über mehrere aufeinander folgende Fenster. Eine große öffentliche CA (Certification Authority) geht noch weiter, sie quält ihre User durch elf Bildschirmseiten, in denen sie ihre Daten eintippen, bevor sie ein Schlüsselpaar erzeugen dürfen.

Halbe Sachen

User, die das Kommandozeilen-Interface kennen, finden sich in diesen GUI-Umsetzungen noch ganz gut zurecht. Wer über diesen Erfahrungsschatz nicht verfügt, wird die Oberfläche dagegen kaum verstehen. Ihm bereitet es dann enorme Mühe, ein Schlüsselpaar für einen E-Mail-Client oder für den Webserver anzulegen. Er wird sich mindestens folgende Fragen stellen:

• Was ist ein Schlüsselpaar?
• Warum brauche ich zwei Keys statt nur einen?
• Welche Schlüsselgröße brauche ich?
• Wer sind DSA und El Gamal?
• Was passiert nach Ablauf der Gültigkeit des
  Schlüssels?
• Warum fragt mich mein E-Mail-Programm nach der E-Mail-Adresse
  – die kennt das Programm doch längst?
• Was kommt ins Kommentarfeld?
• Warum kennt der Computer meinen Namen nicht, ich habe mich doch
  eingeloggt?

Kurz gesagt: Dieser Dialog ist unbrauchbar, das Beste, was ihm passieren kann, ist ein freundliches »rm -rf«.

Auch die tollste Anwendung ist für die meisten Benutzer nur ein Werkzeug und kein Selbstzweck. Statt sich auf die Haken und Ösen der Schlüsselerzeugung zu konzentrieren, braucht das Programm einen anderen Fokus. Der User will nur eine Aufgabe erledigen – dabei sollte ihn das Programm so weit möglich unterstützen und nicht behindern.

Von Microsoft stammt der Name “Activity-Based Planning”. Wer diesem Designprinzip folgt, stellt zunächst eine Liste von Aufgaben zusammen, die der Benutzer erledigen will, und baut das Userinterface dann passend zu diesen Abläufen. Herkömmliche GUIs stapeln dagegen atomare Operationen und erwarten, dass der Benutzer die wichtigen Stellen selbst findet. Dabei jagen sie ihn durch unübersichtliche Menüs und verworrene Dialoge.

Activity-Based Planning

Aktivitätsorientiertes Planen richtet sich danach, wie Anwender ihre Wünsche äußern. Sie setzen sich Ziele wie “Meine Patientenakte muss vertraulich bleiben” oder “Ich will sichergehen, dass die Person/Firma, mit der ich gerade rede, auch die ist, die sie vorgibt zu sein”. Niemand denkt “Ich will ein X.509v3-Zertifikat zusammen mit Triple-DES-Verschlüsselung verwenden, um meinen Kommunikationskanal abzusichern”.

Eine weitere Lehre daraus: Statt mit dem Vokabular der Security-Experten zu jonglieren, muss Software Sicherheitsaufgaben mit den Worten präsentieren, in denen der Anwender denkt und die er versteht. Nur so haben die User eine Chance, zu begreifen, was sie gerade machen, und werden die vorhandenen Sicherheitsfeatures auch nutzen.

Auf die Schlüsselerzeugung angewandt bedeutet dies: Es gibt zwei Aktivitäten, einmal einen Schlüssel zum Schutz von E-Mail erzeugen und einmal einen zum Schutz der Websurfer – genauer gesagt einen Key für einen SSL-Server. Das dazu passende Interface lässt den User erst wählen, welche dieser Aktivitäten er plant, und fragt anschließend nach Name und E-Mail-Adresse beziehungsweise Webserver-Domäne. Aber selbst das geht noch besser: Ist der Dialog Teil der zu schützenden Anwendung, kann er sich die Fragen nach Namen und Adressen sparen oder wenigstens die bekannten Daten vorab ausfüllen.

Selbst für Stand-alone-Programme gilt keine Ausrede, alle Daten vom User erneut zu verlangen, wenn diese bereits in »/etc/passwd« oder der Konfiguration eines E-Mail-Programms vorliegen. Durch die Vielzahl an Mailclients unter Linux ist Zweiteres eine Herausforderung für die Entwickler, der sich zu stellen durchaus lohnt. Selbst wenn der User die vom Programm vorab ausgefüllten Daten nicht verwendet, ist der Schritt hilfreich: Er gibt ihm eine Vorlage, was das Programm erwartet, statt ihn mit einem leeren Eingabefeld allein zu lassen.

Aktivitätsorientierte Designs sind sorgfältig zu planen. Sie müssen die Aufgabenstellung der meisten Anwender abdecken, ohne Benutzer abzuschrecken oder sie in das Korsett eines festen Ablaufs zu zwängen, den sie gar nicht wollen. Schlecht formulierte Aufgaben zwingen den User gar, den Programmentwurf zu analysieren und zu raten, welcher Knopf zum Ziel führt. Besonders verwirrend geben sich zum Beispiel viele der interaktiven Telefondienste von Fluglinien, Banken und anderen Firmen im Internet.

Braucht ein Wizard mehr als drei oder vier Schritte, um einen Schlüssel zu erzeugen, ist ein Redesign fällig. GPA (GNU Privacy Assistant), der zur selben Programmkategorie gehört wie KGPG, benutzte ursprünglich ein fast identisches Dialogfenster wie KGPG. In jüngeren Versionen löst ein Wizard diesen Dialog ab, einer der Schritte ist in Abbildung 2 zu sehen. Leider beschränkt der Wizard sich darauf, die unverständlichen Eingabefelder des Dialogfensters in viele kleine Stücke zu zersägen. Zu den Sünden des Originals gesellt sich damit Langzeitfolter.

Abbildung 2: Einer von zu vielen Schritten beim Erzeugen eines Schlüssel mit GPA. Es genügt nicht, normale Dialoge durch Wizards zu ersetzen und die alten Eingabefelder neu anzuordnen.

Ausweg für Profis

Die Liste der vorgegebenen Handlungen kann nie jeden User glücklich machen. Statt die verbleibenden Anwender und deren Spezialwünsche zu gängeln, muss ihnen das GUI die Möglichkeit anbieten, einen Schlüssel ganz nach ihren Wünschen anzulegen. Selbst die Telefondienste erlauben etwas Vergleichbares und stellen bei Bedarf zum menschlichen Hotline-Mitarbeiter durch, der alle Sonderfälle aufnimmt.

Taktisch klug ist es daher, zusätzlich ein alternatives Interface vorzuhalten. Hinter der Bezeichnung »Expertenmodus« oder »advanced mode« öffnen sich den Power-Usern dann alle Optionen und alle Details – wie KGPG einfach auf die Kommandozeile zurückzugreifen ist allerdings keine gute Idee.

Es ist aber nur eine Minderheit, die diesem Grad an Konfigurierbarkeit etwas abgewinnt, sie jammert zwar laut, wenn sie ihren Lieblingsalgorithmus und ihre krumme Schlüssellänge vermisst. Doch das einfache, geradeaus gedachte Interface muss der Defaultfall bleiben. Gelegenheits-User ändern die Konfiguration ihres Programms nicht, selbst wenn es eine Option für einfaches Arbeiten gibt. Sie fürchten zum Beispiel, damit etwas kaputt zu machen.

Designbeispiel: Schlüssel erzeugen

Wie aktivitätsorientiertes Design bei der Schlüsselerzeugung aussieht, zeigt eine Übung. Die Aufgabe lautet, einen User-Key für E-Mail-Verschlüsselung zu kreieren. In Abbildung 3 ist die erste Seite des Wizard zu sehen. Sie erklärt, was warum passieren wird, und sie enthält den automatisch ermittelten Namen und die Mailadresse. Stimmen die Daten nicht, erlaubt es das Programm, die korrekten Details anzugeben.

Abbildung 3: Teil eins des Wizard, der dem User dabei hilft, einen Key zu erzeugen. Er orientiert sich an den Zielen des Anwenders.

Etliche Details sind wichtig in diesem simplen Dialog. Zum Beispiel nennt die Titelleiste den Vorgang “Schlüssel erzeugen” und nicht “Schlüssel generieren”, wie in vielen anderen Schlüssel-GUIs. Benutzer erzeugen auch Dokumente und Bilder, sie generieren sie nicht, daher ist dieser Begriff vertrauter. Außerdem spricht der Text nur von “Schlüssel” und nicht von einem “Schlüsselpaar”. Weil die meisten User das Prinzip der asymmetrischen Kryptographie nicht kennen, verwirrt die technisch korrekte Bezeichnung mehr, als sie hilft. Außerdem sagt die Titelzeile klar, dass es nur noch einen weiteren Schritt gibt. Der User braucht keine Langzeitfolter zu befürchten.

Bekannte Metaphern

Viele User schrecken davor zurück, Sicherheitsfunktionen einzuschalten, weil sie die Schwierigkeiten beim Einrichten mehr fürchten als die Gefahr durch fehlende Security. Gut gewählte Metaphern helfen diese Zurückhaltung zu überwinden. Jeder kennt zum Beispiel Schlüssel und deren Sicherheitsfunktion im realen Leben. Schlüsselähnliche Geräte eignen sich folglich, um Sicherheitsparameter zwischen Systemen zu übertragen: ein USB-Stick etwa. Wie das sinnvoll funktioniert, macht das WNSK vor (Windows Network Smart Key). Windows speichert den WIFI/802.11-Verschlüsselungs-Key zusammen mit anderen Konfigurationsdaten auf einem USB-Medium (Abbildung 5). Der Benutzer steckt diesen USB-Stick einfach in die weiteren Geräte seines WLAN, um sie ebenfalls sicher zu konfigurieren. Abbildung 5: Jeder herkömmliche USB-Speicherstick eignet sich hervorragend als Sicherheitsmedium. Seine Handhabung erinnert an Schlüssel. Weil USB-Sticks über genügend Speicher verfügen, gelingt es damit, den kompletten Vorgang zu automatisieren, ohne auf Sicherheit zu verzichten (WNSK-Dateien sind etwa 100 KByte groß). Kein Mensch würde diese Daten komplett abtippen wollen – aus Kompatibilitätsgründen ist es dennoch möglich, die wichtigsten Teile des WNSK-Inhalts auszudrucken und auf dem Zielsystem wieder einzutippen. Zeitlich und örtlich beschränkt Die bekannte Schlüsselmetapher sorgt dafür, dass die User den Mechanismus verstehen und tatsächlich einsetzen. Zudem ist er sehr einfach anzuwenden. In der Fachsprache heißt so etwas Location-limited Channel. Der Kommunikationskanal ist sicher, weil nur legitime User physikalischen Zugang zu den konfigurierten Geräten haben. Kennt das Bedrohungsszenario Angreifer, die über das Netzwerk eindringen, dann ist dieser einfache Kanal sicherer als jeder noch so komplexe Smartcard-, X.509- und CA-Ansatz. Über das Netz schafft es kein Angreifer, einen USB-Stick anzustöpseln. Ähnlich dem örtlich limitieren Kanal funktioniert die zeitlimitierte Variante namens Time-limited Channel. Zwei Geräte müssen dabei ihre Sicherheitsinitialisierung in einer sehr kurzen Zeitspanne abschließen, beispielsweise indem der Anwender gleichzeitig einen Knopf an beiden Geräten drückt. Das zu initialisierende Gerät nimmt an, dass nur erwünschte Partner in just diesem Moment antworten. Dieser Mechanismus kombiniert zeitlich und örtlich limitierte Kanäle, weil der Benutzer den Knopf physisch drücken muss und weil das gleichzeitig auf zwei Geräten zu geschehen hat. Einfach und trotzdem sicher Diese Techniken vereinen sehr einfache Anwendung mit einem hohen Grad an Sicherheit. Allerdings ist Vorsicht angesagt, zum Beispiel beim örtlich limitierten Kanal: Hier haben die Bluetooth-Entwickler einen entscheidenden Fehler begangen. Bei ihrer Technik darf jeder, nicht nur der autorisierte Benutzer, eine Sicherheitsinitialisierung erzwingen (genannt Forced Re-Pairing). In der Folge hat sich Bluejacking zum Volkssport entwickelt. Spaßvögel und üble Zeitgenossen kapern damit munter fremde Bluetooth-Geräte. Wer einen ähnlichen Sicherheitsmechanismus entwickelt, sollte sich genau ansehen, was Bluetooth macht, und es auf gar keinen Fall imitieren.

Sinnvolle Defaults

Als Default-Button ist mit Absicht »Schlüssel erzeugen« aktiviert. Das gibt den meisten Usern die Chance, durch einen einfachen Druck auf die [Enter]-Taste voranzukommen. Zudem ist der Button mit einem Imperativ beschriftet statt einer passiven Bestätigung. Die Aufschrift »Schlüssel erzeugen« verdeutlicht, welche Aktion der Knopf auslöst, ganz im Gegensatz zum gefürchteten »OK«. Auch wer sofort [Enter] drückt, darf sicher sein, das Richtige zu tun, ohne durch mehrfaches Textstudium zu ergründen, was »OK« hier bedeutet.

Zu guter Letzt verzichtet das Dialogfenster auf den üblichen Schließen-Button. Dieser Trick vermeidet, dass der User mit einem blinden Klick in die rechte obere Ecke das Fenster los wird und sich später wundert, warum sich sein Programm über einen fehlenden Schlüssel beklagt.

Öffentlichkeitsarbeit

Der nächste Schritt (Abbildung 4) informiert den Anwender darüber, dass sein Schlüssel fertig ist und das Programm ihn gespeichert hat. Damit steht er für die weitere Benutzung bereit. Wieder gibt der Default-Button den sinnvollen Weg vor, nämlich den Schlüssel anderen Nutzern zugänglich zu machen. Sollte sich der Benutzer dagegen entscheiden, landet er in einem Expertenmodus-Dialogfenster. Dort erfährt er, dass er sich nun selbst um die Key-Distribution kümmern muss und beispielsweise einen Schlüsselexport in Textform auf seine Homepage stellen kann.

Abbildung 4: Im zweiten Schritt fragt der Wizard freundlich, ob der Benutzer seinen öffentlichen Schlüssel publizieren will.

Der abschließende Schritt in Abbildung 6 teilt dem Benutzer mit, dass sein Schlüssel nun bereitliegt. Bei diesem Interface genügt es sogar, dass der User dreimal auf [Enter] drückt, ohne sich die Mühe zu machen, den Text in den Dialogfenstern zu lesen.

Abbildung 6: Zum Abschluss informiert der Wizard, dass alles gut gegangen ist.

Je nach der konkreten Situation braucht dieser Dialog als weiteren Schritt eventuell ein Eingabefeld für ein Passwort oder eine PIN, um damit den neuen Key zu schützen. Unnötig ist das, wenn der Key in einem USB-Security-Token oder auf einer Smartcard landet, die bereits PIN-geschützt sind, oder wenn der User beim Start der Applikation bereits ein Master-Passwort eingetippt hat (im Sinne eines Personal Security Environment oder Passwort-Safes).

Gerade bei schwierigen Themen wie der Computersicherheit muss Software die Sprache ihrer Benutzer sprechen. Sie brauchen die Motivation und die Fähigkeit, den Inhalt einer Sicherheitsmeldung zu verstehen. Vielen Entwicklern fällt es aber schwer, aus ihrer Insiderposition heraus zu beurteilen, wie unverständlich ihre Schöpfungen für technisch nicht versierte Anwender ausfallen.

Die Sprache der Anwender

Am einfachsten ist diese Sprachhürde zu überwinden, wenn Entwickler ihre künftigen Anwender fragen, was die tatsächlich vom Interface erwarten. Dummerweise stellt sich in der Praxis heraus, dass es viele Formulierungen für identische Aufgaben gibt. Wer seine Untersuchung auf ein oder zwei User begrenzt, erreicht eventuell das Gegenteil und verwirrt andere Anwender. Besser ist es, eine Liste mit Vorschlägen der User anzulegen und eine größere Gruppe abstimmen zu lassen.

Eine Studie zeigte, dass Benutzern mit Interfaces, die aus solchen Abstimmungen entstanden sind, zwei- bis fünfmal weniger Fehler unterlaufen als bei herkömmlichen GUIs mit technischer Terminologie. Dieselbe Studie untersuchte auch die Fehlerraten nach längerer Gewöhnungsphase: Mit der Zeit glichen sie sich an. Das zeigt, dass User irgendwann jedes GUI erlernen. Doch haben sie kaum eine Chance, sobald das technisch formulierte Programm wieder einen neuen Dialog hervorbringt – was gerade in kritischen Situationen der Fall ist.

Handbücher

Ähnliches gilt für Hilfetexte und Handbücher. Auch hier kann es sich lohnen, die Texte nicht ausgerechnet von Sicherheitsspezialisten schreiben zu lassen. Dann bleiben Wortwahl und Gedankengänge für die Leser eher nachvollziehbar. Die Fachleute sollten erst am Schluss auf inhaltliche Korrektheit prüfen.

Zur richtigen Ansprache der Benutzer gehört es auch, die Botschaft optimal zu vermittelt. Statt wild in den Fenstern herumzuklicken, sollen die User schließlich die Textbotschaften lesen und verstehen. Anders als beim reinen Interface-Design hat das Vermitteln von Botschaften eine lange wissenschaftliche Tradition (siehe Kasten “Psychologie im Dialog”), von der Werbung und Politik seit langem profitieren.

Psychologie im Dialog

Sozialpsychologen haben herausgefunden, dass eine Anfrage weit mehr Erfolgsaussichten hat, wenn ihr eine Erklärung beiliegt [1]. Den User einfach nur zu fragen, ob er ein ungültiges SSL-Zertifikat akzeptiert, genügt nicht. Steht im Dialogfenster zusätzlich “Das ungültige Zertifikat könnte es Kriminellen ermöglichen, Geld von Ihrem Konto zu stehlen”, dann haben Benutzer ein größere Chance, die Situation korrekt zu beurteilen. Dieser Text profitiert noch von einer anderen interessanten Erkenntnis der Psychologen: Die Angst, etwas zu verlieren, motiviert mehr als die Aussicht, etwas zu gewinnen ([2], [3]). Der Mechanismus funktioniert verblüffend einfach: Wenn ein Arzt seinem Patienten sagt, “Falls Sie das Rauchen nicht aufgeben, haben Sie fünf Jahre weniger zu leben”, dann erreicht er damit mehr als mit der positiven Formulierung “Wenn Sie das Rauchen aufgeben, haben Sie fünf Jahre mehr zu leben” [4]. Auf den Webbrowser übertragen bedeutet das: Lieber warnen, jemand könnte Geld stehlen, als zu beteuern, dass ein gültiges Zertifikat für ein sicheres Konto sorgt. Abbildung 7: Einen Teil der Stühle besetzen viele Theater mit Profi-Applaudierern, um Besucher an passenden Stellen zum Jubeln anzuregen. Dieser Mitmach-Effekt klappt auch bei Sicherheitssoftware. (Bild: © photocase.com) Offene Fragen statt Wunsch nach Bestätigung User denken intensiver nach, wenn das Programm ihnen eine Frage stellt, als wenn es nur eine Zusage erwartet. “Etwas ist schief gelaufen. Wollen Sie fortfahren?” ist im Grunde nur eine Beteuerung, die sich als Frage tarnt. Besser ist daher: “Wollen Sie sich mit der Website verbinden, obwohl dies Kriminellen erlauben könnte, Geld von Ihrem Konto zu stehlen?” GUIs können auch von dem Phänomen der sozialen Bestätigung profitieren. Viele Menschen tendieren dazu, Dinge zu tun, nur weil andere es auch tun. Die anderen können eine Autorität oder auch eine große Menschenmenge sein. Dieser Trick ist weithin bekannt und wird oft verwendet. In jedem Spendentopf befindet sich vorab schon Geld, im Theater sitzen professionelle Applaudierer und TV-Serien spielen die Lacher an der passenden Stelle von Band ab. Obwohl Schauspieler und Zuschauer die Lacher von Band nicht mögen, funktioniert der Trick zuverlässig. Die Lacher sind offenkundig nicht echt und die meisten Zuschauer glauben, dass sie sich davon nicht beeinflussen lassen. Dennoch lösen sie die gewünschte Reaktion aus und eignen sich als soziale Bestätigung. Das gilt auch für die oben genannten Mechanismen: Egal ob man an sie glaubt oder nicht, sie funktionieren in der Praxis. Klug getextet Soziale Bestätigung hilft dem User bei der Entscheidung. Etwa bei einer sicherheitsrelevanten Frage: “Für die meisten Anwender ist XYZ die beste Wahl”, wobei XYZ die sicherste und vernünftigste Variante ist. Selbst wenn später einmal dieser Hinweis in einem anderen Programm fehlt, weiß der Anwender, welche Entscheidung vernünftig ist. Wer mehr über dieses Forschungsfeld erfahren will, findet in [5] und [6] einen guten Einstieg. Hoffentlich kommen Phisher nicht auf die Idee, solche Bücher zu studieren.

Keine Na-und-Fragen

Ein einfacher Test gibt Aufschluss über die Qualität einer Botschaft. So lange als Antwort “Warum?” oder “Na und?” möglich sind, ist der Text faul. Ein Programm könnte sagen: “Die Serveridentifikation hat sich seit der letzten Verbindung geändert.” Na und? “Das könnte ein falscher Server sein, der sich für den richtigen ausgibt, oder der richtige wurde neu installiert.” Na und? “Wenn dies ein falscher Server ist, könnten Kriminelle jede Information missbrauchen, die Sie eingeben. Sind Sie sicher, dass Sie fortfahren wollen?” Damit weiß der User endlich, warum ihn das Programm mit diesem Dialog stört.

Die “Warum”- und “Na und”-Fragen passen zwar nicht immer (meist passt nur eine), aber wenn der Dialogentwurf einer dieser Prüfungen nicht standhält, ist fast immer ein Redesign fällig.

Designbeispiel: Schlüssel geändert

Als Designbeispiel für “Spreche die Sprache der Anwender” eignet sich ein Warndialog, der auf einen geänderten Server-Key verweist. Dieser Key ist üblicherweise mit der Identität des Servers verknüpft. Viele Anwendungen zeigen in dieser Situation entweder zu wenig Informationen (“Der Schlüssel hat sich geändert. Fortfahren?”), zu viel (besonders X.509-Jargon, mit dem kein Normalanwender etwas anzufangen weiß) oder die falschen Informationen (“Der Himmel stürzt ein, lauf weg”).

Ein denkbar schlechtes Vorbild liefert der Internet Explorer (Abbildung 8). Jeder Normalanwender versteht hier nur noch Bahnhof – obwohl diese Fassung schon besser ausfällt als ältere Versionen. Selbst ein vorsichtiger Zeitgenosse, der mit einem Klick auf »View Certificate« nach den Hintergründen fahndet, ist verloren. Er weiß nicht, wonach er in der Menge an Infos Ausschau halten soll. Zudem ist dieser Schritt reichlich sinnlos: Kann die SSL-Implementierung das Zertifikat nicht verifizieren, dann gilt dessen Inhalt als nicht vertrauenswürdig. Jeder einzelne Eintrag könnte gefälscht sein – und das so geschickt, dass er den User gezielt austrickst.

Abbildung 8: Die Zeritifikatswarnung des Internet Explorer verwirrt User. Sie packt zu viele Informationen mit unzureichenden Erklärungen in ein Fenster.

Der Autor dieses Dialogs unternahm keinerlei Versuch, die Schwere des Fehlers zu beurteilen. Ein Zertifikat ist einen Tag nach seinem Ablaufdatum weniger kritisch als eins, das seine Gültigkeit vor einem Jahr verloren hat. Noch schlimmer sind Zertifikate, die für eine andere Domäne gelten oder gar solche, die von einer unbekannten CA stammen. Ohne Hilfe durch den Dialog kennt kein Anwender diese Unterschiede.

Der Dialog in Abbildung 8 erspart dem Entwickler Arbeit, weil er nur ein Fenster entwirft, das vermeintlich auf jede Situation passt. Das fordert den User aber geradezu dazu auf, das Problem zu ignorieren und fortzufahren. Das einzige Gute an diesem Fenster ist »No« als Default-Aktion. Der Anwender muss immerhin die Maus auf »Yes« bewegen, um das Fenster loszuwerden.

Aus der Perspektive des Benutzers ist der Wunsch, das Fenster loszuweren, verständlich. Er verbindet sich mit einem Server, den er bereits häufig benutzt hat und den er braucht, um seinen Job zu erledigen. Seine natürliche Reaktion ist, alles aus dem Weg zu räumen, was ihn dabei behindert. Für ihn reduziert sich dieser Zertifikatsdialog zu: “Wollen Sie, dass diese Meldung verschwindet?”

Der Dialog müsste wenigstens – wie oben beschrieben – die Hintergründe erklären. “Die Server-Identifikation hat sich seit der letzten Verbindung geändert. Es könnte ein falscher Server sein, der sich für den richtigen ausgibt, oder der richtige wurde neu installiert. Wenn es ein falscher Server ist, könnten Kriminelle jede Information missbrauchen, die Sie eingeben. Sind Sie sicher, dass Sie fortfahren wollen?”

Vorsicht

Je nach den möglichen Folgen eines falschen Servers sollte es die Anwendung erlauben, mit reduziertem Funktionsumfang (sicherer Modus) fortzufahren, der etwa Uploads verbietet und Daten vom Server misstrauisch behandelt. Die Applikation könnte auch verlangen, dass der Anwender mit dem Admin des Servers kommuniziert, um die Authentizität zu prüfen. Wer will, fügt zudem einen Button »Technische Details« ein, der das X.509-Geplapper wiedergibt.

Drastischer, aber weit effektiver ist es, Fehler in Schlüsseln und Zertifikaten wie einen normalen Serverfehler zu behandeln. Wenn der User erwartet, mit einem Bankserver sicher zu kommunizieren, dann bedeutet mangelnde Sicherheit einen ganz und gar fatalen Fehler und keine simple Hürde, die ein Klick beseitigen darf. Einige Clients handeln bereits entsprechend, zum Beispiel der »xsupplicant« von Linux oder der PEAP-Client in Windows XP.

Serverfehler verstehen die User instinktiv, das erhöht den Druck für der Serveradmin. Nicht mehr der Anwender ist in der Pflicht, die Situation korrekt einzuschätzen, sondern der Admin. Der hat für korrekte Zertifikate zu sorgen und seinen Server sauber zu halten. Vermutlich ist das der einzige Weg, X.509 halbwegs sicher in der Praxis einzusetzen, statt auf die Sicherheit eines Placebos zurückzufallen.

Kompromiss

Eine dritte Alternative erlaubt es dem User, neue Zertifikate oder geänderte Schlüssel auf sichere Weise zu akzeptieren. Statt blind auf »OK« zu klicken, fordert das Programm einen Autorisierungscode. Diesen Code erhalten die Anwender nur vom Serveradmin oder vom Besitzer des Zertifikats. Die Software verlangt dafür einen eigenen Kommunikationskanal, zum Beispiel das Telefon. Das zwingt die Anwender den Key zu verifizieren, bevor sie ihn einsetzen.

Als Autorisierungscode eignet sich eine kurze Zeichenkette von sechs bis acht Stellen, mit denen die Software einen HMAC erzeugt (Hashed Message Authentication Code). Die ersten beiden Stellen dienen als HMAC-Schlüssel, der Rest ist das (verkürzte) Resultat. Sind »ab« die beiden ersten Zeichen, dann erfolgt die Berechnung mit »HMAC (“ab”, Schlüssel oder Zertifikat)«. Lautet die Base-64-Kodierung der letzten Bytes »defg«, dann ist »abcdefg« der Autorisierungscode (Abbildung 9). Tippt der User diesen Wert ein, führt sein Programm die gleiche Berechnung durch und erkennt das Zertifikat oder den Schlüssel nur an, wenn die Werte übereinstimmen.

Abbildung 9: Mit diesem einfachen Schema berechnet die Serversoftware einen Autorisierungscode für ein Zertifikat. Nur wenn der Anwender ein bis dato unbekanntes Zertifikat mit diesem Code autorisiert, akzeptiert es sein Clientprogramm.

Zwangshandlung

Der Einsatz dieses HMAC als Salted Hash ist zwar nicht besonders sicher, das braucht er aber auch nicht zu sein. Er hat nur die Hürde für einen Angreifer zu erhöhen. Statt einfach eine Phishing- oder Spam-Mail mit der Adresse eines gefälschten Servers rauszuschicken, muss er sich nun zusätzlich als legitimer Eigentümer des Zertifikats ausgeben und den User dazu bringen, den Autorisierungscode einzutippen. Ein hartnäckiger Angreifer wird zwar auch diese Hürde nehmen, aber sein übler Job gestaltet sich nun deutlich schwerer.

Die Wahl eines HMAC statt eines einfachen Hash ist kein Zufall. Viele Programme zeigen bereits einen Hash an, meist als Fingerprint oder Daumenabdruck bezeichnet. Wer diesen Code abtippt, würde die zusätzliche Prüfung umgehen, die ihm der HMAC abverlangt.

Farben spielen eine wichtige Rolle beim Erkennen von Gefahrensituationen. Mozilla-basierte Browser haben daraus gelernt. Früher versteckten sie ein Vorhängeschloss in der Statuszeile des Fensters. Heute befindet sich dieses Symbol im URL-Eingabefeld – dieses Feld ändert die Hintergrundfarbe auf Gelb, wenn das Zertifikat verifiziert ist (Abbildung 10).

Abbildung 10: Neuere Firefox-Versionen zeigen direkt im URL-Feld, dass die Seite SSL-gesichert und das Zertifikat verifiziert ist. Zusätzlich zum Schloss-Symbol färbt sich der Hintergrund gelb.

Optische Hilfen

Die Hintergrundfarbe oder den Rahmen eines Objekts zu ändern, das der User gerade betrachtet, bewährt sich als überraschend effektives Kommunikationsmittel. Niemand muss sich merken, wo genau er hingucken muss, um die Sicherheitsinformation zu finden – sie ist unübersehbar. Der Farbwechsel verdeutlicht auch, dass etwas Ungewöhnliches vorgeht. In einer Usability-Studie verdoppelte sich die Zahl der User, die ein Sicherheitsproblem vermieden, durch den gezielten Einsatz von Farbe.

Farbe allein genügt jedoch nicht. Alle User müssten sich die Bedeutung der Farbcodes merken, Menschen mit Farbsehschwäche können manche Farben nicht unterscheiden und die Bedeutung von Farben wechselt je nach Kulturkreis. Rot heißt nicht in jedem Erdteil automatisch Gefahr.

Selbst wenn Rot für Gefahr steht, lässt das Interpretationsspielraum. In England startet ein grüner Knopf schwere Maschinen und ein roter stoppt sie. Die Franzosen halten es genau umgekehrt: Hier leitet ein roter Knopf die gefährliche Handlung ein – er startet die Maschine – und der grüne schaltet sie ab.

Etwa acht Prozent der Bevölkerung leiden unter Farbblindheit oder Farbschwäche. Am häufigsten ist dabei eine Rot-Grün-Schwäche. Das Interface muss folglich auch ohne Farbe funktionieren oder die Farben haben wenigstens konfigurierbar zu sein.

Lücken zeigen

Optische Hilfen können sogar auf das Fehlen von Sicherheit hinweisen, auch wenn es schwer ist, ausgerechnet das Nicht-Vorhandensein einer Eigenschaft hervorzuheben. Eingabefelder für Passwörter in Dialogboxen und Webseiten zeigen üblicherweise Sternchen statt der eingetippten Zeichen. Das erweckt den Eindruck, das Passwort bliebe geheim und sei irgendwie geschützt.

In Wahrheit verhindert es nur, dass der Sitznachbar zufällig einen Blick darauf erhascht. Wirkliche Angreifer hören die Daten auf dem Netzwerk ab, wo sie das Passwort oft genug unverschlüsselt vorfinden. Ironischerweise zeigen die meisten Webseiten eine eingetippte Kreditkartennummer im Klartext, übertragen sie aber geschützt per SSL.

Die logische Folgerung lautet, Passwörter im Klartext auf dem Bildschirm zu zeigen, wenn der Client sie auch im Klartext an der Server sendet (Abbildung 11). Das Programm sagt dem User damit unmissverständlich, dass es sein Passwort nicht schützt. Viele Anwender werden darauf nervös reagieren – genau dies will die Aktion erreichen. Wenn dem Anwender jemand über die Schulter blicken kann, ist es sowieso keine gute Idee, auf geheime, passwortgeschützte Daten zuzugreifen.

Abbildung 11: In diesem ungeschützten Login-Bildschirm erkennt der Benutzer sofort, dass sein Passwort im Klartext durch die Leitung wandert.

Um den Benutzer nicht völlig im Ungewissen zu lassen, empfiehlt sich ein Erklärungstext, zum Beispiel in Form eines Tooltipps. Diese Kombination warnt deutlich und gibt dem User das nötige Hintergrundwissen, um eine fundierte Entscheidung zu fällen.

Designbeispiel: TLS mit Passwort

Das Designbeispiel für visuelle Hinweise bezieht sich auf TLS-PSK, also auf TLS mit Passwort-Authentifizierung (Transport Layer Security with Pre-shared Keys, [7], [9]). Das Verfahren braucht mindestens folgende GUI-Funktionen:

• Eine Anzeige, dass TLS-PSK aktiv ist, also dass sich Client und
  Server erfolgreich gegenseitig authentifiziert haben.
• Eine nicht fälschbare Eingabemöglichkeit für das
  Benutzerpasswort. Verwechslung mit Passworteingabefeldern in
  Webseiten oder Ähnlichem muss ausgeschlossen sein.
• Eine nicht fälschbare Verbindung zwischen der
  TLS-PSK-Authentifizierung und der Webseite, die der Browser
  geschützt geladen hat.

Die erste Forderung erfüllt eine eigene Hintergrundfarbe in der URL-Zeile. Etliche Browser verwenden bereits Gelb für herkömmliches SSL/TLS. Für TLS-PSK kommt zum Beispiel Hellblau in Frage, um die Mechanismen zu unterscheiden. Für die anderen beiden Anforderungen genügt kein herkömmliches Popup-Fenster, das aus jeder Quelle stammen könnte. Besser ist: Die hellblaue URL-Zeile herauszoomen (animiert) und in einen blau gefärbten oder blau umrandeten Passwort-Eingabedialog verwandeln. Nach der erfolgreichen Authentifizierung zoomt das Feld wieder zurück.

Enge Verbindung

Dieser Ablauf verdeutlicht sogar Erstanwendern die direkte Verbindung zwischen dem hellblauen Hintergrund der URL-Zeile und der TLS-PSK-Sicherheit. Der Benutzer braucht sich nur noch eins zu merken: Wenn die blaue Farbe und der grafische Effekt fehlen, hör auf!

Zudem ist der Authentifizierungsmechanismus integraler Bestandteil eines notwendigen Ablaufs. Implementiert ihn der Browser so wie gerade beschrieben, dann funktioniert TLS-PSK nicht, ohne den User durch das Security-Interface zu leiten. Ganz anders der herkömmliche Sicherheitstest bei SSL/TLS, den der User beliebig umgehen kann.

Alle Finessen

Heutige GUIs beweisen an vielen Stellen großen Nachholbedarf, wenn es darum geht, ihren Anwendern zu helfen. In sicherheitsrelevanten Abläufen ist diese Hilfe besonders wichtig, weil den Benutzern meist das Hintergrundwissen fehlt. Ausgerechnet hier versagen viele Programme. Die Tipps aus dieser Serie verbessern die Situation: Oft genügt schon eine geschicktere Formulierung, aber auch ausgefeilte grafische Tricks an der richtigen Stelle tragen dazu bei, die theoretisch mögliche Sicherheit tatsächlich umzusetzen. (fjl)