Reccookies - cookiebasierter Phishingschutz für unwissende und unaufmerksame Nutzer

Version 1.4, 29.05.2005

Hauke Laging, phishing@hauke-laging.de

Inhalt


das Problem (zurück zur Übersicht)

Das wesentliche Problem, das Phising erst ermöglicht, ist der Umstand, dass wirksamer Schutz technisches Verständnis und Aufmerksamkeit auf Seiten des Nutzers erfordert. Der Nutzer muss wissen, was digitale Signaturen sind und wie er sie überprüfen kann/muss, und er muss so aufmerksam sein, dass er darauf achtet, dass dieser Schutz jederzeit gegeben ist. Dieser Schutz ist damit permament durch Vergesslichkeit und Unaufmerksamkeit bedroht, die per se nicht auszuschalten sind.

Die technische Seite von Webangeboten muss nicht mehr oder kaum noch verbessert werden, alles Nötige ist längst in vielfacher Form vorhanden. Nötig sind Fortschritte beim Verständnis der Anwender. Erstrebenswert sind technische Änderungen, die hier ansetzen und es dem Anwender erleichtern, nicht auf Phishingtricks hereinzufallen.

das Ziel (zurück zur Übersicht)

Als Ergänzung zu diesem derzeit einzigen, sicheren Schutz sollte - wenn möglich - ein Mechanismus etabliert werden, der optimalerweise (mindestens) allen folgenden Anforderungen genügt:

Relativ unabhängig von technischen Ansätzen sollte den Nutzern irgendwie vermittelt werden, wie sie sich im Problemfall zu verhalten haben. Dafür wäre es sicher förderlich, wenn es einen einheitlichen, weit verbreiteten Ansatz gäbe, so dass die - vielleicht gar nicht aktiv als solche betrachtete - Sicherheit zu einem Alltagseffekt würde, dessen Ausbleiben dann eben doch so auffiele, dass die meisten auch technisch unbedarften Nutzer stutzig werden.

der Lösungsansatz (zurück zur Übersicht)

Um den üblichen Reaktionen vorzugreifen: Der folgende Vorschlag will sich nicht mit technisch sicheren Verfahren in einer technischen Kategorie messen. Es geht ausschließlich um Usability, um einen Aufhänger durchaus innerhalb der Verständnisebene des durchschnittlichen Anwenders. Absoluten Schutz gewährt auch dieser Mechanismus nicht, der ist vor Dummheit wohl nie möglich. Auch quantifizieren kann ich die Wirkung ohne "Markttest" natürlich nicht, aber aus Ausgleich für diese ganzen Einschränkungen ist der Vorschlag trivial umsetzbar.

Die aufgeworfenen Probleme lassen sich nur lösen, wenn der Nutzer ohne weiteres Zutun beim Aufrufen einer Webseite sieht, dass es sich (im Rahmen der ohne Kryptografie möglichen Sicherheit) um die Seite handelt, die er erwartet. Eine Möglichkeit, dies zu realisieren, liegt in geeigneten Maßnahmen der Webseitenbetreiber. Dem Nutzer soll vor der (vollständigen) Eingabe seiner Zugangsdaten etwas angezeigt werden, das den Webseitenbetreiber authentifiziert, weil nur er und der Nutzer davon wissen, also eine Art Passwort. Wenn dem Nutzer das Passwort nicht angezeigt wird, weiß er, dass irgendwas im Argen liegt. Dann muss er "nur noch" ausreichend konditioniert worden sein, um dann auch entsprechend zu reagieren. An dieser Stelle scheiden sich nun die Geister: Der große Vorteil meiner Lösung gegenüber den SSL-Alternativen ("Er kann doch auch nachsehen, ob...") ist, dass nur bei mir die Wahrnehmung des Mechanismus zur Alltagshandlung gehört. Ob jemand den Sicherheitsstatus seines Browsers überprüft, ist völlig egal, er kann sein Onlinebanking auch nutzen, ohne das jemals angesehen zu haben. Entscheidend ist, dass eine Änderung dieses Status typischerweise nicht auffällt.

Ohne psychologische Kenntnisse kann man zumindest optimistisch vermuten, dass ein mit dem Passwort versehener Hinweis, wie im Fehlerfall zu verfahren ist, durch seine Häufigkeit den nötigen Eindruck hinterlassen sollte. Die Herausforderung liegt hier beim Nutzer, nicht auf wohlklingende Ausreden, die ein Angreifer wohl statt des Passworts anzeigte, hereinzufallen. Ausschließen lässt sich dies natürlich nie.

sicherer Transport der Daten

Entscheidend ist nun die Frage, wo dieses Passort herkommen, also gespeichert werden soll. Die naheliegende Lösung wäre: auf dem Server. Das scheitert daran, dass der Nutzer sich gegenüber dem Server authentifizieren, also seine Zugangsdaten eingeben müsste, denn dieses Passwort dürfte niemandem außer dem legitimen Nutzer angezeigt werden, denn anderenfalls könnte ein Phisher sich dieses Passworts bemächtigen und es auf seiner manipulierten Seite anzeigen.

Es macht Sinn, einen Phishing-Versuch als Man-in-the-middle-Attacke ("zweiten Grades", wenn man so will) zu betrachten. Eine Information muss - ohne Einsatz von Kryptografie (weil die nicht mehr trivial wäre) - sicher von A nach B, ohne dass der Angreifer trotz seiner komfortablen Position an die Daten herankommt. Möglich ist dies, weil es sich beim Phising nicht um eine Man-in-the-middle-Attacke auf IP-, sondern eine auf Applikationsprotokollebene handelt: Der Phisingserver arbeitet nicht als Sniffer/Router, sondern als Proxy.

Cookies als sicherer Transportweg

Da der Nutzer sich über die Integrität des Ziels (auf DNS-Ebene) leicht täuschen lässt, ist ein Mechanismus erforderlich, für den das nicht gilt. Ein wirksamer Ansatz zur Phishing-Abwehr könnte darin liegen, den Nutzer ein Passwort eingeben zu lassen (das nicht im üblichen Passwortsinn "sicher" sein müsste, der Name des Hundes wäre durchaus ausreichend) und dies in einem Cookie zu speichern. Der Server würde das Vorhandensein eines entsprechenden Cookies abfragen und ggf. dessen Inhalt - das "Passwort" - anzeigen. Der Browser würde so auf einfache, aber wirksame Weise prüfen, ob der Rechner am anderen Ende der ist, der es sein sollte. Da diese Cookies der Wiedererkennung des Server(name)s dienen, nenne ich sie Reccookies (für recognition cookies). Dass der Nutzer den Inhalt des Reccookies selber festlegen kann, ist wichtig, weil er mit dieser Technik womöglich auf vielen Webseiten konfrontiert wird und sich nicht jedesmal ein "richtiges" (also zufälliges) Passwort merken kann oder will.

Ist kein entsprechendes Cookie vorhanden, käme eine Meldung der Art "Sie haben kein Reccookie gesetzt oder Ihre Browserkonfiguration geändert, zum Beispiel den Browser gewechselt". Der Nutzer wüsste natürlich, ob er seinen Browser gewechselt hat. Was technische Manipulationen am eigenen Browser angeht, wären die typischen technikfremden Nutzer weniger sicher, aber immerhin misstrauischer als heute.

Die Handlungssicherheit des Nutzers könnte dadurch erhöht werden, dass alle Nutzer dieses Systems beim Anlegen der Cookies dem Nutzer eine Webseite zum Abspeichern anbieten, in der steht, was er zu tun hat, wenn ihm etwas komisch vorkommt. Darin könnten neben Erklärungen, die eben nur im Bedarfsfall gelesen (bzw. lange davor vergessen) werden, auch URLs zur Überprüfung sowie für geeignete Ansprechpartner (E-Mail) enthalten sein. Da alle dies machen sollten, wäre damit zu rechnen, dass viele Nutzer die entsprechenden Seiten der einzelnen Anbieter zentral speichern, so dass sie sie im Bedarfsfall auch wiederfänden.

Im Gedächtnis der Nutzer wäre die Botschaft zu verankern "Folge den früher abgespeicherten Anweisungen oder frage jemanden, der sich besser mit Internet auskennt, wenn Dir etwas komisch vorkommt!".

die Wirksamkeit von Reccookies und ihre Grenzen (zurück zur Übersicht)

technische Voraussetzungen

Trivialerweise muss ein Nutzer, der von Reccookies profitieren will, einen Browser nutzen, der Cookies unterstützt (also erlaubt, nicht löscht usw.). Außerdem muss der Browser, der von einer Phishing-Attacke betroffen ist, derjenige sein, mit dem der Nutzer ansonsten auf die fragliche Seite zugreift (oder schon einmal zugegriffen hat). Es spricht nichts dagegen, Reccookies in mehreren Browsern zu speichern.

Reccookies können natürlich nicht funktionieren, wenn man von Unterwegs - etwa im Internetcafe - seine E-Mail liest und dann den dortigen Browser benutzt. Dies betrifft aber ebenfalls nur einen sehr kleinen Teil der Fälle und eher nicht die technisch unbedarften Nutzer. Außerdem könnte man - mit den Phishing-typischen Erfolgsaussichten - mit den grundlegenden Verhaltensregeln kommunizieren, dass die Nutzer besonders misstrauisch und vorsichtig sein sollen, wenn sie nicht am heimischen Rechner sind.

DNS-Manipulationen

Gegen DNS-Manipulationen helfen Reccookies natürlich nicht. Aber diese stellen nur einen sehr kleinen Teil der Phishing-Angriffe dar. Außerdem stellen Angriffe, die auf Rechnermanipulationen aufsetzen (z.B. hosts-Datei), sowieso eine kaum auszuschaltende Gefahr für lokale Maßnahmen dar.

Load balancing

Wenn ein Anbieter DNS-intransparentes load balancing betreibt (Weiterleitungen an www1., www2., www3.domain.tld), hätte er zu beachten, dass er das Cookie für die ganze Domain domain.tld freigibt. Da dies aber mit vielen Browsern nicht funktioniert, sollte das Load-Balancing entweder nach der (relativ statischen und daher in bezug auf Serverrechenleistung wenig anspruchsvollen) Loginseite erfolgen, oder aber die Loginseite müsste von allen Rechnern vom selben Host importiert werden. Dabei muss man sicherstellen, dass nicht nur die Authentifizierungszeichenkette importiert wird, sondern "so viel", dass sich der Importmechanismus nicht von einem Phisher missbrauchen lässt, indem er ihn in seine eigene Seite einbaut. Völlig tabu sind (nicht nur aus diesem Grund) Pop-up-Fenster zur Darstellung der Zeichenkette.

Pop-ups

Ein Phisher könnte versuchen, das Reccookie von der Originalseite der Pop-up-Fenster einzublenden, indem er Rand und Scrollbalken ausblendet und dafür sorgt, dass das Pop-up-Fenster immer oben bleibt. Der Anwender sähe dann sein Reccookie, obwohl der Phisher es auf seiner eigenen Seite gar nicht anzeigen kann.

Eine wirksame Gegenmaßnahme wäre, die Lage des Cookies zufällig zu verändern (siehe Demo). Durch Änderung der Lage, des Hintergrundmusters und/oder der Hintergrundfarbe wäre es einem Phisher nicht mehr möglich, das Reccookie so einzublenden, dass nicht sofort auffällt, dass da Böses im Gang ist.

Proxies und Firewalls

Es gibt Installationen von Proxies und Firewalls (und womöglich auch megaprofessioneller "Sicherheitssoftware"), die die Benutzung von Cookies verhindern. Daran lässt sich von außen natürlich nichts machen, aber:

Sicherheitslöcher in Browsern, E-Mail-Clients und Webapplikationen

Cross Site Scripting (XSS)

Es gab/gibt verschiedene Sicherheitslöcher, die auch Cookies betreffen. Reccookies bieten natürlich keinen Schutz, wenn der Phishing-Server Cookies auslesen kann, die nicht für ihn bestimmt sind (Cross Site/Frame Scripting).

Als Gegenmaßnahme ohne Sicherheitsgewinn, aber zur Vermeidung trügerischer Sicherheit könnte ein Anbieter vor dem Setzen des Cookies testen, ob der Browser anfällig für XSS-Attacken ist und ggf. das Setzen des Cookies mit einem entsprechenden Hinweis ("Hier können Sie kostenlos einen richtigen Browser herunterladen") verweigern.

Sicherheitslöcher mit lokaler Dateizugriffsmöglichkeit

Auch die Möglichkeit, über die Ausführung von Code, der etwa in ausführbaren E-Mail-Anhängen oder in der E-Mail selber (Scriptsprachen in HTML) eingeschleust wird, über direkte Dateizugriffe an den Inhalt der Reccookies zu kommen, könnte den Ansatz aushebeln. Aber solche Probleme gehen weit über die Phishing-typische Gefährdung hinaus und sollten nur kurzzeitig bzw. bei einem kleinen Teil der Rechner (den ungepflegten) Wirkung entfalten.

Möglichkeiten zur Steigerung der Wirksamkeit

Die Wirksamkeit von Reccookies könnte gesteigert werden, indem regelmäßig - also vielleicht einmal im Quartal - die Reccookies serverseitig verworfen würden. Der Anwender bekäme dann den Hinweis, wie er sich nun zu verhalten hat: Webseite direkt per Adresse oder Bookmark aufrufen, Reccookie neu setzen.

Dadurch, dass dieses Verhalten dann quasi trainiert würde, dürften noch mehr Anwender im Phishingfall stutzig werden. Ganz anders als heute, da die Phisher eine ungewöhnliche Situation und damit Handlungsunsicherheit beim Anwender schaffen, lösten sie in diesem Fall eine Standardsituation aus und wären darauf angewiesen, dass der Anwender sich ungewöhnlich verhält.

sonstige Schwierigkeiten (zurück zur Übersicht)

Verfallsdatum von Cookies

Cookies haben eine begrenzte Lebensdauer, so dass es passieren kann, dass dem Nutzer angezeigt wird, dass sein Browser keine Authentifizierungskennung sendet, obwohl der Nutzer nichts aktiv verändert hat, woraufhin der Nutzer dann misstrauisch wird. Dieses Problem lässt sich ganz überwiegend dadurch lösen, dass das Verfallsdatum weit in die Zukunft gelegt und bei jedem Login aktualisiert wird. So ist nur ein kleiner Teil der Nutzer von diesem Effekt betroffen, nämlich die, die sich fast nie einloggen. Diese Nutzer dürften in der Tendenz aber auch die sein, die ihre E-Mail – und damit auch die Phishing-Mails – erst lesen, wenn alles vorbei ist, so dass diese Leute lediglich irritiert, aber auch bei Missachtung der potentiell kritischen Situation im allgemeinen eher wenig bedroht sind.

Passwortverhalten der Nutzer

Da dieses Konzept Nutzer als Zielgruppe hat, die sich in der Tendenz ziemlich dumm anstellen, kann es nicht schaden, sicherzustellen, dass der Nutzer als Cookie nicht sein reguläres Passwort (oder etwas sehr Ähnliches) verwendet. Dies wäre zwar keine Bedrohung der Wirksamkeit des Reccookies, aber es muss ja nicht sein, dass Passwörter in der Cookiedatei des Browsers landen...

"Sicherheitssoftware"

Es gibt sogenannte Sicherheitssoftware, die Cookies regelmäßig löscht. Dagegen kann man nichts machen, man kann den Nutzer nur davor warnen, so etwas zu benutzen. Insbesondere sollte ein entsprechender Hinweis in die Hilfedatei.

negative Auswirkungen auf die Nutzung verlässlicher Sicherheitsmechanismen

Ein eher theoretisches Risiko ist, dass manche Nutzer den Reccookies mehr Sicherheit zutrauen, als sie bieten, und daher verlässlichen Methoden weniger Beachtung schenken.

Gedächtnisprobleme

Der Nutzer muss sich plötzlich mehr merken als zuvor. Dieses Problem wird aber nahezu eliminiert, wenn er den Inhalt der Reccookies selber festlegen kann, so dass er auf allen Seiten dieselbe Kennung hätte. Dies eröffnet ein weiteres eher theoretisches Problem: Ein Angreifer müsste (in der einfachen Variante) "nur noch" den Inhalt eines beliebigen Reccookies in Erfahrung bringen. Allerdings erlaubt das alleine noch keinen Rückschluss auf die Identität des Nutzers, so dass damit vergleichsweise wenig anzufangen wäre.

Aufwands-Nutzen-Abschätzung (zurück zur Übersicht)

Supportaufwand

Neben dem Sicherheitsgewinn muss wirtschaftliche Praktikabilität gegeben sein. Diese könnte beeinträchtigt werden, wenn durch unerwartete Effekte viele falsche Alarme ausgelöst werden, die dann zu Supportanfragen führen. Dies könnte passieren, wenn die Nutzer häufig ihre Cookies kaputt machen, ohne das zu wissen oder zu ahnen. Diese Befürchtung drängt sich aber nicht auf. Supportanfragen sollten dabei außerdem über die beim Anlegen des Cookies gespeicherte Datei gehen, in der sinnvollerweise stünde, wie der Nutzer einen falschen Alarm erkennen kann, so dass er auf die Supportanfrage hoffentlich verzichtet.

Dadurch wird relevant, dass der User die fragliche Datei auch wirklich abgespeichert hat. Dies ließe sich "sicherstellen", indem die lokale Datei in einem (I)Frame angezeigt wird. Man könnte etwa den oberen Rand der fraglichen Datei grün färben, den obersten Teil einblenden und dazuschreiben: "Wenn Sie hier kein grünes Feld (sondern etwa eine Fehlermeldung) sehen, klicken Sie bitte hier." Das würde voraussetzen, dass der lokale Pfad entweder in einem weiteren Cookie oder sogar im Datensatz des Benutzers gespeichert wird. Das größere Problem dürfte darin liegen, den Nutzer hinreichend komfortabel diesen Pfad an den Server übermitteln zu lassen. Der vermutliche Aufwand legt es nahe, diese Information dauerhaft, also auf dem Server, zu speichern. Cookies hätten den Vorteil, dass das Verfahren auch auf mehreren Rechnern (mit unterschiedlichen Pfaden zu der Datei) funktionierte. Dies klingt arg aufwendig, wäre aber rein optional und der individuellen Nutzenbewertung des Anbieters (v.a. seiner Supportabteilung) überlassen.

Implementierung

Der technische Aufwand ist im einfachsten Fall sehr überschaubar. Eine Webseite wird um die Darstellung des Reccookie-Inhalts auf der Loginseite bzw. die entsprechende Meldung bei Fehlen sowie sie Möglichkeit, dieses Cookie zu setzen und die Anleitung für den Fehlerfall herunterzuladen, erweitert. Dies erfordert keinerlei Änderung an z.B. bestehenden Datenbanken. Mit allen Browsern sollte es sowieso funktionieren.

Mit den sinnvollen Erweiterungen steigt natürlich auch der Impelemtierungsaufwand, aber in erster Linie der einmalige und auch der in sehr überschaubarem Maß.

Gesamtaufwand

Aufwand fällt an folgenden Stellen an:

Webdesign
geringer und einmaliger Aufwand
Supportabteilung
dauerhaft, Umfang schwer abschätzbar, aber beeinflussbar

Kein Aufwand fällt im Bereich der Hardwareausstattung an. Reccookies erhöhen die Anforderungen an die Server nicht merklich.

Gesamtnutzen

Nutzen ergibt sich an folgenden Stellen:

Supportabteilung
Die "echten" Phishing-Anfragen fallen (überwiegend) weg
Image/Marketing
Der Anbieter ist das Phishing-Problem quasi los und kann diese zusätzliche Sicherheit als Kundennutzen vermarkten. Vor allem kommt er nicht mehr (oder weniger) durch Phishing-Mails in die Schlagzeilen.

Fazit (zurück zur Übersicht)

Reccookies sind alltagstauglich, ohne technische Hürden von quasi jedermann nutzbar, leicht zu implementieren, nicht durch Unaufmerksamkeit "auszutricksen" und daher eine für Anbieter wie Nutzer gleichermaßen attraktive Lösung. Die genannten Einschränkungen der Sicherheit reduzieren den Opferkreis immer noch um Größenordnungen, so dass es sich einfach nicht mehr lohnt, Phishingversuche bei entsprechenden Seiten zu unternehmen.

Wenn eine kritische Masse an Anbietern Reccookies implementiert hätte, würden die anderen schnell nachziehen, da sich die verbliebenen Phishingversuche auf sie konzentrierten. Die hohe Verbreitung hätte wiederum ein besseres Verständnis auf Seiten der Nutzer zur Folge.