© Peter Gutmann

Kaum ein Anwender verschlüsselt seine E-Mail, Phishing funktioniert super und HTTPS-Seiten mit falschen Zertifikaten schrecken keinen. Viele Entwickler sehen nur die Anwender in der Verantwortung, dabei fehlt es an benutzbarer Software. Teil 1 der Usability-Serie untersucht die Hintergründe für diese Situation.

Wer Software entwickelt, muss von Beginn an deren Sicherheit einplanen. Sicherheitsexperten beklagen gern und zu Recht, dass Programmierer jegliche Security nachträglich in ihre Applikationen klopfen. Ironischerweise tappt die Sicherheits-Community in eine ähnliche Falle: Statt die Benutzbarkeit von Anfang an zu berücksichtigen, folgt Usability frühestens an zweiter Stelle hinter der technischen Sicherheit.

Das traurige Ergebnis: In den 90er Jahren entstanden Sicherheitsfunktionen, die niemand benötigte. Bei den heute grassierenden Viren, Würmern und Phishern wäre diese Sicherheit nötig, dummerweise kann sie niemand benutzen. Um das zu ändern, müssen die Entwickler Usability-Prinzipien von den ersten Design-Überlegungen bis in die Betaphase hinein ständig berücksichtigen.

Sicherheits-Usability unterscheidet sich von den gewöhnlichen Anforderungen an Benutzbarkeit einer Software. Eine Software funktioniert korrekt, wenn alle Dinge, die geschehen sollen, tatsächlich geschehen. Sicher ist ein Programm erst dann, wenn alles, was nicht passieren soll, wirklich nicht passiert. Sicherheitsentwickler interessieren sich für die zweite, die Marketingabteilung eher für die erste Anforderung.

Ein sicheres Gefühl

Während sich der Anwender sicher fühlen will und vom Programm nur erwartet, dass es seinen Vorstellungen von einem sicheren Ablauf entspricht, muss sich die Applikation in jeder Situation sicher verhalten und per Default Schaden vom Benutzer abwenden. Wie die passenden Sicherheitsfunktionen aussehen müssen, hängt zunächst von der Umgebung ab, in der sie arbeiten.

Die vergangenen zehn oder 15 Jahren haben viele Versuche mit Internetsicherheit gesehen, in jüngerer Zeit kamen sogar Usability-Tests dazu. Dabei hat sich herausgestellt, dass etliche gut gemeinte Mechanismen in der Praxis versagen.

Schlechte Erziehung

Eine ambitionierte, aber praktisch unwirksame Maßnahme ist das Schulen der Benutzer. Die User haben inzwischen recht viel über Sicherheit gelernt, leider das Falsche. Konditionierung wäre der treffendere Begriff: Wann immer jemand online geht, bombardiert ihn sein Rechner mit Fehlermeldungen, Warnungen und Popup-Fenstern. DNS-Fehler, vorübergehende Netzwerkausfälle, ASP-Warnungen eines Webservers, Javascript-Probleme, fehlende Plugins, unerreichbare Server, falsche oder abgelaufene Zertifikate, PHP-Fehlermeldungen beim Versuch, auf ein MySQL-Backend zuzugreifen, und vieles mehr.

Viele Meldungen warnen nicht einmal vor echten Fehlern, sondern scheinen absichtlich den Benutzer zu ärgern. Unklar ist zum Beispiel, wovor Abbildung 1c warnen will: Der Anwender nutzt seinen Webbrowser, also ist es offensichtlich, dass er Daten über das Internet sendet. Keine Textverarbeitung würde auf die Idee kommen, die Rechtschreibprüfung mit einer Warnmeldung einzuleiten. Konqueror und Firefox (Abbildung 1a und 1b) sind immerhin etwas deutlicher in der Problembeschreibung.

Abbildung 1a: Konqueror sagt immerhin deutlich, wo aus seiner Sicht das Problem liegt: Der Benutzer ist dabei, Daten unverschlüsselt zu versenden.

Abbildung 1b: Bei Mozilla Firefox arbeitet die Checkbox anders als bei IE und Konqueror: Der User muss explizit anwählen, dass er solche Warnung haben will.

Abbildung 1c: Ein Beispiel für hoffnungslos übertriebene Warnmeldungen. Der Anwender hat einen Knopf gedrückt, schon belästigt ihn sein Browser mit einem Hinweis, dass er genau dies getan hat.

Alle drei Warnungen enthalten aber keinen Hinweis darauf, welche Daten der Browser sendet. Sie erscheinen, egal ob der Benutzer sein Onlinebanking-Passwort mitteilt oder auf Ebay nach billigem Fischfutter angelt. Diese und viele ähnlich sinnlose Popup-Warnungen konditionieren den Benutzer geradezu Warnmeldungen zu ignorieren. Praktischerweise hat der Internet Explorer per Default sogar die Option »Diese Meldung nicht mehr zeigen« ausgewählt. Offenbar war den Entwicklern sehr wohl bewusst, dass die Anwender solche Warnungen nicht haben wollen. Die User lernen aus den häufigen Meldungen Folgendes: Jedes Problem verschwindet, wenn sie »OK« oder »Cancel« klicken oder es später erneut versuchen.

Wichtige Warnungen

Jeder Browser bemerkt typische Angriffe auf SSL-geschützte Verbindungen, wenn sich der Webserver nicht korrekt mit einem vertrauenswürdigen Zertifikat ausweist. Also warnt er den Benutzer. Diese Warnung unterscheidet sich aber aus Sicht des Users nicht von der Flut nutzloser Hinweise, die er in der Vergangenheit so erfolgreich ignoriert hat. Zu allem Überfluss sind die meisten Zertifikatswarnungen noch False Positives – sie reagieren auf keinen Angriff, sondern sind auf Fehler des Servers zurückzuführen. Kein Wunder, dass Benutzer SSL-Warnungen ignorieren.

Wie weit die unheilvolle Konditionierung geht, bewies kürzlich eine Bank, die versehentlich ein falsches Zertifikat auf ihrem Onlinebanking-Server installierte. Von 300 Usern, die in der Zeit den Dienst aufriefen, brach nur ein einziger die Verbindung ab. Datenschutzbedenken verhinderten leider, die Reaktionen der anderen User genauer zu untersuchen. Eine informelle Befragung deutete aber darauf hin, dass die Benutzer die Zertifikatswarnung für eines der üblichen vorübergehenden Probleme hielten, dem sie wie gewohnt auswichen.

Psychologen bezeichnen diese Herangehensweise als Urteilsheuristik: eine Faustregel, die auch unter großer Unsicherheit schnelle und ökonomische Urteile ermöglicht. Sprich: Statt neu über ein Problem nachzudenken bleibt der Anwender bei einer Entscheidung, die in der Vergangenheit ausreichend erfolgreich war, selbst wenn er damit gelegentlich falsch liegt. Einer der Bankkunden beschrieb es recht treffend: “Hotmail macht das auch häufig, ich warte dann kurz und es funktioniert wieder.”

Ein ähnlicher Fall betraf eine staatliche Webseite in Neuseeland, über die Bürger viele tausend Dollar Vermögenssteuer abführen. Die Benutzer ignorierten das große rote Kreuz über der Grafik des Thawte-Zertifikats (Abbildung 2) und den Hinweis, dass das Zertifikat ungültig ist. Es dauerte zwei Monate, bis ein Sicherheitsexperte auf die Seite stieß und die Admins auf ihren Fehler hinwies (das Zertifikat war abgelaufen). In einem weiteren Fall verwendete eine größere US-Genossenschaftsbank ein ungültiges Zertifikat. Hier dauerte es über ein Jahr, bis jemand davon Notiz nahm.

Abbildung 2: Diese Zertifikatswarnung hielt Benutzer nicht davon ab, tausende Dollar an Steuerschulden mit ihrer Kredikartennummer zu begleichen.

Es genügte einer weiteren US-Bank sogar, ganz auf Zertifikate zu verzichten und stattdessen einfach auf die Webseite zu schreiben, dass alles in Ordnung sei – die Kunden hat selbst das nicht gestört. Mediziner kennen das als Placebo-Effekt. Diese Beispiele weisen deutlich darauf hin: Zertifikate verlieren im Umfeld vieler False-Positive-Warnungen ihre Schutzfunktion gegen Man-in-the-Middle-Angriffe. Sie sind in der Praxis daher fast unwirksam.

Eine unerwünschte Benutzer-Konditionierung ist nachträglich kaum zu korrigieren. Psychologen haben in zahlreichen Studien bestätigt, dass Menschen ein einmal angenommenes falsches Verhaltensmuster sogar dann beibehalten, wenn ihm eindeutige und überwältigende Beweise widersprechen [1].

Es kommt noch schlimmer

Es hat ganze zehn Jahre nach der Einführung von SSL gedauert, bis Mitte 2005 endlich eine ernst zu nehmende Studie die Wirksamkeit von Zertifikaten untersuchte [2]. Die Zielgruppe waren Informatikstudenten im Hauptstudium. Selbst diese weit überdurchschnittlich Computer-erfahrenen Anwender ließen sich von ungültigen Zertifikaten nicht aus der Ruhe bringen.

Zusätzlich zeigt sich ein überraschender Effekt: Dieselben User, die jedes ungültige Zertifikat fröhlich akzeptierten, weigerten sich ihre Daten an eine Seite zu übermitteln, die ganz ohne SSL arbeitet. Sie knüpften ihr Sicherheitsgefühl an das bloße Vorhandensein eines Zertifikats. Ironischerweise verhielten sich die Anwender sicherer, wenn die Seite nicht SSL-geschützt war. Damit erweist sich SSL sogar schlimmer als ein Placebo: Es verleitet User dazu, gedankenlos Daten zu übermitteln. Ein mit solchen Eigenschaften ausgestattetes Medikament wäre längst verboten.

Phisher nutzen heutzutage die Urteilsheuristik gezielt für ihr so genanntes Secure Phishing aus. Sie stellen einen SSL-geschützten Webserver bereit, dem die User ahnungslos alle Bankdaten anvertrauen, nur weil der Server irgendein Zertifikat verwendet.

Ganz ohne Zusammenhang

Implizit und ohne den User zu informieren vertrauen Browser vielen CAs und folglich einer gewaltigen Menge an Zertifikaten. Der User kommt mit dem Begriff der Zertifikate daher erst in Kontakt, wenn ihm sein Webclient eine Warnung präsentiert. Er weiß damit dann nichts anzufangen – ihm fehlt der Kontext.

Bei einer Umfrage stellte sich heraus, dass die meisten Anwender ein SSL- Zertifikat gleichsetzen mit einer Plakette an der Tür eines Geschäfts (etwa “Mitglied der Metzgerinnung”) oder dass es nichts weiter besagt, als dass sein Besitzer dafür gezahlt hat (Letzteres ist oft näher an der Realität als es sein dürfte). Die Folgen dieser fatalen Assoziation: Benutzer halten wenig von vertrauenswürdigen (trusted) Zertifikaten und kümmern sich daher auch nicht um ungültige, falsche oder abgelaufene Exemplare.

Vermutlich wäre die beste Lösung für sichere Netzwerkverbindungen der Einsatz der passwortbasierten Authentifizierung von TLS (siehe Kasten “Theoretische und tatsächliche Sicherheit”). Es verwendet automatisch eine gegenseitige Authentifizierung, die ohne Zertifikate auskommt. False Positives kommen nicht vor: Entweder der Handshake klappt und beide Seiten haben sich vollständig authentifiziert oder die Sitzung schlägt fehl – ohne Ausweg über kontraproduktive Warndialoge.

Die meisten Anwender gehen den Weg des geringsten Widerstands, selbst wenn sie wissen, dass das wenig sicher ist. Sicherheit ist kaum das Wichtigste für einen Benutzer; wenn sie stört, umgeht er sie [3]. Studenten des Dartmouth College in den USA bevorzugten weiterhin Passwörter, obwohl ihnen die Uni kostenlos wesentlich sicherere USB-Tokens bereitstellte. Passwörter empfanden die Studenten als praktischer.

User mögen es nicht, wenn ihnen jemand ein bestimmtes Interface vorschreibt. Eine Gartner-Untersuchung [4] kam zum Ergebnis, dass Benutzer, obwohl sie sich vorgeblich mehr Sicherheit wünschen, im Ernstfall lieber bei ihren gewohnten Passwörtern blieben statt sichere Chipkarten und RSA-Keys zu verwenden [5].

So gut wie niemand beachtet ein Feature eines Sicherheits-GUI, wenn es nicht integraler Bestandteil der entscheidenden Abläufe ist. Kaum jemand klickt zum Beispiel auf einen Button, um das Zertifikat einer Webseite zu prüfen. Dieser Schritt ist nicht unbedingt nötig, um die Webseite zu besuchen. Selbst wenn beim Erledigen der Aufgabe A die Dialogbox B dazwischenfunkt, nimmt sich niemand die Zeit, deren Inhalt zu studieren, er sucht nur nach dem schnellsten Weg, um Tätigkeit A zu erledigen (siehe auch Kasten “Simon sagt”).

Lästige Lizenzen

Deutlich zeigt sich das Verhalten bei EULAs (End User License Agreement). Sie stören nur bei der Software-Installation. Selbst als Usability-Forscher mit enormem Aufwand die Lesbarkeit verbesserten, nahm keiner von EULAs Notiz [6]. Spyware- und Dialer-Entwickler nutzen das schamlos aus und behaupten, dass sie ihren Müll mit dem Einverständnis des Users auf seinen Rechner laden.

Copyright-Hinweise in Videos und DVDs verpuffen ähnlich wirkungslos. Die User spulen das Video einfach vor. Dass Filmstudios die Hersteller von DVD-Playern zwingen, das Vorspulen beim Copyright-Vermerk zu verhindern, hilft ihnen auch nichts: Niemand liest diese Texte, aber jeder ärgert sich. Das geht so weit, dass in der genannten EULA-Studie viele Benutzer sogar angaben: “Egal was ihr macht, letzten Endes ignoriere ich es doch und installiere die Spyware.”

Auch Microsoft stieß auf das Problem bei den automatischen Windows-Sicherheitsupdates. Da nur wenige Windows selbst updaten, prüft das System, ob neue Patches vorliegen. Statt stumm im Hintergrund Software zu aktualisieren informiert Windows den User, was demnächst passiert. Überraschend für die Redmonder: Ein erheblicher Teil der User klickte in alter Gewohnheit auf »Cancel« oder auf den Schließen-Knopf des Popup-Dialogs, um das lästige Fenster loszuwerden [7]. Viele User hielten den Dialog gar für eine weitere Spyware- oder sogar Spam-Meldung.

Viele psychologische Studien haben diesen Effekt untersucht: Bei externen Stimuli wie Stress oder dem Wunsch, eine Aufgabe zu erledigen, konzentrieren sich die Probanden auf die geringstmögliche Anzahl an Hinweisen, die ihnen zu einer schnellen Entscheidung verhelfen ([8], [9], [10], [11]). Das Verhalten ist demnach ein Teil der menschlichen Natur, den niemand als Faulheit abtun oder darauf hoffen darf, dass er es ändern könnte. Das menschliche Verhalten ist eine Tatsache, mit der Software-Entwickler und GUI-Designer leben müssen.

Schließen verboten

Eine kleine Hilfe könnte sein, den Fenster-Schließen-Button von Dialogboxen zu entfernen. Das unterbindet immerhin eine der eintrainierten Verhaltensweisen. Auch sollten wichtige Sicherheitswarnungen als modale Dialogbox ausgeführt sein: Das zwingt die User sich um das Fenster zu kümmern. In den 90er Jahren galten modale Dialoge als böse. Entwickler trieben enormen Aufwand mit ihren nicht-modalen. Die Folge: Beim Anwender stapeln sich die ignorierten Fenster, während er munter in unsicherer Weise weiterwerkelt.

Einen besseren Ansatz nutzt Apple in seinem Mac OS X: Es startet eine voll ausgestattete Anwendung (für Software-Updates) in der Hoffnung, dass User das eher respektieren. Apple unterscheidet auch Sicherheitsupdates von normalen Aktualisierungen, sodass User nur die wirklich wichtigen Korrekturen einspielen und das System ansonsten unangetastet lassen können.

Suse versucht sich an einer Kombination: Der Suse-Watcher informiert in der Standardeinstellung unaufdringlich mit einem Warntext, falls Updates vorliegen (Abbildung 3a). Nach einem Klick auf den Text verschwindet er – ohne weitere Folge. Ein Klick auf das rot gewordene Watcher-Symbol (es kennt auch als Zustände gelb und grün) öffnet zunächst eine etwas wirre Kombination aus Infos, Einstellungen und Knöpfen für weitere Aktionen (Abbildung 3b). Erst wer hier auf »Starte Online-Update« klickt, kommt in den Genuss des Update-Programms. Zwischendrin muss der User aber noch sein Root-Passwort eingeben und einen Mirror-Server auswählen.

Abbildung 3a: Suses Watcher informiert zu unauffällig über neue Updates. Nach einem Klick auf den Text verschwindet er und stört nicht weiter.

Abbildung 3b: Ein Klick auf das Watcher-Symbol öffnet ein wilde Kombination aus Info-, Konfigurations- und Aktions-Fenster statt direkt zur Updatefunktion zu gehen.

Immerhin unterscheidet auch Suse deutlich zwischen Sicherheitspatches und normalen Updates. Soll sich das System aber mehr an Normalanwender und weniger an versierte Sicherheitsexperten wenden, dann müssten diese Aktualisierungen leichter erreichbar und weniger leicht ignorierbar sein.

Motivationsschwäche

Fehler beim Motivieren der Benutzer, sich um Sicherheit zu kümmern, passieren auch auf Serverseite. Manche Banken binden die Login-Felder für ihr Onlinebanking immer noch in ungeschützte Startseiten ein – sei es, um den Zugang leichter auffindbar zu machen, oder doch eher, um Werbung einzublenden, ohne die Geschwindigkeit der Seite durch SSL zu bremsen.

Noch erschreckender: Manche Bank trainiert ihre User regelrecht zum künftigen Phishing-Opfer. So die Bank of America und American Express (Abbildungen 4a und 4b): Beide versichern, dass die Daten nach der Eingabe in eine unsichere Seite per SSL übermittelt werden. Der User soll blind den Angaben in der unsicher übertragenen Seite vertrauen.

Abbildung 4a: Dieses Finanzinstitut setzt den Zugang zum Onlinebanking in eine unsicher übertragene Seite und überredet die User dennoch, ihre Daten einzutragen. Genau solches Verhalten wünschen sich alle Phisher.

Abbildung 4b: Die Überredungsversuche von Abbildung 4a sind kein Einzelfall. Auch dieses Kreditinstitut konditioniert seine User dazu, ihre Daten in eine unsichere Seite einzutragen.

Besonders deprimierend ist, dass beide Beispiele keine Ausnahmen darstellen. Offenbar sind es nicht nur Anwender, die das zertifikatbasierte Sicherheitsmodell von SSL falsch oder gar nicht verstehen, sondern auch große Finanzinstitute. Wer Sicherheitsmechanismen plant, muss neben Unverständnis auch mit widerstrebenden wirtschaftlichen und politischen Interessen rechnen. Oft helfen dann nur Lösungen auf der gleichen (wirtschaftlichen und politischen) Ebene.

Lehren zwecklos

Völlig zwecklos ist es, Probleme mit den Sicherheitsfunktionen eines User-Interface per Benutzeraufklärung lösen zu wollen. Computersicherheit ist schlicht zu komplex und die Motivation der Anwender, alle Feinheiten zu lernen, ist viel zu gering. Keiner will Anleitungen lesen, auch wenn sie ihm in Form von Popup-Dialogfenstern begegnen. Angreifer sind gut darin, die Komplexität und das fehlende Verständnis der User für ihre Zwecke auszunutzen.

Als warnendes Beispiel mag die Folge des I-Love-You-Wurms dienen: Erst nach vielen Jahren hatten es die meisten Benutzer mühsam gelernt, niemals auf Attachments von unbekannten Absendern zu klicken. Kein Problem für die Angreifer. Heute scheinen die Würmer von Freunden, Verwandten, Kollegen und Geschäftspartner zu stammen – die Adressen sind natürlich gefälscht. Niemand kann es sich leisten, alle Attachments dieser Absender zu ignorieren. Jahre der Benutzerschulung waren nutzlos.

Unsicherheit ins Format eingebaut

Viel besser wäre es, Software so zu entwickeln und die Anwender so zu trainieren, dass sie nur noch ungefährliche Dokumentenformate verschicken. Formate also, die sich passiv verhalten und auf dem Zielsystem keinen Schaden anrichten können.

Doch im Gegenteil tauchen überall Turing-Maschinen auf: In ihrer Jagd nach Erweiterbarkeit verwandeln Entwickler alles vom Office-Dokument über PDF bis zur URL einer Webseite in eine Programmiersprache. Leider sehen viele dieser gefährlichen Dokumententypen gar nicht aus wie eine Programmiersprache. Entsprechend schwer bis unmöglich ist es, deren aktive Funktionen zu deaktivieren oder überhaupt aufzuspüren.

Deutlich besser wäre der Least-Privileges-Ansatz: Der Viewer für dieses Programm sollte mit so wenig Rechten wie möglich laufen (Sandbox-Prinzip), um im Ernstfall möglichst wenig Schaden anzurichten. Diese und weitere grundlegende Sicherheitsmaßnahmen sind seit den 60er und 70er Jahren in der Informatik bekannt, finden aber immer noch viel zu wenig Beachtung.

Benutzerschulung funktioniert auch deshalb nicht, weil sie viel zu oft als Auffangbecken für alle Probleme herhalten muss, die der Entwickler in der Programmoberfläche nicht lösen kann oder will. Die perfide Logik: Wenn ein Problem zu kompliziert für eine einfache Lösung ist, dann erklären wir dies zur Aufgabe der Schulung. Es ist dann das Problem von jemand anderem!

Wenn ein Dialogfenster dem User dem Sinne nach die Frage stellt: Hier könnte vielleicht etwas Gefährliches passieren. Dennoch fortfahren? (siehe Abbildung 5), dann zeigt dies, dass der Applikationsentwickler schlichtweg aufgegeben hat. Alle Wirksamkeit der Sicherheitsmechanismen einer Software hängt nun am Urteil des Benutzers. Der wird zwar kopfüber in die erstbeste Sicherheitslücke fallen, es ist dann aber seine Schuld und nicht die des Entwicklers. Darauf hofft zumindest Letzterer.

Abbildung 5: Etwas auf die Spitze getrieben: So ähnlich wirken viele Dialogboxen, die den Benutzer fragen, ob er fortfahren will.

Angriffe auf das User-Interface

Angreifer sammeln zusehends Erfahrung darin, Schwächen von Benutzerschnittstellen auszunutzen. Sie testen ihre Techniken im großen Stil in der realen Welt. Klar, dass sie erfolgreiche Strategien weiterentwickeln und unwirksame aufgeben. Diese Evolution schreitet schneller voran als die vieler gewöhnlicher Software. Usability-Experten befürchten sogar, dass ihre Arbeit eher den Angreifern nutzt als den Anwendern: Weil Cracker besser verstehen, wo Usability-Probleme liegen, können sie normale User gezielter in die Irre führen.

In einer Welt, in der Spammer mit Linguisten zusammenarbeiten, um Spamfilter zu umgehen, und sich Phisher die Hilfe von Psychologen holen, um ihre Opfer erfolgreicher zu betrügen, ist es nur eine Frage der Zeit, bis Angreifer die Usability-Forschung unmittelbar für ihre Zwecke missbrauchen.

Gegenfrage

Ein recht einfacher Weg für den Entwickler, um potenzielle Problemfelder aufzuspüren, sind negative Pflichtenhefte. Sie beantworten die Frage, was das User-Interface dem Benutzer auf keinen Fall ermöglichen darf. Wenig sinnvoll ist es zum Beispiel, dass der Benutzer in vielen Browsern sämtliche Sicherheitsfeatures abschalten kann (Abbildung 6). Ein ganzer Schwarm an Viren und Würmer hat diese Funktion von Microsoft Office und Outlook prompt genutzt, um deren Sicherheitsfunktionen abzuschalten. Das ging so weit, dass Virenscanner die Malware am einfachsten an deren Code zum Abschalten der Schutzfunktionen erkannten.

Abbildung 6: Niemand würde ein Auto kaufen, bei dem der Fahrer auf Knopfdruck die Bremsen deaktivieren kann. In einem Browser scheint es dagegen nicht zu stören, wenn alle Sicherheitsfunktionen abschaltbar sind.

Nicht nur Malware missbraucht solche gefährlichen Fähigkeiten. Auch viele Handbücher und Webseiten empfehlen detailliert und Schritt für Schritt das Abschalten von Sicherheitsfunktionen, nur um schlecht programmierte Software zum Laufen zu bringen. Egal ob Windows-Features oder ein »xhost +« unter Linux, das den sowieso schwachen Schutz des X-Servers aushebelt: Es ist oft einfacher, die Sicherheitstests abzuschalten als die Software zu fixen.

Eine Negativliste zusätzlich zu den bekannten Designvorgaben für eine Benutzeroberfläche ist daher ein wichtiges Hilfsmittel. Das GUI sollte den User wirksam davon abhalten, sich selbst unnötig zu gefährden.

Weniger wäre mehr

Viele Sicherheits-GUIs sind außerdem zu umfangreich. Sie nerven den Anwender so lange mit unwichtigen Meldungen, bis er auch wichtige Hinweise ignoriert. Sie erlauben es dem Benutzer, selbst wichtige Sicherheitsvorkehrungen einfach zu umgehen (Verbindung mit SSL-Servern trotz eines ungültigen Zertifikats) oder sogar mit Hilfe überflüssiger Konfigurationsoptionen abzuschalten.

Gelegentlich verleiten ihn Dienste oder Anleitungen sogar gezielt, seine Sicherheit zu gefährden. Damit hebelt die Praxis den theoretisch durchaus sehr guten Schutz von zertifikatsbasiertem SSL aus. (fjl)