Inhalt:
.Akustische TANs: Ein Schritt zur Gleichberechtigung
Wolfgang Trexler, Bank Austria-Creditanstalt
Wolfgang Trexler: Mein Name ist Wolfgang Trexler, ich komme von der BankAustria Creditanstalt AG. Ich denke, es wird den meisten von Ihnen ein Begriff sein, die BankAustria Creditanstalt AG sieht das Web als Schnittstelle zum Kunden, wie die meisten Banken.
Wir möchten unseren Kunden über das Internet die Möglichkeit geben, online auf ihr Konto und ihre Veranlagungen und Bankprodukte zuzugreifen. Die BankAustria Creditanstalt AG, beziehungsweise ihre Vorgängerinstitute haben das Web bereits seit 1995 als Schnittstelle zum Kunden erkannt.
Begonnen hat das Ganze eigentlich schon Anfang der 90er-Jahre mit Dingen wie BTX, Telebanking mit Modem und ähnlichen Sachen. Wir haben derzeit eine Online-Banking-Applikation für Privatkunden, die von circa 510000 Kunden genutzt wird. Darüber hinaus haben wir auch noch für Firmenkunden Banking-Produkte, die derzeit von circa 60000 Firmenkunden, also Unternehmen genutzt werden.
Es ist also so, dass das Banking in den letzten Jahren ein bisschen gebeutelt wurde, was die Sicherheit betrifft, es ist Ihnen allen sicherlich das Thema Phishing geläufig. Es wurde hier versucht, von mehr oder weniger ahnungslosen Benutzern durch einen Trickbetrug Zugriff auf ihr Konto zu bekommen und an ihren Verfüger, PIN und TAN heranzukommen. Wir haben uns daher mit März 2006 entschlossen, dass wir das sogenannte iTAN-Verfahren einführen.
Das ist eine Erweiterung unseres bestehenden Authentifizierungsverfahrens. Im Juni 2007 haben wir dann noch einmal etwas draufgesetzt und haben also das mobileTAN-Verfahren herausgebracht.
Das ist ein Verfahren, bei dem wir dem Benutzer die Transaktionsdaten seiner Transaktion, die er jetzt unterschreiben möchte, sowie den TAN, den er braucht um das Ganze zu unterschreiben, direkt in Echtzeit, binnen ein, zwei Sekunden, auf das Mobiltelefon zustellen.
Die Sicherheit von Webapplikationen ist immer eine Gratwanderung. Es geht also um Sicherheit versus Usability oder Sicherheit versus Benutzerfreundlichkeit.
Aus meiner Sicht ist eine Anwendung dann am Sichersten, wenn kein Benutzer damit arbeiten kann. Abgesehen davon hat es auch noch den angenehmen Nebeneffekt, dass sie auch viel problemloser und runder läuft, viel rascher ist. Die Leute, die das von der Businessseite sehen, haben aber leider relativ wenig Verständnis dafür.
In der Praxis führen Sicherheitsüberlegungen fast immer zu Einschränkungen in der Benutzerfreundlichkeit. Das kann man sich so vorstellen, dass also zwei Mannschaften am Seil ziehen, das eine sind sozusagen die Marketiere, die versuchen das möglichst freundlich zu machen. Auf der anderen Seite sind das die Sicherheitsleute, die versuchen, das möglichst grauslich zu machen. Ganz so stimmt es natürlich nicht, die Bestrebung ist, es möglichst sicher zu machen und die Wahrheit liegt dann immer irgendwo in der Mitte.
Wir sind aber eigentlich, deswegen bedanke ich mich auch für den Vortrag, das schlechte Beispiel, ich zeige Ihnen nämlich, wie es nicht sein sollte.
Wir haben uns Mitte 2006 entschlossen, dass wir unsere Image-TANs, also die TAN-Nummer, die der Kunde eingibt - ich wollte nur fragen, gibt es jemanden im Publikum, dem dieses Verfüger-PIN-TAN-Verfahren gar nicht geläufig ist, dann würde ich das kurz skizzieren, sonst der Zeit wegen eher nicht - als Image rauszurendern.
Wir fanden das aus Sicherheitssicht eine wahnsinnig gute Idee, wir machen ein großes Image, in dem der Benutzer alle Transaktionsdaten drinnen hat, auch gleich von mehreren Überweisungen und am Ende bringen wir noch einmal die Gesamtanzahl aller Transaktionen, die er jetzt unterschreiben möchte, sowie die TAN-Nummer, die er für genau diese Transaktionen braucht.
Dazu muss man auch noch wissen, dass in diesem Sicherheitskonzept auch beinhaltet ist, dass eine derartige TAN-Nummer nur für diese Transaktionen verwendet wird. Das heißt, wenn man abbricht wird ganz sicher eine andere verlangt und diese nie wieder.
Das war Teil eines Gesamtbündels und wir haben gesagt, da gibt es jetzt alle möglichen Sicherheitsbedrohungen und es wäre eigentlich eine gute Idee, den Text, also die Nummer vom TAN, die ich haben möchte, nicht mehr im Klartext über die Leitung zu schicken, sondern das noch einmal in ein Bild hineinzupacken, gemeinsam mit allen Transaktionsdaten, das würde die Sache um vieles sicherer machen.
Was wir, ehrlich gestanden, übersehen haben, oder einfach nicht bedacht haben, war, dass wir auf diese Art und Weise auch ganz wunderbar geschafft haben, unsere Kunden vom Banking auszuschließen. Das war natürlich nicht unsere Intention, den sehbehinderten Teil unserer Kunden von unserem Banking auszuschließen und denen eigentlich die sehr wichtige Selbstständigkeit im Banking zu nehmen.
Wir haben dann in Ab- und Rücksprache mit den entsprechenden Interessensvertretungen, die berechtigterweise auf uns zugekommen sind, eine für Sehbehinderte geeignetere Lösung gefunden. Ich sage jetzt absichtlich nicht optimale Lösung, weil es ist eine geeignetere Lösung, aber wie das halt so ist, Sicherheit versus Usability, es ist einfach auch nur ein Trade-Off sozusagen. Wir haben uns bemüht.
Ich möchte Ihnen das kurz skizzieren, wir haben ja auch nichts großartig Neues erfunden, sondern auf bestehende Konzepte zurückgegriffen. Wir haben also unsere CAPTCHAs anhörbar gemacht und darauf geachtet, dass wir dabei die Sicherheit nicht vernachlässigen.
Was wir also tun, Sie sehen im oberen Teil des Bildes, wie der untere Abschnitt so eines Zeichnungsvorganges aussieht. Da steht also nochmal die Gesamtsumme drinnen, wie ich vorher schon skizziert habe, die entsprechende iTAN-Nummer ist in diesem Fall die Nummer 42, die wir ganz gerne hätten. Also der Kunde muss auf seinem Zettel nachschauen, den TAN, der mit 42 beginnt, den muss er jetzt eingeben. Rechts davon ist ein kleines Ohrwaschel, mit TAN-Index. Das ist auch entsprechend mit einem Alternatetag und all diesen Dingen hinterlegt, dass man das auch mit einem - ich sag einmal - nicht-visuellen Browser möglichst gut findet.
Wenn der Kunde dort draufklickt, dann passiert im Hintergrund ein dynamischer Vorgang, das ist wieder Teil des Sicherheitskonzeptes, wir haben mehrere Sprecher die Zahlen von null bis neun sprechen lassen. Das wird dann dynamisch zur Laufzeit zusammengestöpselt, es wird per Zufall ein bestimmter Sprecher ausgewählt und es wird ein zeitlicher Abstand von Weiß-Rauschen, auch dynamisch per Zufall genau zu dem Zeitpunkt, wenn das Ganze generiert wird, hineingeflickt.
Wir packen die vier, eine zufällige Länge von Weiß-Rauschen plus die zwei zusammen und haben damit für jeden Zeichnungsvorgang wieder eine eindeutige Kombination, die ich mir aber anhören kann. Das Ganze wird dann in ein wav-File verpackt und das wav-File übergeben wir an den Browser.
Das machen wir nicht in Form irgendeines Plug-Ins, Java-Script oder sonstiger Zauberei, sondern wir übergeben hier einfach den entsprechenden MemTab und lassen dem Browser die Auswahl, wie er mit diesem wav-File umzugehen hat, an welches Tool er das dann schlussendlich für die Sprachausgabe weitergibt. Was wir damit geschafft haben ist, wir haben ohne unsere Sicherheitsidee zu vernachlässigen, ohne hier in der Sicherheit von unserem Konzept abzugehen, einen, glaube ich, ganz praktikablen und eleganten Weg gefunden, um dem Benutzer weiterhin das selbstständige Banking zu ermöglichen.
Auch wenn im ersten Ansatz unsere Variante, das Ganze mit einem CAPTCHA zu machen, das eigentlich das verhindert hätte. Wir haben hier eigentlich damit ein Audio-unterstütztes CAPTCHA geschaffen. Grundsätzliches ist es so, dass unsere Applikation nicht eine der behindertengerechtesten ist, die es gibt. Das Online-Banking gibt es jetzt doch schon seit einigen Jahren.
Es ist aber so, dass wir uns bemühen, auch in Zusammenarbeit mit den Interessensverbänden hier die nötigen Schritte und Adaptionen in kleinen Schritten und Adaptionen zu machen, um es "weiterhin zu verbessern".
Ich bedanke mich für die Aufmerksamkeit.
(Transkription: Christine Schubert, www.freak-online.at)