Online-Banking unter Linux

Ergänzend zum Artikel in der c't 7/2000 (Heise-Verlag) habe ich zusammengetragen, was das Internet-Banking zu bietet hat, wenn man kein Windows benutzt.

Tabellen

Der Artikel in der c't kam wie auf Bestellung. Zuvor hatte ich schon selbst versucht mir ein Bild zu machen: Die linke Hand am Telefonhörer zur Hotline und die rechte auf der Maus bei dresdenerbank.de. So fuehrte mich der freundliche Herr zur Eingangsseite, die von der Homepage nur versteckt erreichbar ist. Leider mussten wir die Tour vorzeitig abbrechen, weil der Server auch fuer den Testzugang überlastet war...

Mit Hilfe der Tabellen auf den Seiten 150-153 habe ich mir ein neues Bild gemacht und nach längerer Auswertung die netbank.de favorisiert. Online habe ich dann dort erst mal ein paar Sachen durchgelesen. Mit gutem Gefühl wollte ich mich bis zum Login wagen, um mich von der Funktionsfähigkeit des Applets zu überzeugen. Zuerst durfte man das unsignierte Applet 'auswählen', da das signierte 'zur Zeit nicht verfügbar' war. Ob die Gebühren bei VeriSign gestiegen sind oder einfach nur vergessen wurde eine frische Signatur zu holen, möchte ich lieber nicht wissen. Doch die endgültige Enttäuschung bekam nur durch den langen Ladevorgang Aufschub.

Windows-Java

Der Browser beschwert sich, dass das Applet eine Netzverbindung möchte. Das hätte mir eine Signatur erspart - ich bestätige. Doch hier hörte der Spaß auf: Auch nach Anklicken des Feldes 'Kontonu' kann ich dort nichts eintragen. Wenn die Eingaben nicht im Adressfeld des Browsers landen, darf man schon von Glück reden. Später habe ich festgestellt das mit Maus-Dauerfeuer auf das Feld mit gleichzeitiger Tastatureingabe doch Zeichen in das Feld gelangen. Leider hat man dadurch nach spätestens drei Zahlen alles markiert und überschrieben - eine Kontonummer will ich so nicht eingeben...

Natürlich wird bei 'Systemvoraussetzung' nicht von Linux geredet, aber warum verwendet die Netbank nicht gleich Windows-Software? Von systemunabhängigen Java-Programmen habe ich aber anderes erwartet!

So abgeschreckt habe ich erst mal die Tabelleneinträge 'Internet-Technik' in der c't genauer unter die Lupe genommen. Einen Tag später fing ich dann doch an, allen Banken auf den Zahn zu fühlen.

So wurde getestet:

Die vier Tabellen geben jeweils die sieben bzw. acht Banken einer Seite der c't wieder. Die Punkte-Berwertungen sind subjektiv. 'Wertung mit c't' spiegelt wieder, wie die Bank schon in der c't abgeschnitten hat. Ich habe dabei besonders bestraft, wenn die errechnete Jahresgebühr zusammen mit einer VISA-Karte deutlich über 100DM lag. - Dass die Bank grenzenlos einspart, während ich verblute, sehe ich nicht ein. Umgekehrt finde ich es aber akzeptabel wenn die Bank einen Weg gefunden hat Qualität anzubieten, ohne vom Ansturm aller Surfer totgetrampelt zu werden. Anschliessend habe ich auch noch auf 'Terminüberweisung', 'Verzinsung', die Depot-Konditionen, Gold-Karten und den Dispokredit geschielt.

Den 'Ersten Eindruck' habe ich online bekommen. Von der Eingangsseite bis zu den Infos über das Internet-Banking mit versuchtem Login. Ein Testkonto wurde auch besucht, sofern vorhanden. Transparenz war mir wichtig. Wenn man auch nach zehn Minuten noch nicht wusste, welche Leistungen nicht kostenlos sind, hatte schon mal schlechte Karten. Wenn man dann auch mit intensiver Zuhilfenahme des 'Back-Buttons' gar nicht auf den grünen Zweig kam, hatte seine Gunst verspielt. Andere Gehässigkeiten oder deprimierend schlechtes Webdesign brachten auch Minuspunkte.
Die Bewertung erhielt hier maximal ein Zeichen (Plus, leer, Minus).

Unter 'Banking-Technik' konnte man ein '++' erreichen, wenn nur SSL zum Einsatz kam oder man anderweitig von überragender Plattform- und Browserunabhängigkeit reden konnte. Wenn auch Java-Applets zum Einsatz kamen, war nur noch '+' möglich. Eigentlich war ich geneigt hier nicht abzuwerten, aber die einzige verfügbare Java-Virtual-Machine (Appletviewer) für Linux, die https unterstützt, ist der Netscape-Browser. Ich lasse mich hier gerne eines besseren belehren, aber selbst mit dem Sun-'JDK' in der Version 1.2.2-RC4 war der Appletviewer nicht zu https bereit. Wenn man sich nicht auf Betriebssysteme mit Netscape beschraenken möchte, kann man u. U. mit etwas Bastelarbeit nachhelfen, was ich mit der 1822direkt probiert habe.
Neutral fiel die Wertung bei allg. Windows-Orientierung der Bank aus. Ich erwarte jedenfalls nicht, dass kleine Macken behoben werden, wenn explizit Windows95/98 mit Netscape 4.03-4.5 'empfohlen' wird... Bei einem Minuspunkt ist der Zugang entweder nervig oder extrem umständlich; prinzipiell aber noch funktionsfähig unter Linux. Bei '--' gehts nicht.

Die Webserver-Software wurde nur informationshalber ermittelt. Jedoch war das der Teil im Test, bei dem mir wirklich die Haare zu Berge standen! Ein Drittel aller überprüften Sites antwortete nicht RFC-konform auf Simple-Requests oder brachte es hier nur zu völlig krankhaften (versuchten manuellen) Redirects. Besonders heldenhaft viel mir eine Präsenz auf, die via HTTP/0.9 eine Werbeseite mit Konfigurations-URL für den Webserver ausspuckte. Da konnten nicht mal die Sites mithalten, die bei HTTP/1.0 Redirects auf sich selbst versuchten. Anzeichen, dass HTTP/1.1 wirklich gebraucht wird, da Virtual-Hosts zum Einsatz kommen gab es selten.
Hier möchte ich noch anbringen, dass jeder gängigere Browser zumindest die wichtigsten Features von HTTP/1.1 unterstützt. Zum Problem wird es also nicht.
Bei der Überprüfung bin ich oft von Abkürzungen ausgegangen, wie z. B. http://advancebank.de/ anstatt http://www.advance-bank.de/ und bin häufig nur auf die Portalseiten eingegangen und nicht auf den Server, der den eigentlichen Zugang zum Online-Banking vermittelt. Eventuell sind daher mehrere Webserver gelistet. Ein '-' am Anfang des Eintrags habe ich dem negativ aufgefallenen Drittel verpasst...

'Internet-Technik' zeigt die Vorraussetzungen noch mal stichpunktartig. JS steht für JavaScript und galt für den Weg vom Portal bis zum Online-Banking. Bei Java ist https-Fähigkeit nötig. Selten bringen Appletviewer ungleich Netscape überhaupt ein Bild...

Die Kandidaten:

1822direkt: Als Voraussetzung wird "java-fähiger Browser" angegeben. Die Bank fiel mir dabei auch sehr positiv auf. Wenn man kein JavaScript benutzt, bekommt man technisch verschiedene Applets zur Auswahl. Da sollte für jeden Browser was zu finden sein...
Das wollte ich auch mit dem Appletviewer des Blackdown-Port vom JDK 1.1.8 unter Linux probieren. Die erste Hürde wurde leicht genommen: da der Viewer kein SSL kann, wurde erst mal die HTML-Datei mit dem Applet-Tag und das Archiv mit den Java-Klassen manuell geholt. Der Start einschliesslich Initialisierung klappte. Jedoch der Versuch mit der Bank Daten auszutauschen schlug fehl. Anhand der Fehlermeldungen war zu erkennen, dass der Transfer via http probiert wurde, der Server diese aber nur über SSL anbietet. Innerhalb der Virtual-Machine von Netscape wird https angewandt. Ob dieser gezwungener Maßen nötige Wechsel von https zu http der VM oder dem Programm zuzuschreiben ist, kann ich nicht beurteilen. Das es aber nicht gleich zum Abbruch kam, liess mich einen kleinen Trick versuchen: mit stunnel, einem SSL-Proxy, kann man einfach ein http-https-Gateway bauen, ohne dass es (SSL-)Server oder (Nicht-SSL-)Client merken. Mit angepassten Proxy-Einstellungen konnte ich so tatsächlich die Netzanbindung betreiben.
Na wer sagt's denn - es geht auch ohne Netscape...

Berliner Sparkasse: Die FAQ meint: Schalten Sie JavaScript ab - JavaScript ist aber für unser Angebot nötig... Auch die Startseite ist unzumutbar: mit meinem K6-333 lässt sich nicht mehr die Maus vernünftig bewegen, wenn das JavaScript der Homepage loslegt.
Leider hab' ich den Loginversuch ausserhalb der Rechnerbetriebszeiten unternommen - wie nachlässig von mir.

BfG Bank: Ohne JavaScript funktioniert das Auswahlmenu nicht, aber man könnte es sowieso nicht erkennen, da es schwarz auf dunkelblau dargestellt wird.
"Wir von der BfG haben etwas gegen diese Hektik..." wärend links unten die Büroklammer für Online-Banking nervös mit dem Fuß tappt und anschliessend Rundumleuchten bekommt. Viel schlimmer ist aber, dass mein Betriebssystem "zur Zeit nicht unterstützt" wird.

Dresdner Bank: "Was sind weitere Vorteile des (...) HBCI? - Neben dem bereits aufgezeigten Sicherheitsaspekt zeichnet sich der ... Standard auch durch seine Plattformunabhängigkeit aus, das heißt, er unterstützt jedes beliebige Betriebssystem ... ."
"Kann ich das InternetBanking ... auch mit (...) OS/2 nutzen? - Nein, derzeit werden lediglich ... Windows 95/98 sowie NT 4.0 unterstützt."
"Beim Anmeldevorgang kann es derzeit leider zu einer eingeschränkten Erreichbarkeit (...) kommen. - Insbesondere bitten wir Sie derzeit von einer Schlüsselgenerierung abzusehen ..."

Einige Sparkassen: Teilweise benutzen einige Sparkassen ein gemeinsames System bei banking.sonline.de, wo das Java-Applet gehostet wird. Bei meinen Versuchen mit fiktiver Kontonummer und PIN bekam ich die Meldung: "Die Verbindung zum Bankrechner ist nicht m glich. Bitte melden Sie sich neu an." Ich gehe inzwischen davon aus, dass die Meldung sehr unpräse ist und es sich nicht um eine Überlastung der Rechner handelt. - Ich habe für die Technik ein '+' vergeben.

Postbank: Es ist die einzige der 30 Banken, die völlig ohne Java-Script und Java auskommt. SSL reicht. Das verlangte natürlich nach einem Versuch mit einem Textbrowser. Der bekannteste und verbreiteste ist Lynx, der auch einfach mit SSL-Unterstützung in Binärpaketen zu bekommen ist. Mit Links und w3m hat er leistungsfähige Konkurrenz bekommen, die wesentlich besser mit Frames und Tabellen umgehen können, aber sich teilweise mit HTTP-Authentifikation oder SSL schwer tun.
Mit Lynx auf dem Versuchstisch sah es dann auch genau wegen der Frames nicht mehr so rosig aus. Die Navigation gestaltete sich schwer und der vom W3C missbilligte META-Refresh muss manuell ausgeführt werden. Daran scheitert auch w3m, aber richtig. Er kann damit gar nichts anfangen, was die Postbank so unbenutzbar macht.
Also aus der Traum, mal eben am VT220-Terminal im Serverraum seine Bankgeschäfte zu erledigen. Schade eigentlich.